Since it was the most liked posts in the older Rhino 8 WIP post, I would like to resurrect the ongoing quest to finally get an Object Manager in Rhino 9.
The original post by @ThSRhino 8 Development - #91 by ThS got 32 likes (by far the most in the almost 700 post long thread), while many of the posts following in the discussion by myself and many others all got a lot of likes as well.
As mentioned by thomas, there was a beta version of this in Rhino 4! We are now at Rhino 9.
I stand by my conviction as a UX designer and long-time user of Rhino, that not having an Object Manager/Outliner, like literally ANY other 3D software out there, that the Object Manager is the biggest no-brainer and would be a great feature to make Rhino more accessible through sheer familiarity.
So my question to McNeel is again: Is this being worked on for Rhino 9? Will we ever see an Object Manager like we are so used to in all other tools? Just something so I don’t have to constantly select things in the viewport or create a layer for basically any small part. What’s the point of naming objects, if I can’t really see that name in a list anywhere?
Still baffled by the absence of the Object Manager and McNeels reluctance to admit its usefulness.
The feature request is on the list; it wouldn’t be if it weren’t deemed to be useful. I’ve added this thread to RH-54814 Add Object Manager to Rhino
Judging from recent activity in RH-66122, this is not completely out of the question.
-wim
I was being a bit tongue-in-cheek, because of how long it has taken and how long some youtrack items have been around for. Obviously it was deemed useful back in Rhino 4 as well.
Whenever it comes up there always seems to be some resistance from McNeel and questioning why would need such an outlandish tool.
Right now I am not even sure if it was abandoned because it was too complex or if really ALL other items that made it into Rhino 5 to 8 where more important. That is the only conclusion we can come to if it was in Rhino 4, got dropped and now it “might not be out of the question” that we will get it in Rhino 9.
So yes, I do think that whoever decides what gets worked on does not see the value in this and I am still curious for that reasoning.
We made the block manager panel in Rhino 8 as a first iteration of an object manager. This isolates the problems to solve before moving to a general solution
For ages loving to use Rhino for the creation of UIs and 3D assets, I am desperately missing an object manager to create defined hierarchies.
An omission of Rhino which forces me to use an additional tool like C4D or Blender in my workflow to create object hierarchies.
I even am thinking about switching to a different tool like Shapr3D, which offers me a C4D/Blender-like facilities to structure my scenes …
How do you overcome these limitation?
Still hoping that an Object Manager will make it into R9!
Well, you don’t. You can only end up using Layers for everything, which looks good on paper, but relies on everything actually being on the right layer.
We simply use Rhino mainly for Grasshopper and simpler 3D scenes with not a lot of hierarchy. You can actually also create somewhat more modular files, by placing one .3dm file in another or using Blocks.
I hope the Object Manager is still coming as well, but I am not holding my breath. There is a thread on here where the devs post updates on Rhino 9 and the object manager is not even mentioned in there, as far as I can tell: Rhino 9 WIP Available Now!
Removing the Object Manager from Rhino 8, pretty much killed my enthusiasm for the upgrade, despite being a Mac user! I was so crestfallen to see the object manager dropped out, that I basically stopped caring about the entire Rhino 8 release WIP and any other features that were added…
I’m slowly using other more friendly tools more often, because proper Outliner features are a HUGE usability difference once you’re working with more than a dozen objects even temporarily.
Adding it to Rhino 9 would make this a no-brainer upgrade for me.
Note that in Steve’s comment that you quoted, there is no mention of Rhino 9.
As far as I can tell, this is not something that will be in Rhino 9.0.
-wim
You are right, it was only you hinting at the possibility. I seemed to remember that was the hypothesis, that it would be the Block Manager in Rhino 8 and then Object Manager in Rhino 9.
Another thought: maybe Rhino doesn’t need to solve all of this only through an Object Manager.
A more capable Worksession / Model Manager could already solve a large part of the organization problem for complex projects.
For example, I often organize complex models into separate files/subassemblies: Body, Wheels, Interior, Glass, Environment, etc.
If the Worksession panel provided a simple Show/Hide control for each attached model, together with the Active/Reference model control that is already there, it could effectively become a very capable model/drawing manager and the top level of the project hierarchy:
Layers would then remain responsible for organizing the contents inside each model, instead of also having to compensate for missing model-level controls.
I think this would already make very complex Rhino projects considerably easier to manage, even without a full C4D/Blender-style Object Manager.
I previously raised the model visibility issue here: [link]
Since Worksessions are currently receiving attention for Rhino 9, perhaps this could also be considered as part of that work. @mary@dan
Thinking about your comment regarding RH-1652, I don’t think Hide and Unload necessarily need to be two separate user-facing states.
From the user’s perspective, a model is either visible or temporarily hidden, while still remaining part of the Worksession. Internally, hiding it could, for example, unload the model, with caching used if appropriate for faster reactivation.
This could provide both benefits — simple visibility control and better memory management — behind a single Show/Hide function.
One more thing I noticed while testing Worksessions: when several models are visible, there is no immediate visual indication in the viewport of which one is the active/editable model.
Interestingly, Rhino already makes this distinction when using Select All: the active model is highlighted normally, while the attached models are displayed differently.
It would be very useful to have an optional display override for Worksession reference models — for example, a configurable transparency level for references, while the active model keeps its normal display. Switching the active model would automatically update this.
This should be purely a viewport/display override, completely independent of locked objects/layers and without changing any model or layer properties.
For printing, an option could determine whether this override is honored or ignored.
This, together with model-level Show/Hide, would make it immediately clear both what is visible and what is editable.
