you get by default primitive A when section lines are just set to some special line width
in B section recognizes same “material” and automatically joins two objects in section
in C which is basically how things are drawn is that when it is for example concrete pier and footing there is just a separation line between those two shapes (meaning different times of concrete pour)
So some setting inside section definition should determine what result we expect and what is the rule to determine if the material is the same (is it on the same layer, is it the same section style and on same layer, etc… can elaborate then)
This is why i strongly recommend general definition of section styles and assigning them, not how it is handled now. you should have some place to define your section styles and appoint them to the element not define it in place.
BUT generated section is always raw stuff no matter how meticulously you set all the settings.
You always need some changes to the output so by associative changes i mean that you just click on any element (line, hatch, …) generated by section and can override the style (line type, hide entirely, change color, width, …). Maybe in this mode of postprocess all resulting curves and hatches would be split temporarily by adjacent objects…
And please realize make2D is not a future. We need dynamic stuff, everything related to make2d no matter how much semidynamic it is it still requires exploding the geometry which is a nogo. (with exploding geometry i can achieve everything but its where we are right now).
I’m starting to see the picture. I’d like to gather more examples about workflows and requirements. Thank you for sharing the concrete example.
Just to elaborate about some low level functions to help clarify my point: SectionTools dynamic layouts use the HLD functionality that is what Make2D uses, so if it becomes available in Make2D, it can be supported dynamically as well.
-you have your 3d model as detailed as you need
-you have well defined section styles for each element
-to define a section you ought to be able to define:
which objects are included (maybe selecting by hand or by some rules include if and else, …)
trajectory of your section ranging from simple finite plane to whatever single curvature finite polysurface (with curvature and kinks or jogs)
direction of the section and depth of the view behind (sections are useless without the content in the background
settings how outlines should be highlighted
setting how two adjacent solids with same material should behave (merged hatch, different separation linetype,…)
settings how outlines in the connection with air and with other materials should be (normally in drawings interface between material and air (in model air empty space) is heavy line and material to material with finer line)
settings how hidden lines should be treated, if visible, global overrides, etc
settings of how objects in the background should be displayed (when not touching section plane override color or dont display hidden lines of those objects which dont touch section plane (usually those objects are not of so much importance to clutter your drawing)
all of the above create a definition of a section which could be listed under “section definitions”
once you place your section-view somewhere either layour or model space you define the scale of it
when it is placed you can make associative changes to override parts of the generated section-view (change linetypes, overides styles, …) these overrides are listed somewhere under maybe “associative changes to section-view placement”
when your raw and postproccessed section is ready you can start to annotate it further, adding some line work when you need to add some details which were not there in 3d, so on and so forth
I think this is THE workflow which basically all you need and there is nothing more to add. it is perfectly well defined and only way to go.
default edges in section (linetype, width, color) *including that it is not displayed in section at all
hatch for the fill (basically all the hatch settings available including combinations of hatch and solid fill)
how hidden edges of object should look
how object should look when it is in the background
So everything how things look per object would be defined per object and within section definition special cases and overrides would be defined as i mentioned in my other post.
I think i am an expert about this and there is no program in existence which fullfils properly of what is required for drawings when you actually want your drawings to be derived from 3d model. (not revit, not allplan, not microstation, not rhino, not anybody)
Curious to learn why they were not useful in your workflow.
You should be able to do that if you reference the NamedView of the section. Is that what you are after. I’ll make a more detailed outline of SectionTools workflow in the RhinoWIP to help explain.
Well, that’s exactly the opposite of what I meant. Looking through a Detail view, even if this detail is in layout space, is just looking into the 3D scene. Which results in all the hassle with layer visibility and placement of the 2D elements in 3D space.
That’s what I tried to say: you seem to shy away from the fact that 2D drawings should be placed into layouts, because layouts are the perfect 2D drawing environment. At least they were envisioned as such a long time ago.
There’s even the cool ChangeSpace command, which beams objects between layout and model space.
Can you elaborate why you chose to place the 2d output of the section tools into 3d space? Is it a technical problem, or do you just not get the picture? (Meaning no offence).
If you look at Revit, ArchiCAD etc., these programs have of course dedicated 2d plan views, for good reasons. Rhino should in my opinion go down that route, too.
I hear that you have a preference to output and manage 2D drawings in layout space instead of referencing them from the 3D space XY-Plane. You mentioned 2 hassles:
managing layers visibility, and
placement of 2D elements.
I’d like to understand your point more clearly to see if we can bring improvements to the sectioning workflow, but first, have you used SectionTools to produce and manage 2D drawings?
Its been discussed in other threads. Other software has dedicated 2d modelspaces, where you can draw 1:1 and those can be displayed in details in layout/paper space. The way i would imagine this working, is you just add a 2d modelspace with the + icon of the layout-tabs. This could then be used either to just directly draw in, or as destination for make2d or section tool results.
Thinking of it, it wouldnt have to be a 2d modelspace, could also be additional 3d modelspaces. But i agree with rajaa that this could be done with layerstates and a single modelspace as well in principle, but for some workflows it might just be tidier/easier to seperate geometry in multiple modelspaces, especially if you work with tons of layers.
I’m not arguing against having things like dedicated modelspaces. They don’t currently exist in Rhino and is a reason model geometry ends up in a detail instead of directly on a layout page.
I have used VisualArq section tools many times, which work quite well and straightforward, and follow the known Rhino logic, so to speak.
Are you familiar with their toolset? In many ways, it’s exemplary. (The catch is, the plugin costs almost as much as Rhino, and it’s for architects, so many of it’s capabilites will be useless for non-architects.)
I tried your section tool a few times, and found it comparatively cumbersome. But since it’s going to be the ‘freeware’/built in alternative to VA sections, for my colleagues in the office it will be the way to go, and that means, I am going to use it too, one way or another.
VA: you don’t need to tell the section wich objects to section. It takes all in it’s “view range”. No need to edit a section object list. Should objects be excluded, they have to be put on layers and turned off. Also, there’s a clipping toggle per object in the VA section properties. (I’ve already posted it, but here it is again:)
VA: The section itself can be selected like a regular polyline, and thus the regular transform commands (move, rotate, scale). and control points, which can be turned on with PointsOn command. No special move/rotate commands necessary.
In SectionTools, you don’t have to select the objects to be sectioned. You can section through all visible objects. Just “press enter” instead of selecting objects. This is the common workflow.
The latest Rhino WIP use is a new SectionObject and the old hint is removed. Sections now can be selected like other Rhino objects, and can move, rotate, be copied using regular Rhino commands
Sections can be flipped too (Use Rhino Flip command, or flip through the properties panel)
You can now set sections depth (command option), but also will be included in the panel. Adjusting depth with grips (control points) is on the wish list.
No support for jogs, and no support to change the mark type, but both are on the wish list.
Yes. If dynamic sections were placed on layouts, they would need a scale parameter. (Just like in ArchiCAD, Revit and the likes.) Shouldn’t be a problem for you guys… ; }
VisualArq creates dynamic blocks, btw.
If you place lines which were auto-created by some section tool on layouts directly (NOT via Detail view), they can stay on the same layers as the original objects they were created from, because what’s put into a layout is visible only there.
The question is, do you want to invest into such a workflow? Utilize layouts to their full potential? It’s elegant and future proof. DWG output, 2d overwrites, … the whole story.
I just installed this week’s WIP… I didn’t before because the improvements you mentioned weren’t listed on the WIP download page, so I thought they are just upcoming, and didn’t test it. Sorry.
I must say, this is much better! So thank you very much for pushing this thing forward!
Yet it eludes me how to get these section hatches to be shown:
Edit:
I could trick the dynamic section into layout space (ChangeSpace),
… but the moment you change the section, it falls back into model space (of course it does).
Would you mind thinking about it? Dynamic sections on layouts… that’s the champions league!
Glad to hear you see improvements.
So if the input object has hatch properties set, you can choose as a section to show those or not.
When you rus ClippingSection command, there is the “Output” option, that you can set to show curves only, surfaces, hatches, or all. Does that help?
Do your section tools (for R7 and earlier) bear any similarities to what is planned for R8? If so I wouldn’t mind playing around with them. I don’t quite have enough free time to actually try out WIP.
I recognized that gazebo right away! And thought the name ringed a bell as well; is is quite recognizable after all…
@Eugen Thanks for giving it a try. I appreciate your feedback.
Found the misalignment bug and fixed it. You should see it in the next WIP.
As for the hatch in layout (when you run Clipping2DLayout command), did you set “ShowHatch=Yes”?
I’ll look into adding support to move section-lines, scale, etc. That should help with positioning. Currently is goes through the center of the boundingbox of the objects it sections.
I’ll look into what it takes to make Layout reside/remain in the Layout Space.
Hi. Rajaa. Nice to meet you here.
I have a quick question. Is is possible to set different 1.Color, 2.Linetype, 3.Print Width, 4.Print Color for section and projection through new Section Tool. Actually, section tool have not supported this so far and this is the biggest reason why I have not used it. VisualARQ supports this. One object is represented as a section in a section drawing, but also it is represented as a projection in another one. This function is very critical one for architectural drawing. Does new section tool support this?
Thanks.
and there is no program in existence which fullfils properly of what is required for drawings when you actually want your drawings to be derived from 3d model. (not revit, not allplan, not microstation, not rhino, not anybody)
