Smn842

If you have a 3D view open then yes that's adds more time, but for large plans the file operation can be much slower than the redraw (unless in PBR mode). When using a RAM disk this can be used for Chief undo only to avoid the issues you mention. The 3D speed remind me of another performance issue which I've reported which is that having a 2D and 3D view of the same plan on the same level causes a slow down when moving in 3D. The cause appears to be the 2D plan regenerating/drawing for every camera move whether the camera symbol is shown or not. This is very noticeable with a 3D mouse due to the ease of movement and the workaround is to move the camera to another floor and then move it in 3D back to the applicable floor so the plan considers it on another floor. As a quick fix am sure CA could either make the camera symbol and overlay to avoid this or even just throttle 2D updates (say once per second) when moving in 3D. My day job is software performance and scalability so please excuse all the detail

I have also been using a specific folder for Chief undo to an NVMe SSD and as @Kbird1 said its easy enough to create a folder on a RAM disk at boot even if the RAM disk software itself doesn't provide the facility. The last time I reviewed RAM disks some had options and hooks to prepare and/or persist certain files around boots, but in this case a simple command (batch) script can create a directory for Chief on each boot. As I work in software I decided to monitor the behaviour of Chief's undo with appropriate tools during a couple of hours work and it is indeed very heavyweight. I have developed undo/redo for complex applications with multiple users and highly linked data so I am aware of the challenges, but even so some things in Chief are surprising. During that session Chief wrote more data to my SSD than anything else and that includes Chrome with loads of tabs (notorious for its cache), Norton and various other development tools and running applications including a virtual machine. From that session I noted: It appears that a few operations such as object moves have been optimised to store a relatively small undo file (2 - 10MB). Some operations are obviously trivial to reverse whereas others will require data lost by the change so perhaps this was the undo optimisations mentioned in X9 or X10 (can't remember which). Most operations trigger the storing of an undo file roughly double the size of plan file as noted in the OP. The large undo files are stored even when clicking OK to a dialog with no changes. There are many operations that trigger the large undo file but appear easy to reverse such a toggling layer visibility triggering the larger undo file, changing a setting in defaults etc. The binary contents of the undo files are easy to compress and/or reduce size during writing (I've not checked into whether these contain any SQLite tables frequently used by Chief or just another representation of the plan) I generated 3.5GB of undo files from a 65MB plan file using the default 50 levels of undo so I wouldn't want to work on monster plan! I tried a short session using a medium speed hard disk for undo instead of my fast NVMe and it was so painful I gave up. I've always used NVMe SSDs with Chief and I had no idea it could be this slow. As a software developer I do appreciate some things are not as easy as they seem and a much more efficient undo/redo may impact Chief's whole internal storage model. However there appear to be some potential ways to improve speed of the current system without major work, e.g.: Use an internal memory cache with a user configurable size (so in effect an internal RAM disk) and when push the oldest undo files to disk. Increase the number of operations that don't need to store the large undo file. It seems terrible that a bit of layer visibility causes that large file per layer toggle (unless you're really quick). Run the data through a fast low overhead compression (LZ4 or similar) before storage. There's always a trade off between CPU and disk speed especially against NVMe SSDs but compression can be done in a background thread or threads and only used when beneficial. As a quick test a single thread LZ4 ran at 700MB/s on on core on my oldest dev PC and reduced the file to 40% of the original. Good NVMe SSDs can manage 2000+MB/s write speed but even single threaded this would be useful for caching in RAM to greatly increase storage and on disk still be better for most users. Some of the applications I've written test disk write speed to ascertain whether to use compression or not as applicable. Some undo files as noted in the OP, are very similar. It may be viable to use a differential algorithm to only store differences between a sequence of similar undo files but would need code to ensure the base undo is retained or rolled forward as needed. I have run on way more than intended and have some other work to do now . Suffice to say the current undo/redo system appears to need major improvement but I hope we can get some quick fix improvements while we wait.

I am a software developer as well as Chief user and did some analysis on file activity a while back, initially for library search performance issues. I saw the same heavy writes for undo, but given I never have much of a delay for undo (my plans are normally 75 - 100MB) I just moved the temporary and undo folders to a dedicated small but very fast SSD I use for many applications that write too frequently affecting performance. I have enough memory for a RAM drive and used to use a commercial one with persistence options, but with the reasonable cot of small fast SSDs its no longer the best option for me. There are many major applications that perform too much file I/O (Chrome, Norton, Office) and also often overlook that anti-virus applications can scan some of these files on every write, so Chief is not alone here. I do think its unfair to suggest CA developers learn about linked lists as Chief is a complex application and clearly their developers have skills, but even the best companies don't always prioritise certain issues or realise the real world impact. I specialise in highly scaleable web applications and find such issues all the time. There are many other areas of Chief where it appears some profiling and general performance analysis is in order, the needless full 2D redraw discussed in another thread recently and some far from sub optimal file usages around the library for a start. I suggest you make a post in the suggestions section about this, or raise a ticket.

The last few releases have been in February so a while yet, but quite likely within the 12 month SSA.

Yes it still does the same for me no matter how I hide the camera from the 2D plan. I've just got into the habit of moving the 3D view to a different floor level to avoid the issue.

Do you have the 2D plan visible in another window with the camera on the same level as the 3D view? If so then this may well be the issue I reported several times over the last couple of years, first when I purchased HD Pro and then again after upgrading to Chief Architect Premier. I noticed that whether or not the camera symbol is visible in the 2D plan, if both the 3D and 2D views are on the same level then the 3D view speed is greatly impacted as it appears for every movement the 2D plan is being recalculated and/or redrawn. The solution is to move the camera up or down a level or hold the mouse down in the 3D window which stops updates in the 2D plan. Before X10 that had the disadvantage of turning off lights but now with the higher light limit that's not an issue. Perhaps I should report again, but I posted it in the Home Designer suggestions forum here and the second time after buying Chief via email and heard nothing back.

Is the 'Drawing Unit' on the '3D' section of the 'Symbol Specification' dialog set to the correct unit during symbol import using Advanced options import? I find most issues for symbols I import are due to this so I now check on every import (although I use metric and not sure if that makes a difference to importing).

In a 3D view Chief will show the total surface count of layers shown in the status bar. For individual symbols you can open the symbol and it shows on the 3D section under the faces section. I am just using Chief on my own home renovation so no idea of how many surfaces is normal for professional use, but FWIW my plans seem to be 600K to 900K. The biggest issue I've had is I import a lot of manufacturer symbols (from Revit format usually) and some of these are very high count like as with general symbol sites. It takes time to check and avoid issues, e.g. 30K surfaces for a single radiator but its worth it in the long run.

I thought the checkbox on the 'General' tab for doors 'Separate trim and materials on each side' did this for all cases:

I choose mice based mainly on the right size for my grip style and hand size. Then I just choose whatever good quality and reasonably high dpi mouse I can find (being left handed reduces my choice a little) However I am a fan of the 3DConnexions SpaceMouse as a mouse for the other hand. This way I can pan and zoom more easily in 2D and 3D and also when some modal dialogs are showing and I need to move the underlying plan/3D view about to determine settings for the dialog, but perhaps that is more an issue of how I use Chief being a part time user.

I use 3 Dell 27" 2560 x 1440 here and they work well for my day job (software) and Chief. The move from 3 x 24" I had before was really worth while so I would recommend the 27" of those two options as its 60% more space. The text is smaller when not scaling on the 27" compared to the 24" (109 dpi vs 94) but I actually find that better. For reference I have tried one 43" and missed the convenience of easier window separation (it was too big for side screens on my desk!). I also tried 2 x 40" and didn't like the central bar or off to the side mode of working. So for now I am a bit stuck as to how to go better other than perhaps 16 x 10 form factor 30" screens. However as that is no longer a common form factor its quite pricey and as an upgrade would only give me 11% more space. For now the only thing I am sure on is I want my next upgrade to be high dpi monitors to benefit from sharp text when scaled as required.

Thanks - I did scan through that thread but didn't pick up that issue was included given all the points mentioned.

After some experimentation to get good results with PBR for a particular plan I updated the plan default settings to match what I was manually entering into the 'Rendering Technique Options' dialog in 3D views. However after changing Default Settings -> 3D View Defaults -> Rendering Technique Defaults -> Physically Based the next time I opened a 3D view and changed from standard view to PBR I had a white out with the sun enabled (without it was okay). After some experimentation it appears for me its just the 'Improve Lighting Quality' setting being on in plan defaults that's causing the issue not the other settings I changed. If I leave that option off, open a new 3D view, switch to PBR and then enable 'Improve Lighting Quality' from 'Rendering Techniques -> Techniques Options' it doesn't white out. The settings should be the same unless I am missing something but perhaps having it set before generating the initial view is the issue. Can anyone else reproduce this as I see the same behaviour in several plans.

I use one and don't have that issue, however I have had the odd case where it stopped working while using Chief and I had to close Chief and restart it to get it to work again. I find this mostly when changing between three Chief windows over thee monitors so there may be a glitch with doing that rapidly. The drivers for the space mouse have also had some odd issues over time. I had a case recently where after an upgrade the mouse would show as not connected and eventually I had to fully uninstall, clean up install remnants manually and re-install to get it back.

Thanks, the latest update fixes the cases I noted earlier. I appreciate issues happen, but a suggestion for such problems in future would be to post in Announcements that there's an issue and library update in progress/done. That would have saved myself and others some time and probably a few support tickets/calls for CA to answer as well.

I've updated my support ticket about this as it was closed after the last library updates.

I've just checked and although the recent updates fix the missing texture icons in the library browser when using those previously affected materials I get the same missing file warning you get. The material then looks likes its applied but in fact some details are missing: Maybe other people aren't trying the materials out fully.

The response I got from the support case a month back was to manually edit the wall and the issue would be looked into. Manually editing is fine but stops auto rebuild so not ideal. Today I chased up to find out if this issue has been confirmed/logged as a bug given the X10 official release version still has the same problem. The response was to request the plan in X9 format which I provided a month ago when I raised the case and specifically stated it was still in X9 format. This makes it appear this hasn't even been reviewed to date. I raised another compatibility issue when I upgraded from X8 to X9 that also yielded nothing other than a workaround and was never fixed. I work in software development and appreciate that some regression bugs will never get fixed, but lack of feedback (request for more info, not reproducible, confirmed bug ID etc) and not appearing to read clear case notes doesn't do much to make users keep reporting issues. I do hope I've just had bad luck with my two support tickets to date.

Even as a hobby user I find the door frame and sill issues annoying. Also the lack of inset control which I didn't find an easy workaround for (makes modelling UK style construction very difficult). I did try playing around with using tiny sections of a different wall type but it got very messy to maintain especially with working around a visible wall cavity in some cases.

I just ensure the 'Drawing Unit' on the '3D' section of the 'Symbol Specification' dialog is set to the correct unit during symbol import (check 'Show Advanced Options' on 'Import 3D symbol' dialog) and that solves the problem. You can use the bounding box sizes on the sizing section to ensure the unit is correct if not sure of the source scale. Once imported the drawing unit is read only. The bounding box is just for correcting where the effective edge is for placement etc. I am only a hobby user so there may be ways to adjust after import but this works for me.

Yes I noticed that bit of gutter which wasn't there in X8/X9. They're all auto built roof planes and the walls have no manual adjustments so it should work as is.

I am a software developer so completely agree with the sentiment, but with my end user hat on it all takes time ;-) I'll report it. Thanks.

For my first look at X10 I tried opening an existing X9 plan and the previously correct roof and auto built walls now have a gap: Anyone else reported this type of issue for the current X10 beta? If not I'll sort out a cut down plan for CA support to have a look at to see if its a bug or problem with my plan.

Using two mice is a good, but with one of them being a 3D SpaceMouse its even better in my opinion, and it even works while modal dialogs are displaying. I am not a professional user, but even with my limited use I couldn't imagine using Chief without one.

I second the suggestion on a larger PCIe SSD as Chief does a lot of file I/O in the background and 256GB doesn't go far (only 238GB in real GB terms) . A drop on the graphics card to even a GTX 1080 should allow that and its also quicker to upgrade a graphics card than the boot drive. The general system performance increase of PCIe SSD even compared to SATA SSD is significant.