I really want to View Modelspace and Layout space at the same time! See Attachment.
I’m not talking about Viewport Tabs, or Floating Viewports… I get that. But moving Rhino to another Desktop Space when there are several disconnected Windows is a PITA, especially if you have massively hi-res monitor and CAN fit workable side by side Viewports.
I’ve spent too much time trying to hunt down a command item and moving around Viewports… only to wonder if it is a limitation of OpenGL / or Rhino. I understand that Layouts are rendered maybe differenly compared to Model spaces… but don’t know why it wouldn’t be possible.
Also, I see how Layer States could complicate this… but Rhino is nothing if not Complex!
Thanks Mary Ann. I appreciate your correspondence on this. Floating Layout is pretty workable, but here are some features that would make it more efficient:
First off though, Toolbars also suffer from abandonment when moving desktops, however I’ve made my peace with this through carefully tabbing, docking and layering of toolbars so their are no floating toolbars
However, Viewports are critically associated with the specific .3DM file you’re editing.… and so should hang together, by default.
The real issue here is how tedious multiple monitors, multiple desktops, etc are to navigate, when a program doesn’t drag all it’s siblings along with it, whether Viewports or Toolbars.
Here’s what I’m looking at:
Model Spc Layout Process (New Annotated):
5% or less of my labor in the Layout space (Left 1/3)… since objects created IN Layouts are not associated to model space, I prefer not to waste time belaboring changes in the Layout… Rhino’s tabbed layouts are great.
95% of the real work is done exclusively in the Model space (Right 2/3). The Floating Layout viewport is paper sized and serves as a PDF preview of Client or Vendor Deliverables.
My workflow annotations: CAD Data and Details in (Blue) are sent up to A (Red) Elevations and B (Yellow) Elevations, or over to Vendor .DXF output in (Orange).
Layer settings and Layer States in (Green) allow Control over the Layout plans (and PDF ultimately.)
Rhino has developed a great system, but it’s complex and hard to learn best practices… on the 2D drafting side, so I guess we all just make it up as we go.
On Drag, or on Float Viewport command Let Rhino calculate the remaining display area away from the Main window, and then Snap/Fill it 100% with the Layout.
Secondly, If another de-docked Layout is brought close to an edge… Let them split the space 50-50, similar to your Toolbar behavior.
How and where: Have one Tiny “Thumbtack” or Magnet icon on the layout or menu that will cause it to Move with the Main Rhino container from which it was spawned. Or make Move w Parent the default, and a Break Link icon.
Hello! From a usability perspective: Is there any good reason why model and layout space viewports should not be mixed? Meaning, why can’t any single viewport just be switched between model/layout?
I know this is an age old tradition, but why actually? It can be quite useful to keep model and layout space side-by-side.
I have had the same question. I had assumed it’s a display / coding limitation, but I’m not sure.
Yesterday I discovered you can apply the Rendered mode to a Layout window and can then see Decals rendered as bitmap textures! … and leads me to believe they might be more compatible than once thought.
Either we disagree on nomenclature, or this isn’t accurate.
I would use Instance to mean Rhino.exe and we’re not talking about two executables.
I am displaying the Model Space and Layouts from a single 3dm file, as shown in my Screenshot . I have floated the Layout window… standard stuff. All we’re talking about is whether the floating Layout can be pinned (good) or docked (best), and how it could work in some future version.
