It would be far more useful to finally implement an optional permanently visible list with all the objects in the file (just like many other 3d programs), that could be also arranged by object type and filtered to be shown or hidden in the list based on their type. For example, the user should be able to choose to see only surfaces and polysurfaces in the list, while the remaining object types won’t be listed there if not needed. Note that this is not hiding the actual objects from the viewport, it’s just hiding them from the list of scene objects in this particular window. that pop-up window must be dockable, lockable, and should support opening and closing via a key or a key combination. The objects list must be able to include every object in the scene, even those that are currently hidden or locked. It must show the layer where each object is located, too. The latter will help with finding “lost” objects that were accidentally put into some hidden layer that the user can’t figure out and thinks it’s missing, while in reality it still exists somewhere.
I would also like to be able to right-click on a layer and select “List all parts in the layer”, which will open a pop-up window consisting a vertical list of all objects in that particular layer, including those that were hidden. This should be like a light version of the scene browser list.
Here is a screenshot og Zanoza modeler, as an example of scene browser done right. It has that useful feature since two decades.
Also, the scene browser of Keyshot:
Rhino models don’t have a hierarchy, it would just be a giant flat list, of minimal utility unless your model is really simple.
It’s not about hierarchy, but having all the existing objects listed in a vertical list. They must be able to be sorted by object type, by name, or by layer. Kind of what the
'_SelName tool does, but with the following differences:
Ability to be docked to some toolbar, to be shown as part of the Properties panel, or to be opened all the time as a dedicated floating window;
To include all objects in the scene, even those that are locked and hidden.
There could easily be THOUSANDS of objects, tens of thousands of objects. Your screen can list how many at once? And how many have meaningful names that let you tell what they are at a glance? It’s not helping you find a needle in a haystack, it’s just adding another, bigger haystack to search through.
I mean, if people want it, whatever, but…it’s not gonna do much.
Exactly! That’s the beauty of the scene browser! It has a list of all objects in the file. The vertical list behaves exactly like the scrolling windows just like an Internet browser, so the number of objects is no issue at all. By the way, the
_SelName command also invokes a pop-up window with a scrollable vertical list of objects that could be extremely long, so there is no limitation by the screen resolution itself.
We are working on this as a long term project. The initial implementation is focusing specifically on blocks as a replacement for the current block manager in Rhino.
promoting groups to actual objects would help a ton in creating hierarchical structure in the model.
Ok, so I haven’t done this in quite a while so I guess it’s due… here’s a screenshot from the object lister in Alias which is really neat because it shows a number of things:
- Object history (the green highlight)
- Object type (it even shows if a surface is trimmed or not)
- Group hierarchy (although typical I didn’t have any in the screenshot)
I think I’ve mentioned this before, but the first question almost everyone I show Rhino to is always “so where do I see what objects I have”, and that might be a very trivial and basic question, but it’s really confusing when literally every other CAD package on the market has this feature while Rhino does not.
See my post on Geometry omni viewer this is mostly possible now within Grasshopper.
Rhino Geometry Omni Viewer - Rhino / Rhino for Windows - McNeel Forum
Please note that I stated we are working on a new block manager panel for Rhino 8. This can be thought of as a step toward a general object browser, but it will initially be focused on and limited to blocks.
I think I am safe in believing that a lot of users think blocks are one bite of the elephant, will be useful to a lot of people, and a manageable step in eating the whole elephant. As my mom used to say: you need to finish your dinner! That will make a much larger number of people happy by making it much easier for them to manage their model.
I think a very important aspect of managing objects is an automatic two-way visually indicated association of a selected object in the viewport and the object list (ie: objects could be selected either in the viewport in the usual way or from the list in the usual ways: shift or control click for multiple selections).
Perhaps a handy way of implementing multiple selected objects would be to float them to the top of the list for the duration of their selection.
We could have a layer like panel, showing all the objects, that can be used to create a hierarchy. Or numerous hierarchies.
Layers (as-is, no objects listed)
Custom Hierarchy 1 (perhaps a build hierarchy)
Custom Hierarchy 2 (perhaps a material hierarchy)
Custom Hierarchy 3 (BIM LOD rating)
Custom Hierarchy 4 (group objects by drafting options, hide object by hierarchy rather than layer)
Custom Hierarchy 5 (naming conventions, name parts based on the hierarchy)
The custom hierarchies can have nestable “folders” for grouping like objects, just like the layer panel. All of these are identical feature wise, only our imagination and modelling processes decide how the hierarchy is to be used.
Features would be similar to the layer panel; right-click assign object to hierarchy level, select objects, etc.
There could be no limit to the number of custom hierarchies we could build to manage large models
Visibility properties (hide/show, colour, transparency, etc) could change when flicking between hierarchies. This would alleviate my biggest concern with a scene browser (or similar), visibility hierarchy. Does the layer system override the scene browser or vice-versa. As we know, hidden objects already create a minor issue with layer on/off state. The scene browser visibility would have to leverage the existing Hide and Show commands, not override them.