TheKitchenAbode

Just ran a quick test concerning faces. Took a chandelier that has about 9,500 faces and placed in a blank plan. Copied it for 100 units giving a total face count just shy of 1 million. The 3D Model Rebuild took (hanged) for 9 sec. on my system after I clicked OK on the Rainbow DBX.

Michael - Good Point. I think the whole program is structured around these layers, they determine what you see, what CA processes and how you access things during your workflow. How you set them up and what elements you assign to the layer(s) can have a significant impact on how efficiently you and the software function. Hopefully some of the items discussed here will help us better understand the importance of the Layer Sets, their Display Options, how we assign elements to them and how we structure them.

Another way of looking at these frustrations is that if one is curious enough it encourages you to dig deep into the program as you attempt to understand what's going on. This often results in a greater understanding of the software and how it functions. In this particular situation I now have a much improved understanding of Layer Sets than I did prior to this. CA may not be perfect, but time and time again it seems that with CA if there's a will then there is a way.

That's a step forward

Larry - Understand but I know from experience that it can be a huge task at times to rewrite code and just about every software company tries to avoid this like a pandemic disease. The first approach is always a patch. I'm sure they can come up with something that would at least minimize this, at least concerning the 3D Model Rebuild. Even if not, from what I can see, we can control this from our side through the use of the Layer Set Display Options. Possibly this was always the intent, it was just never explained to us.

Thanks Alan - I'm certain there is something they can do to at least minimize this. I'm can't believe that they did not encountered this when developing the Grandview plan, unless they are using IBM's Watson. I know the 3D Model Rebuild is necessary but maybe they could make this a background process so at least the program would not hang when this is executing on a complex model.

Here is a possible work around for those experiencing a 3D Model Rebuild execution when only working with a plan view. Open up a 3D camera view and set the layer set to "All Off", go back to your plan view and I think you will find that the 3D Model Rebuild will not execute anymore. This assumes you do not have any other 3D cameras open. It seems that there are times when CA does not recognize that there are no 3D Views, so it continues to Rebuild. I've tested this a few times in the Grandview plan and it seems to work.

I've done a bit more experimentation. I'll stick my neck out but it seems to me the Rebuild is a big part of the problem. In my opinion it's too "Dumb of a Function" as it seems to rebuild the entire model regardless of what has actually changed. I uniquely named a material so it would be exclusively assigned to only one couch in the Grandview plan and not used anywhere else in the plan. I clicked the couch with the Rainbow tool, clicked ok and it made no difference to the Rebuild time, it obviously rebuilt everything even though the only thing that was changed was one material on one simple couch. This definitely needs to be corrected if at all possible.

Locking layers has no effect. It appears to be the number of layers in use and the number of elements on the layer that dictates what has to be processed. I have tested this over and over with the same result. The only hick-up that I can find is that for some reason CA performs a model rebuild even though there is no 3D model being displayed and it only seems to happen with certain elements and not always every time. You can turn off the Auto Rebuild but some functions like undo/redo override this and force a rebuild.

Thanks Larry - From what I can conclude so far is that the demand on hardware is not really that severe. With the Grandview plan my total RAM load is only 6GB and that includes my other programs. The Memory load on my graphics card is only about 2.4GB and that's with the plan, 3 cameras, 2 elevations and another monitor with several windows displayed. I tested the graphics response with about 10 cameras open to push it to use a swap file. There was very little in noticeable response time when the camera view had to be pulled from the swap file and this only effected the initial display of the view, it had no effect on moving within the view once it was displayed as it is now all in the GPU Memory. There is no benefit at all to having a bunch of unused RAM, it's just a waste of money. Concerning the Drives. It only comes into play when you initially load the plan, the first access to a Library section, undo/redo and a file save operation. The first two are one shot deals and no longer have any effect while you are working on the plan. In most circumstance the undo/redo and file save disk read/write operations are just not that much. From what I can see the undo/redo lag is not related to the drive operation, it seems to be this rebuild function that takes place after the fact. Will keep exploring and posting my thoughts

If you are triggering the rebuild by just opening and closing the DBX then make sure to select "Cancel" or the "X" to close the DBX. If you select "OK" then it will trigger the rebuild. If you are not making changes related to the furniture then turn those display layers off for the camera layer set. This should prevent them from being included in the rebuild.

I had looked at stuff like that many years ago. They really don't do a lot and can cause unexpected problems. In most cases if you check your CPU usage with Task Manager you can see that in most cases only 1 or 2% of the CPU is being used on the normal Windows background processes. This would not make any noticeable difference in performance. On my system even with Ray Trace eating 100% of all Cores there is no noticeable slowdown in my other programs. Today's processors are much better at responding to interrupts and managing multiple processing tasks than systems 5 or more years of age.

Mark - It looks to me that the rebuild is definitely an area of concern, especially when it is triggered by only opening & closing the DBX without any change having been made. These rebuilds are time consuming and get progressively worse as a models complexity increases.

So far closing any DBX related to Material properties or Terrain elements seems to trigger an automatic rebuild or something depending upon closing.

Just checked into this, Yes it happens with the Rainbow tool. I clicked on a surface, the DBX opened and then I closed it without making any changes and it did a rebuild. The rebuild must be triggered based on closing the DBX and not on whether a change was actually made.

Agree - There does appear to be times when a rebuild is executed for no understandable reason. I would need to check but I think this can happen with the Rainbow DBX.

I did observe this happening if you change a materials properties. If a material changes then the model needs to be rebuilt. From what I observed, any change you make will force a rebuild. The fact that it seems to vary according to a particular camera could be related to the display layer options for that particular camera. From what I observed this determines what will be rebuilt.

