it is possible to have multiple viewports, using different documents on each, at the same time? Or can I only display one document and in each viewport I have to hide everything I don’t want to visualize?
I want to preserve each state of a model in different viewports. I have several viewport controls and I would be ideal if I can work with different documents, to avoid having a lot of hidden geometry in the ActiveDoc. From these viewports, I only need to rotate the camera and via double click it instances that state of the model in the ActiveDoc.
Speaking for Rhino for Windows, which is a single-document application, the only way I can think of is to use either linked blocks or to use a worksession. Of course, you can open additional instances of Rhino, simultaneously.
The Mac version support multiple documents. So perhaps it provides an additional option.
I guess I don’t understand what multiple modeling spaces means. I might need some clarification on this.
Well, space is something abstract in itself, but in essence I refer to all forms of measuring geometric-user interaction, in particular the viewport (which allows you to see, create, modify… a model) and also the document or file that stores all the model information. Having these two things together in the same object makes sense to me.
Do you know why? or what prevents Rhino for Windows from being a multi-document application?
I don’t think it’s enough with blocks, but if you have any ideas let me know.
Under the same application or in different executions?
It would be cool to be able to dig through different documents simultaneously. I think it would improve the user experience when working with complex models. But what I’m looking to do is design a smooth workflow to define data-based models from a plugin.
Rhino for Mac is multi-document because (I believe) that’s how Mac applications work. I think (in general) its not possible to run more than one instance of a Mac application.
Rhino for Windows, on the other had, has always been a single-document application. I’m too old to remember why. Perhaps it had to do with the state of hardware 20+ years go. Plus, Windows allows one to run multiple instances of an application. So there’s never been a compelling reason to refactor the product (IMHO).
You’ll need to post this question in a different category of you want a more complete answer.
Also, we know the worksession API is incomplete. For example:
From a plug-in, you’ve always been able to access multiple documents. In C++, use ONX_Model. I RhinoCommon, use File3dm. But on Windows, the UI is controlled by the one and only document opened by the user.
I just came across the new RhinoWIP LayerBook and it has the same workflow/user experience problem as other features in Rhino, which are not fluid to use. Since you don’t have different documents open, you have to work on the tutorial document instead of working on it separately. Yes, it can be done, but it is not a fluid experience. Although I think the LayerBook is a good add-on.
If there are very deep limitations, I would like to put other approaches on the table. Could the layers be associated with a viewport and only be shown in that viewport? So that only the geometry of that layer is displayed/interplayed by only that viewport?
That’s good to hear. I was just looking for a proof of concept, there’s no rush. I’m very interested to know the reason for this limitation. We have a RhinoDoc.ActiveDoc, but we have no inactive documents available. Which libraries take care of all this (document/viewport) stuffs? Are any of them in your github? Can you shed any light on this, even if it’s speculation? Do you think it’s because of how the Rhino architecture was designed at the beginning or is there a technical limitation for some reason?
This was just how we originally designed Rhino for Windows. Rhino for Mac and now compute need to work with multiple documents in a single instance.
Many if not most plug-ins and components were not written to be aware of the fact that more than one document can exist. RhinoApp.ActiveDoc makes this complicated as so much code uses this function which doesn’t make sense in cases where multiple documents exist. We have been fixing this in the core over many years due to requirements of Mac Rhino, but we don’t have control over what is produced by other devs.
I am currently working on support for extra inactive “headless” docs in the WIP. You will see support for this in next week’s WIP with a new version of Grasshopper’s “Import 3dm” component. The component will create “headless” RhinoDoc instances and output referenced geometry that can be inspected the the “Object Details” component. Since the new component internally creates a headless doc, it can use all of the file formats supported in Rhino for reading.