One viewport, one document, one love


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.

What do you suggest to do this?

(I am using C# and Rhino WIP)


Hi @Dani_Abalde,

Have you considered using Layouts? Or am I not understand the problem you are trying to solve?

– Dale

No, Rhino layouts are in page format and I need a list format, and especially not in the viewport. But thanks!

This are three Rhino sessions, three pairs viewport-document. Would it be possible to put a list of these pairs on a Rhino panel control?

Or is there a reason Rhino doesn’t support multiple modeling spaces?

Strong question for a Monday morning? :cowboy_hat_face:

01:50 in the morning would be pushing it no matter which day of the work-week we are talking about…

throw new InvalidJokeException(“01:50 in the morning would be pushing it no matter which day of the work-week we are talking about…”);

Hi @Dani_Abalde,

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.


– Dale

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.
I did not know this, it seems incomplete (why it doesn’t have a setter?) although I have not understood how it should be used. What was the intention behind this?

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.

Thanks :slight_smile:

Hi @Dani_Abalde,

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:

Rhino for Mac doesn’t support worksessions yet.

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.

– Dale

I changed to Serengueti-developer, if some admin thinks another one is better, it can be changed.

Thanks for your time @dale.

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?

You can already do this with Layouts.

– Dale

We are heading in this direction as a capability, but we are definitely not close to having this as a reality yet.

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.

1 Like