Haltone Mayhem

[cwilrycx.109927]

I recently had a Support Request elevated to GOD at Autodesk in an attempt to figure out why my elevations had slowed to a crawl. Allthough not 100% where it was, it appears that the culprit was OVERRIDE GRAPHICS IN VIEW > HALFTONE. Once I removed the haltone from the object in the elevation that were far away from the view plane, the issue was substantially improved. So if you are dealing with sluggish response times, please troubleshoot by checking to see what you have overrided the graphics in view on.

[ron.sanpedro]

I recently had a Support Request elevated to GOD at Autodesk in an attempt to figure out why my elevations had slowed to a crawl. Allthough not 100% where it was, it appears that the culprit was OVERRIDE GRAPHICS IN VIEW > HALFTONE. Once I removed the haltone from the object in the elevation that were far away from the view plane, the issue was substantially improved. So if you are dealing with sluggish response times, please troubleshoot by checking to see what you have overrided the graphics in view on.

We found the same thing, and i am a little dismayed that
1: This is even an issue. Seems like a bug that should have been fixed in the most recent build. And...
2: This doesn't seem to be listed as a known issue.

Perhaps someone didn't expect this to be perceived as a great way to get depth in elevation and it would be used extensively, but now that this is known, it should at least be documented.

Best,
Gordon

[tkrich00]

I have had the same problem in plans when using the “Override Graphics in View” to change the visibility of groups to have a half tone. Autodesk sales pitch - New visibility control of groups in views: Reality; true but we cut the performance of that view in half.

[Calvn_Swing]

It depends on HOW you do it.

Think of it this way, Revit is one big database. Overriding graphics by categories or filters tends to have minimal impact on performance because it is part of the indexed data of each object that you're using to override its display.

Overriding by element is just not very Database of you, and so it does take more time. I don't know how the programming behind the overrides works at the element level, but seeing as it came about as a way to change a few objects separately from their categories it could be something as stupid as a list of element ID's associated with the override. Any list like that will make the time to apply those overrides really long.

Try this instead, set up an elevation halftone filter, and then select those same objects and change the value in whatever parameter the filter targets to whatever you said it needed to be to include those elements in the filter selection set. Personally, I've never had slow downs in views using filters like this.

Maybe one of the Dev's can chime in here and let us know why these element-level overrides are so slow...