In fact, it does. Layouts keep their own layer states. Also, they are, per design, the place where 2d graphics belongs.
Does not make much sense to try to emulate what they already do but in a model space viewport (with separated layer states).
On the (hopefully not too) long run, layout space can and should become what adobe illustrator, affinity designer etc. are used for, and it’s not so much missing. Place a section/ elevation/ floorplan/ 3d view in there, ‘explode’ these=make 'em editable if they don’t already look as desired, and work on top. Add/delete lines, hatches, add pictures etc , with good draw order support(!).
That’s the ‘vision’, inspired from numerous other cad/architectural apps.
I know layer set can be applied to individual layout and detail, but I would not go back and forth between model space and layout space. BricsCAD BIM exactly works like that. If you create section, it is exported to a layout automatically. However, you can not but check layout very often because many annotation works including dimensioning work need to be done in layouts. It slows down work very significantly. I would work in one space like Archicad. I think layout should be ‘literally’ layout - space for layout of individual detail view in a sheet.
Ah yes:
It would be desirable to mix layouts and model space viewports. Now, they are mutually exclusive.
Since layouts can reside in floating windows, I can’t see the strong technical reason why regular viewports cannot be switched to any layout.
Btw, this would also solve this problem elegantly: given you are creating a section view and indeed want to choose a layout as target - you easily could, when some viewport was set to the desired layout.
It feels as though a st section should be a single object that can be moved to wherever we want it (model or layout), scaled as we see fit, updated when required (and before plotting), and have a set of properties that define rules for lineweight, hatch, etc… This would be so versatile and useful…and seems just out of our reach.
Exactly.
Story: VisualArq section/plan views are, as mentioned, dynamic blocks, with parameters (e.g. which level should the plan view show).
I had a similar debate with them some time ago, because it turned out that it is already possible to put their dynamic section blocks on layouts (using ChangeSpace), and dyn. update would still work.
They agreed to implement this.
Here we are, talking about the same thing, but on the McNeel side.
That’s why I ask myself: what the heck is so toxic about layout space that it’s utterly unthinkable to use the bloody thing as intended - as the dedicated 2d environment.
Maybe people are unaware that all drawing tool work just fine in layout, except it’s 2d.
Does that now work in VA? Can you export same from the layouts in DXF/DWG with WYSIWYG functionality, so that the DWG will look like the PDF equivalent?
I don’t have anything to do with architectural work, but if VA can do this, it is getting to the point where I think it’s a worthwhile investment, simply because McNeel are getting themselves tied in knots over it and have been for years. The fact that I, as a single-member-of-staff design consultant that has to think carefully about investing in kit, should be thinking this way should send a signal to McNeel.
This won’t be in Rhino 8, but it is on the list for the future. Table objects require an entirely new object type in Rhino which is a large project to implement.
I was thinking on BOM recently.
And I’m curious, on which proprty of an object BOM should be built?
Some plugin rely on block attributes, but not all the objects are blocks.
To base on AttributeUserText? But during modeling you may loose them (adding new surfaces to polysurf, exploding and rejoining for example).
Layers? In some cases product consists of several layers, not only one.
And this should work for all designers, simple, like Move command.
But it’s quite hard to be good for very different approaches of assembly organization.
Could somebody explain the idea, what BOM should be based on?
Not yet, no.
They set up a roadmap page, which states DWG export from layouts: in progress. That’s all anybody knows on the outside, but it’s going to be in 3.0.
DWG export from layouts is a complex thing, if done right. Example: what if there are blocks visible in Detail views - will these translate correctly into DWG? What about viewports in some shaded mode etc.? Will these come out as colored hatches?
I’m very much looking forward to it, and very curious how they are going to approach all this.
Last VA released version is 2.12.6, which was from September '22.
2.13 is upcoming shortly (and some people already received a pre-release version of it). According to here it will be the last version before the 3.0 cycle.
I would like the sections to auto-update when I open the layout that it is synced with or when I print the layout. That’s how it works in Revit, it’ll update when you need it to. I’d rather wait a bit to see the updated section when opening the layout view then having it load > click update and wait for it to load once more.
Also, I think it would be sensible to get some sort of project browser that has each section/ plan/ view listed, which you can then place on a sheet (layout) for print. Otherwise it gets hard to track views.
We can already draw in layouts in 2D (and 3D object too if you desire). Don’t even need changespace command, copy and paste works fine. That’s why it doesn’t feel wildly out of reach to implement a better drafting user interface based on it.
Section Tools output could/should be an object spat out anywhere and we can cut & paste it to a layout. Even Make2D output could do the same.
This is a really neat concept but I see a problem with having it associated with a section style, and that’s that you need to be able to assign different behaviours for different objects or all similar materials will merge.
Only way I could see this working is if you a merging behaviour tab in the properties panel.
This would allow you to select merge by material or by or other key value entry (merge group?). Anyway I don’t see this happening soon
+1, too.
How else would you keep track of all the section , should there be more than just a few.
What I just noticed: when running the Clipping2DLayouts command, and it asks for the placement point, it is well possible to switch to a layout and place it there! Nice! However, when changing the section line, the placed 2d graphics falls back into model space.
I agree this will be a useful addition. Right now it is limited to triangle and line (if set ArrowSize=0)
I can see how this might make sense in some cases, but the “Dir” option is meant to define a direction, rather than a placement. You might want to set the direction, then still want to set more options, flip, place multiple sections.
In that case, what would be the height of the text? Defined per section?
You can now change the size of the section line with gumball and Rhino commands such as Scale.
So you think the command flow starts by asking for 2 points to define direction, then other options show?
@archist97 , @rajaa@Eugen
Apologies if some of these points have been made before and for intruding in the discussion without both reading the whole (enormous) thread or testing the WIP.
Not only there are thousand of elements in a architectural project, there may be several projects in architectural projects. In large scale (or even medium scale) projects, we very often work with referenced blocks for different parts of a project.
It can be repeated hotel rooms in a large hotel, or is can be repeated kitchens, in different apartments; repeated apartments in an apartment floor; repeated floors in an apartment block; repeated apartment blocks in a residential development.
I state this only to check if someone has experience with the section/layouting of referenced blocks.
Consider also that way of keeping the 3D from getting messy, is to use a different file that references the 3d files and where the 2d layouting happens. This allows large teams to continue working on the model, while other team members prepare the 2D layouts. We use this also in managing 2d information, the geometry files are rarely the layout files, which combine a geometry from different sources.
For this to happen, there are a lot of improvements needed in the way Rhino deals with blocks and the ability to manage referenced layers, update information, preserve layer states from referenced files, etc, etc.
A different issue referenced elsewhere is the need to export the layouts to DWGs. This is a really important aspect of the overall workflow of trades. As much as we would like to think that all parties work with 3d information, many trades don’t and to export these layouts in vectorial DWGs is super important, so that the shopdrawings of the suppliers are not mere guess work. At the moment the production of these background drawings for the suppliers is a not insignificant part of the time spend documenting a project.
Apologies again if this is off topic, but it has been a source of frustration the management of geometry from large teams in large projects. Any layout documentation strategy should consider this…
N
