In Rhino any object is solely visible in viewports. It would be very handy to have objects lists, listed objects in the layer manager, or in a schematic view like grasshopper.
That way it would be much easier to organize scenes, select invisible objects, see groupings, dependencies, materials and so on.
3 Likes
Hi Ron -
I’ve added your thread to RH-54814 Add Object Manager to Rhino
-wim
Alias and many other programs have very practical object listers that are also configurable. Having one in Rhino would be a real benefit to those working with complex products.
1 Like
Since the concept of what constitutes an “object” is very nebulous in Rhino, and Rhino models are basically “flat,” an “object” list would do basically nothing. A list of 5000 “object005” surfaces is not useful.
There would need to be some kind of new logic for naming/grouping/tagging objects distinct from layers or groups or blocks or whatever else already exists to justify this.
a really nice example
Hi Wim,
I would really appreciate it, if you could also add these suggestions to YouTrack.
Thank you very much!
You’re inventing hierarchies that don’t exist. You’re not asking for an object browser you’re asking to turn Rhino into SolidWorks. Please try to apply your concepts here to models with hundreds of objects containing thousands of surfaces and see if they make any sense whatsover.
Scott Davidson (McNeel) had written: “Orca3d has a similar tree in rhino … “
”Rhino models are basically “flat,”” ’
The command “EditFilletEdge” proves that Rhino objects are not “flat”, whatever that means.
I don’t understand why any Rhino user would doubt the necessity of an object browser.
The only reason one might not need an object browser would be if the “history” were automatically recorded in a Grasshopper definition.
1 Like
the current Block Manager is already heading in the right direction, but this Block Manager would need to be extended to groups and objects, and then more interaction options such as adjustable edits and transforms would need to be added.
I would prefer to organise 500 lines into groups and subgroups, which I can open and close and show and hide and be able to see this visually in a browser 
As an explanation and answer, I would like to quote this post:
In Alias, the software names each surface type with a specific name so one knows which of the many types it is, also very useful when working together on larger projects (think aircraft seat, “Kei” car style inner city delivery vehicle, or modular combine harvester), and, together with the Object Lister that is also a Layer Manager (with many useful options such as templating, referencing, or setting symmetries), I could not live without it.
1 Like
This is called “cherry picking”. You pick a very specific case to argue against something.
Wether something is useful to someone or not is their decision and very much depends on the circumstances. Of course having 500 basically unnamed items wont be useful to most people and most likely nobody will go through and name them all. But if it is 20 items and they are something specific then all of a sudden its very useful. It’s about having the option. It’s also about just aligning with how 99% of 3D tools work. At least I have not come across many that don’t have this concept of a list of the objects in your scene with grouping and being able to name those objects.
Having Layers and Blocks as the only way to organise your objects in a scene and being able to see them in some form of list is very limiting.
5 Likes
It would be useful to see objects as node or in a scene lister as text or in the layer manager.
That way you can see the dependencies between objects, material associations, groupings, what is in a layer, hidden objects and so on. If you have hundreds of objects in the scene, you see them, are able to sort them out group them, delete them, whatever you want.
The best way it’s implemented is in 3ds Max. If you draw a polygon, it’s an object. If you draw another one it’s a second object. If you merge the 2 Polygons, one object disappears.
That way you get a perfect way to organize your scene and see clearly what’s in it.
You even are able to sort the nodes in a way they appear in any elevation.
So you can clearly see which glass objects are for instance on the second floor of a building.
2 Likes
strangely, in R7 there is no named groups panel which would be quite helpful for giving hierarchy to a model
1 Like
Hi
GH will show all and I made a post about it many years ago but it fell on deaf ears. And it’s a pain to interact with and have to create things from scratch so I don’t think GH is the way to go.
I would like a spread sheet environment, no other modeling program has a good one. If we could merely have Rhino methods on a spreadsheet, (they’re already there in python or c) and use those we could have an amazing interactive method that would be easy to manage and would allow so many things.
We would begin with icons that let us list the objects in a scene their layers their layer states their materials. Users could place them anywhere they want on the spreadsheet and interact with them in any way even with the macro editor, python or other means.
We could then tag these items we could use formulas to create Boms, properties all sorts of things. We could do away with the properties manager, we could do away with text tags, eto documents would become unnecessary and this would make the terrible block manager unneeded. McNeel is entrenched in the complexity of Gh where you have to reinvent the wheel to use it. If we had this spreadsheet tool users could create their own linkages, modeling paradigms and so many uses for documentation easily. We just need the Rhino programming methods exposed to a spreadsheet these methods already exist. It would be like combing excel with Rhino.
RM
Hi, I would like to suggest a feature that could make Rhino much more powerful for product design, furniture, transport cases, and reusable engineering libraries.
What seems to be missing is not only an Object Manager / better object listing, but also a way to define a local component coordinate system for blocks or objects.
For example, a component could store:
- its local origin and X/Y/Z orientation,
- which axis is its main length,
- named mounting points / holes,
- optional cutting or machining reference planes.
This would make it possible to build a much smarter reusable component library.
If I replace one hardware part with another revision or alternative model, Rhino could automatically:
- keep the correct orientation,
- remap mounting holes,
- update spacing,
- rebuild simple machining features in the host panel.
This would be extremely useful for workflows like:
- furniture design,
- flight/transport cases,
- panel machining,
- profile cutting,
- product families with many variants.
In my opinion, combining:
- a better object/component browser,
- local component coordinate systems,
- named anchors/features,
- structured metadata
would move Rhino much closer to a smart reusable design system, without forcing it to become a full mechanical CAD package.
Rhino is already very strong for flexible geometry. Adding this layer of component intelligence would make it much stronger for real production workflows.
A component with a coordinate system (BasePoint) would be a good first step in the right direction.