I can't say specifically for your situation as there is no way for me to know whether or not something else is going on in you plan. My observations and conclusions are based on the Grandview plan and I'm fairly confident in my results based upon what I could observe. I also only explored a few of CA functions, listed in my posting. There could be many other functions that could produce differing results.

Just a clarification - When I talk about The Active Display Sets I should have said that it is the Active Display Options within the Active Display Set that determines what CA processes.

Thanks Perry - I think for you your system really helps. One way to artificially emphasize the lag is to go into Preferences, General and uncheck Optimize for Multi-Core CPUs. Take the Grandview plan open a 3D camera and change a roof plane. Dialog boxes will pop up that shows the rebuilding process steps. On faster systems you don't see this.

I did not test placing pdf's or pics directly in the plan but I did test turning off textures on all of the materials and this did not seem to have any noticeable effect.

I spent several hours yesterday investigating the issue concerning sluggish/laggy computer performance that many users seem to experience as their plans become increasingly complex. I used the Grandview plan from CA and setup several system monitors for CPU Usage, RAM Usage, Disk Access, GPU Usage & GPU Memory Usage to see exactly what demands were being place on my system when performing certain CA functions. My System Specs: - I7 6700K 4GHz, 4 Core with Hyperthreading - 8 GB RAM - 512 SATA Drive (not SSD) - Nvidia GTX745 4GB - CA X9, Windows 10 General Observations and Conclusions System Ram & GPU Memory Usage - Initial system Ram used with Chief before loading plan & layout – 4.1 GB - Ram used after loading Grandview plan & layout – 4.7 GB “the plan and layout consumed only 0.6 GB of system Ram” - Initial GPU Memory used with Chief before loading plan & layout - 380 MB - GPU Memory used after loading Grandview plan & layout – 840 MB “the plan and layout consumed only 460MB of GPU Memory” - With three 3D views and 2 Elevations open system Ram used – 5.6 GB “each view consumed an average of 0.2 GB of system Ram” - With three 3D views and 2 Elevations open GPU Memory used – 2403 MB “each view consumed an average of 313 MB of GPU Memory” “CA is not very demanding on System RAM or GPU Memory” Some CA Operations/Functions When opening a new camera view Seems to be primarily CPU based as CA builds the model & it’s surfaces before sending to the GPU. Undo/Redo Primarily CPU based, minor Disk Access as CA re-builds the model & it’s surfaces. Stretching a Roof Plane Seems to be primarily CPU based as CA builds the model & it’s surfaces. Rotating A Camera View GPU only – does not affect GPU Memory used. Accessing the Library Disk & CPU – disk access only happens the first time the library section is first clicked on. It appears that library items are not preloaded into memory when CA is initially started. Once used they remain in RAM for future access. Ray Tracing CPU only The most interesting observation I made relates to when working in a 3D view. Any change to the model requires CA to rebuild the model, this includes undo/redo. When working with a complex model such as Grandview this rebuild process can take 5 or more seconds depending upon your system. What I also observed was that even if auto rebuild is turned off this does not apply to the undo/redo. Also, the total number of elements that CA uses in the rebuild is determined by the Active Display Options within the Active Display Layer Set. “The greatest contributor to lag is due to the rebuilding of the model” “Active Display Layer Sets determine what needs to be rebuilt” Final Thoughts Upon some contemplation, it became obvious that the 3D models seen on our screen are generated solely for the purpose of presenting the data in a form that is easier for us to understand and manipulate. This data conversion process is likely the most time consuming of all CA processes. There are only two solutions to making this process faster. 1.) A faster Computer. 2.) Process less data. The first is ok but that costs money, continual upgrading and the reality is that no matter the hardware you would always eventually be able to build a model that would overwhelm it. Processing less data is really the only viable solution. The Active Display Options within the Active Layer Set provide the ability to control how much data CA must convert. As the model is for visual purposes, it really serves no purpose to have CA process data that is neither seen nor is needed when performing a task. For example, when working with Roof Planes what visual information do you really need? Most likely just the Roof Planes and Walls. If everything else is turned off then CA only processes those two elements of the model. With any reasonable computer this amount of processing should be easily handled regardless of the total complexity of the model.

Here is one more very interesting study. It looks at multi-cores and dual Xeons using Photoshop. https://www.pugetsystems.com/labs/articles/Adobe-Photoshop-CC-Multi-Core-Performance-625/

Chopsaw - Here is a good example. http://www.tomshardware.com/reviews/intel-core-i7-broadwell-e-6950x-6900k-6850k-6800k,4587-4.html The 6950X has a Cinebench score of 1,800 while my 6700K is barely 900. One would assume that with a 6950X you could expect a 250% performance improvement across the board. But if you look at the test results you will find many instances where my 6700K outperforms the 6950X. It's only when testing programs that are core dependent that the 6950X shows it's real power. I believe that in most circumstances CA other than the Ray Tracer operates more like Microsoft Office and Abobe Photoshop/Illustrator.

Chopsaw - Your CPU has 4 hyperthreaded cores giving you 8 logical cores. Your CPU runs at about twice the GHz as the Xeon which from a relative perspective gives you the equivalent of 16 cores. Depending upon the software, as you have seen, those cores are not always used to their max or not all cores are recognized. Another factor can be CPU throttling, as the temp rises most CPU's will throttle back the GHz, this can vary quite a bit between different CPU's and their cooling system. There is no doubt that it's very challenging to determine the right hardware balance for the software you use at a cost point that represents dollars well spent.