TheKitchenAbode

Though this should always be done I have never found it to have much if any effect on speed, tends to be more related to display quality and certain camera attributes. No harm in checking.

If you are talking about having problems changing the color/finish of a cabinet or any other object one thing you need to first check is your plans list of materials. Often if you review this will see duplicates, these duplicates are problematic. Say your cabinet finish is color white and you wish to change it to color blue with the spray can, but in your plan materials there are two color whites in the list, when you select color blue from the library and hover over your color white cabinet and click apply which of the two color whites in the material list does it change. The one it changes may not be the one that is associated with that cabinet and therefore the cabinet color does not change. To overcome this issue just open up the plan material list and whenever you see a duplicate just use the rename function and add a prefix or suffix to it to make it unique, now everything should work just fine. Not sure exactly why CA allows duplicate naming in the plan material list, this should never happen but it does and can happen very often if you are making lots of changes to your materials.

Welcome to Chief. There are times when library issues are related to the video card or video driver, these are used to generate the previews when you select an item. Make sure your video drivers are up-to-date. You should also add to your signature your system specs and version of Chief, it is very helpful when others are attempting to assist with issues.

I really don't think there is much you can do about this and I'm not sure there is much CA can do either. It seems that the handling of 2D graphics is done via a Microsoft module. To display things when panning and zooming in 2D all those vectors have to be recalculated and then rasterized. Most of this is CPU related computations and from I can see they are predominantly single threaded so there is an inherent limitation as complexity increases. As this discussion has evolved the only option is to use the display layer sets to reduce as much as possible the displayed graphics.

Worth looking into. Well I can see exactly what your issue is, you don't have enough memory!!!

That's a tall order!!! What are the hardware specs of your current system? Maybe there is something that can be done but if your system is already reasonably configured then it's unlikely you will be able to reduce the lag enough. Again need to know your current specs. Not sure why you are so adverse to turning of layer sets, this is the most effective way to improve performance and it does not cost any money to do so. It just involves a bit of front end effort to set-up/define the different working sets and then save this as your template. Like you, I have all kinds of 3D plants and furniture in my plans but if I'm working on roof planes there is no purpose in having those items displayed, they only clutter-up the view and slow things down and they can also be distracting. It's important to understand that there is no software that can handle an infinite amount of complexity, they all slow down at some point in time. Breaking things down into more manageable chunks is the only effective way to deal with this and this technique is used in every industry software or otherwise.

To assist you need to describe precisely the issue you have and what you are attempting to do when things slow down. Better still is to post a problematic plan. Looking at your system specs I'm not to sure there is much room for improvement as far as hardware goes. Your RTX 2080 can't be the problem and you have 32 GB of ram, both of these are far more than what CA needs. Your I7 7700 is a fairly good processor so upgrading this may not provide any significant performance boost, maybe 20% on average, also to upgrade this you will need a new motherboard that will add to the cost. As others are suggesting, managing the display layer options to reduce display complexity is an easy one, especially in plan view if 2D panning and zooming lags. This can also help with 3D camera views but when choosing the things to turn off you need a different approach. In 3D things like textures, the number of active lights, the sun setting and shadow settings have a significant impact, if these are not needed then turn them all off. In 2D plan views everything displayed are vector graphics and to rescale these each time you move around is highly CPU intensive. This is one of the major problems with say 3D plants, their cad blocks are way too complex, all those vector line details have to be recalculated when scaling. This is similar when additional content is imported such as high res pics or PDF content, it's not that the files themselves are a problem it's what has to be done to rescale them each time you pan and zoom. You can also turn-off as many auto-rebuilds as possible so this is not happening to the entire model every time you make a change.

Excellent point. When discussing this it is really important to differentiate between 2D and 3D performance as they involve distinctly different processes. It's also important to recognize that even in 3D CA has to do a lot of computations when one makes changes to their model and these changes are primarily CPU based and they need to be completed before the graphical portion can be updated.

This is most likely due to the fact that much of the given advice is often based upon broad generalities concerning computer performance. Though valid it does not reveal the true picture of what's going on in respect to a specific software package, unfortunately this can lead one to misinterpret the role a specific piece of hardware has and its impact on performance. For example, if your monitor is 60Hz and you find the movement on your monitor to be jittery then there may be nothing gained by choosing a graphics card solely on the basis that the new one can put out 120 Fps. First, a 60Hz monitor can only display 60 Fps and no more, secondly all graphics generation involves the CPU and thirdly how the software is written is all part of the involved process. To make the appropriate choice one needs to understand what role each of these have, is it an inherent limitation in the software programing, is the CPU to slow and can't feed the GPU fast enough or is the GPU not fast enough. For CA it can be even more complicated as there are many computational processes that must be done before anything is done on the graphical side, so is it the this that's really the issue, maybe it has nothing to do with the graphical processing/hardware.

Everyone has the same(similar) experience. It bogs down the system due to the fill, it's set at 1/16" which generates a huge number of vector lines that must be regenerated each time you pan or zoom. This represents what happens as a plans complexity increases, each wall, framing member, cad object and symbol are in plan view vector lines. It was also designed to demonstrate that the number of surfaces are not the only contributor to lag, as this object only has 12 surfaces.

