Trimble Business Center

Working on a project that was revised quite a bit.

Whenever I make an edit to an element that is a surface member, I'm experiencing an unacceptable amount of "lag".  

The laptop is pretty beefy: 32gb ram, i9, NVidia Q4000, SS harddrive +250gb free.

I have all surfaces that are not related set to "Empty".

The surface in question is set to rebuild "By User"

The Design and Original takeoff categories panels are empty.

Yet, any edit that is made to a surface member cause a quick progress bar flash like it's calculating the FG even though its set to rebuild by user, and then an unacceptable lag. See the linked video below for a demonstration. Not sure what I have set incorrectly, or doing incorrectly, but it the lag is unproductive and quite annoying.

Dropbox - 20501 Medline NY - Trimble Business Center 2020-10-15 14-46-32.mp4 - Simplify your life 

The issue i likely with the Contours and Quick Contours that you have on the FG Surface that are visible. If you have a lot of Quick Contours, even when you have the rebuild of the surface set to By User, the Quick Contours get told that the surface changed and even though it has not rebuilt yet it triggers a regen of the quick contours and that is the lag you are seeing. If your Quick Contours are at a loose interval the lag will be less than if at a Tight interval. The redraw is zero when they are switched off.

Contours if visible can be set to rebuild by User or Auto or Show Empty also, and those could also be a part of the lag that you are seeing depending on their On / Off state and depending on how you have their rebuild set - they will get rebuilt when the surface changes and gets rebuilt - i.e. if you have the surface Rebuild set to By User and the Contour Rebuild set to auto, the surface does get changed when you add or remove lines or change the elevations of lines, and while the surface does not get rebuilt the contours do, even though the surface did not change because you have to rebuild it by user.

I discussed this with the developers and they will take a look to see if that is something that they can address because while the surface model did change (but not get rebuilt), there is little point rebuilding the contours if the surface has not been updated and maybe there is something that can be done with that logic - currently the surface changing causes the rebuild of contours - there is no ability to stop Quick Contours from getting regenerated but that is 100% where the lag is coming from.

Alan

Thanks Alan,

As suggested, I deleted the calculated contours completely and turned off the quick contours. As mentioned, the responsiveness while editing immediately became acceptable. However, the quick contours are indispensable when creating/editing a surface and the user should not be put in a position of choosing between a productive, responsive system and the data needed for quick verification of the effort. This is why we put the surfaces in rebuild "by user" or "show empty" in the first place. Having the contours continue to calculate, even though they don't redraw, kind of defeats the point of setting the surface to by user. The quick contours do not redraw until the surface is rebuilt so as you've mentioned, what's the point in having them re-calculate with each and every edit, which is a severe determinant to production, if the surface is set to rebuild by user or show empty in the first place. Having to switch the properties of the calculated contours back and forth between empty and by user, and then having to rebuild them, is also disappointing and counter productive. They too should not re-calculate until instructed by the user to rebuild the contours or surface. 

Hopefully the development team doesn't disregard this issue as it has many others and gets it cleaned up sooner rather then later as it's madding when you're in a hurry trying to get the work done. To me, this is a shortcoming of the product and needs to be addressed post haste. Thanks again for your help and bringing the issue to the devs attention.