Hello all, Been looking for this information for quite some time. Is there any information available on bounding box colours? I understand well the green > yellow > orange > red and the thickness of the box, but nowhere can I find what the Cyan and Blue colors mean. Any pointers welcome, The biggest confusion I currently have is this: Some objects imported from sketchup, after being transformed with Break > Solids into Surface, will turn Cyan after mesh consolidation, some will turn green. I am really trying to understand what is going on and what are the best practices when seeing these colors as boxes. I am fully aware of these threads before anyone link them ;-) http://forums.cast-soft.com/index.php?threads/geometry-optimization-and-file-efficiency.283/ Thanks!
Hi Jay, My bad that I never got around to updating the optimization articles that are linked in the thread you mentioned above. I will do this very soon, but in the meantime, here is the explanation (along with a bit more information than you yourself probably need, but I figured I may as well be thorough and add some more basic points, so less-experienced users can take advantage of it too). WYSIWYG’s Bounding Box system is actually much simpler to understand than it used to be, because where in the past colours and thickness used to represent objects’ complexity (i.e. amount of polygons/elements it is made of) now only colours are used. In essence, an object with a Blue Bounding Box is less complex than one with a Cyan Bounding Box, which is, in turn, less-complex than one with a Green one, and so on “through the spectrum” / through Yellow, Orange and Red. The complexity calculations are based on the number of polygons that make up objects (or LEDs in the case of LED Walls) and are an internal approximation of how much work is required to rasterize the object (i.e. get it to appear in the Shaded View). Using this system, the model within a file may be visually-analyzed (inspected) in order to determine which objects are geometrically inefficient: the more complex an object, the more processing it requires – which (it goes without saying and as with all things in computing) results in lower performance. As such, your aim should be to have a lot of Blue Bounding Boxes in your model, but for these not to be clumped together/”densely-packed”. For example, when you draw a Sphere with default options (i.e. 12 Stacks & 12 Segments) its Bounding Box is Cyan; if you then Break that Sphere into Surfaces (polygons), you will end up with a large number (264 to be exact) of Blue Bounding Boxes (one for each Surface/polygon that the Sphere was broken into); this may seem like a better option but it is not, because these polygons no longer form that single/cohesive sphere object, so each must be processed individually in order for the same sphere to appear on screen. (Modern video cards are great at processing large numbers of polygons, but only if these are submitted for processing (by the software) at the same time (in a batch) as opposed to one-by-one.) Keeping the object as an actual Sphere is not ideal either though, because performance would be slightly improved if the unbroken/Mesh-Consolidated Sphere had a Blue Bounding Box. The solution, therefore, is to reduce the number of polygons that make up the object, while at the same time keeping it a single/cohesive object. In the case of a Sphere drawn in WYSIWYG this is very simple: access the Sphere’s Properties and reduce its “base complexity” by setting the Stacks & Segments values to a lower value of 6 or 8; this will result in a Blue Bounding Box now surrounding the object; yes, the visual quality of the Sphere has decreased, but this is likely acceptable, especially if the object doesn’t need to be seen up-close. The Sphere is indeed a very simple example, but the same principle applies regardless of what the object is, how complex it is, or where it comes from, whether it’s drawn in WYSIWYG or imported. Imported objects’ complexity can indeed not be reduced the same way within WYSIWYG, but this can be done externally, using the application in which the object was created or perhaps MeshLab, and then the object may be re-imported—and then Mesh-Consolidated as/if needed. All this said, it is of course understood that it is almost impossible to have a file with only Blue Bounding Boxes, especially when you are dealing with imported objects, so we are by no means suggesting that if that’s not the case, performance will always suffer. However, the more you do to ensure that the majority of Bounding Boxes are Blue but without these being densely-packed the better the performance will be. In cases where they are densely-packed, proper Mesh-Consolidation will definitely help—even if the Consolidated Mesh objects ends up with a Cyan (or “higher”) Bounding Box; if it does, consider whether or not you can further reduce the number of Blue Bounding Boxes (i.e. the “base complexity” of the object), do so if possible, and then re-import and re-Consolidate. Please let me know if you have any follow-up questions, Dany
Thank you Dany, super clear as always. I was wondering why the box thickness did not appear changed in the last couple of releases, I guess this all makes much sense now. Kudos