Also, if when the camera is open and you have changed the display layer make sure to save the camera before closing it, otherwise it will use the prior one.

Everything always runs fine as long as the plan remains below a certain level of complexity. Would be interesting if you would run this P-Solid stress test with your graphics cards to see how they perform. Once the plan is loaded, first select the full screen icon and then record the time to reduce it by one magnification. Then reset it back to full screen and then record the time to increase it by one magnification. P Solid Stress.plan

Thanks Michael. Having the lights on or off depends on how you wish the scene to look. I just wanted to demonstrate that X11 PBR can generate a half decent scene with just the sun only and a few minor material adjustments. The big advantage in not having lots of lights is that the PBR runs real fast and with just the sun it simplifies your lighting adjustments as there is only the sun to adjust. Same for the exterior, the one I posted yesterday(a few posts above) only used the generic sun, no other lights. The model has 2.5 million surfaces. 116 3D trees/plants, with just 1 light source everything runs very fast. I know many users are struggling with CA's PBR, but it's not really that difficult. It just takes a bit of controlled experimentation to develop an understanding as how the sun and lights work on their own and when together. Materials are only adjusted once the lighting is correct, not before.

The other lights are not turned on, the only light source in the scene is the generic sun. The recessed lights look like they are on because their lens material has emissive set in the material properties. Only lights that are actually turned on require computation.

Here's an example of an interior PBR that only uses the generic sun, no other lighting. When using just the sun the interior ambient is going to be dictated by the amount of glazing, the more glazing the more ambient light. You can increase the ambient by cranking up the suns lumens but this will also crank up the direct light, find the right direct light level and If the interior ambient still appears low just add a small amount of emissive to the ceiling and wall surfaces. In this scene the ceiling emissive is 0.13 and the walls are 0.20. As only the sun needs to be computed this PBR runs real fast, about 5 seconds to regenerate after a change, also rotates, zooms and pans smoothly. This model has 2.4 million surfaces and contains 116 3D trees/plant, it runs smooth and glitch free.

Just for interest, I took an X11 PBR, made a few basic adjustments to saturation and light levels in Photoshop. Here is a direct comparison to a scene that was generated in another rendering program. The exterior X11 PBR only uses the generic sun, no other lighting. Though the other scene is of better composure, most of the lighting qualities between the two are comparable.

It gets a bit more complicated if there is a material region spanning more than one floor. The material region even though it spans more than one floor is assigned 0nly to the floor based on it's start point when first drawn. Now if you try to paste a window from floor one onto floor two where the material region is it causes a problem as it seems to take the material regions floor assignment to locate the window, so it places it on floor 1 instead of floor 2.

Just played with this, good catch. It only seems to happen if you do a copy paste in place and then drag the window up onto another floor. If you do a copy and then paste it on another floor then everything seems to work out fine.

If it was working ok with X11 the other day then it might be something in that plan that is causing the problem. Try another plan to see if it happens again. You could also post that plan so we could see if we also get that message.

Library Analysis - I have just finished an extensive assessment of the processes involved during library use. When the library is being accessed there are 3 processes involved, the first being accessing the disk drive to retrieve the symbol/texture, the second process involves the CPU to process the symbol/texture and the third process involves the GPU to display the model/texture. Disk Drive Accessing - disk access times, regardless of symbol/texture complexity it was always under 1 millisecond. Also, under most circumstances once a symbol/texture had been accessed for the first time it remains in memory so subsequent accessing of the symbol does not require accessing the disk drive. CPU Processing - this is where the bulk of the time is spent. Essentially the CPU processes are no different than those involved when generating a camera view. CA must generate the images of the symbol/texture for display in the selection panel and the preview panel, which are basically mini camera views. As symbol/texture complexity increased the CPU processing time increased accordingly. GPU Processing - Though involved as it would be in any camera view the time to process was relatively minor. The GPU really only comes into play once the model has been generated/displayed and it then takes over when the symbol/model is being rotated or zoomed in on, no different than what happens in a standard camera view. As revealed in prior stress tests, the CPU plays the most significant role in overall processing time and it's importance becomes even greater as complexity increases.

Just played with this. It does not seem to be related to an Attic wall. It happens on any wall if the window intrudes into the floor or ceiling platform. It seems that the material region does not recognize objects in those areas.

Your symbol does not work correctly because for some reason, the actual symbol size and the bounding box size/position is mismatched, maybe when it was first converted to a CA symbol something got corrupted. Suggest just placing your symbol in a plan, not in a cabinet, adjust the symbols size to be proper, ignore the bounding box. Then convert it to a symbol, then place it in the plan again and open up the symbol and set the origin offsets and bounding box as they should be to insert into the cabinet door opening size. Save this to your library and all should be ok.

I believe you will find that when a symbol is first inserted into a cabinet that CA does not size it to fit. It checks the symbols defined size and if the cabinet opening is large enough it will insert it at that size, if one of the dimensions is to great it pops up a message that the cabinet opening is not large enough and to resize the cabinet. The symbol stretch zones only come into play after the symbol has been inserted and you change the cabinets size.