Rhino WIP Feature: SectionTools Enhancements

Sure!
So think of a building model in Rhino, where each object has a bunch of data stored into its User Text Attributes. Data such as material, cross-section, and maybe some specific text tag.
If I create a section of this, it would make sense to use the new SectionTools. And in this case it is crucial to get some reference to the source object, so I can i.e. automatically annotate the section using Grasshopper. So I would like to generate leader lines, text dots and whatnot using a custom Grasshopper script.

If each clipping plane object would carry its source object GUID with it, I could easily use Key Value Search for each text tag and find the source object (Curve, Line, Brep, Mesh, whatever…). For example I could automatically place leaders to each object with text [objectName]_[crossSection].

So think of it like creating section drawings in an automated fashion, either by defining the Clipping Sections manually in Rhino or by Grasshopper itself. Nonetheless, the source GUID’s are crucial.

Does this make sense?

does zoomclippingdrawing also aligns the view to he plane of the drawing?

Hi Tuomas -

The point I was trying to make in my earlier reply to your question is that all of that user text is automatically copied onto the geometry in the drawing. You don’t need to first find the parent geometry to then extract that user text. Am I missing something?

Hi Ivan -

No, zooming always just zooms to the bounding box of an object.
-wim

There a specific tools for this.

so what is the fastest way to get clipping drawing to layout? i just want to define my clippping plane in model space and make a detail view in layout in fewest clicks. ideally i would just drag and drop from some list of clipping planes and got asked about the scale.

Yeah I get what you are saying, but it would be even better to get the source GUID automatically (as Rajaa suggested earlier) “Are you asking to add to add another user-text as follows:
Key=Source, Value=“GUID of the source
”.

Consider this scenario:
I have a building modelled in Rhino and each object has some meaningful properties attached to them. Here I am using Grasshopper’s components to create the clipping plane and get the section data, but the problem is that I have no way of knowing whether the white slab curves originate from the same source object or not - since there are holes in the slab and multiple curves are generated for the same object. They do carry their User Text Attributes with them, but that is of course not equal to having a unique tag/ID with them.

So with the current setup, I can manually have a step where each objects GUID or some other unique tag is written to them, but I would assume it is very easy to just have that automatically written to each object.

That would then allow annotation workflows like:

  • only show the tag once for a single object (not every instance of the section curves)
  • are all the objects annotated?
  • display the area or volume of the objects

So in my opinion, the GUID of the source is much much more useful than just its User Text Attributes.

Hi Tuomas -

Thanks. I see how this makes sense when automating a workflow. Of course, when you automate, you can easily pass more information to the process.
We’ll take a closer look at this.

Hi Ivan -

When the detail is active, you can select the block instance from the Block Manager or by running SelBlockInstanceNamed. Then zoom to selected.
-wim

I guess @Sebastian_Blum mean this:

Typical assembly wall is a set of stacked extrusions with a butt/miter joint.
To create continuous hatches, you need to join them together, which makes them almost uneditable.

I’ve put the request on the list as RH-92619 ClippingDrawings: Merge Common Sections
-wim

sorry for my late reply. This problem occures when clipping or extracting drawings, if you don`t use boolean union. If you use boolean it becomes almost impossible to change and, if you do to many boolean opperations the geometry gets destroyed. This works in Archicad, Revit and Visualarq (if you use their elements)

Slab-Roof Intersection 400

not hidden intersection line

I’m struggling with section tools.

Each of my section is set to Auto-update, yet when I removed everything the content is still there.

Also, nothing happens (no change) if I update each clipping plane individually or globally (All).

Another bug:

The global change for annotation style makes no changes

only individual:

I also wish to be able to change the rectangle size. This is just too much

Auto-Update happens automatically when moving a clipping-plane, but not when adding/deleting objects. You need to run UpdateClippingDrawings command. Does that help? If not, can you share the file?

I am not sure I am seeing this. I selected “all” clipping planes, then change the annotation style.

It seems to have applied to all

Where would you see the option appearing to specify the size?

Thanks for the video. Indeed, in Rhino those are treated as separate objects (unless Booleaned as you said). When extracting drawings though, hatch boundaries and curves are put in separate layers that can be turned off. You will see continuous hatch, but you will loose the outline curve. Not sure if there is an easy way to solve this.

Turning off:

Hi Rajaa

Thanks for your reply.

  1. My post started with not being able to update the drawing using this icon:

image

It was my second experience with Section Tools. First one was enthusiastic, the second one not so much.

  1. I was thinking that the scale of the section plane symbol determines the clipped area, pretty much like in Archicad. Unfortunately (for me), it goes infinite, which becomes a problem with complex scenes with many objects. If we can control the depth, why not the footprint of the CP? I know how regular CPs work, but I was hoping Section Tools brings it to the whole new level of functionality.
  2. The size of the rectangle could be hidden the Advanced settings in Options panel. Besides, can you come up with anything other than the rectangle?
  3. the problem with global assigning the style could have been the hiccup of my system.

Added support to place all drawings in one global layer. Please try this feature in the Rhino WIP and let us know what you think.

What I am struggling with is that there seems to be no clear way to control hatch color and hatch lineweight independently from boundary color and boundary lineweight through the layer settings. For me, it becomes a real mess when trying to control each element as in the references below. Some of this seems to be handled through section styles, but section styles also partially override the usual print color / lineweight logic, and vice versa. At the same time, I cannot find a clear setting that defines the lineweight of the hatch pattern itself. Somehow it is connected to the layer print width. The lineweights or hatch and boundary weights also do not seem to match properly, even when the same weight is assigned. In some cases, a 0.50 appears much thinner than a 0.13. The background also does not seem to show up in the layout. See the reference above.

Another issue is the line hierarchy. In section drawings, load-bearing elements should read heavier than non-structural or visible elements, but at the moment the order and weight of the lines often appear in the wrong arrangement and do not seem to be adjustable. Also the boundary comes before the hatch, which is often not the case especially when using colors/greys/non-blacks. Or is there a way to control this that I am missing?

The most important point for me is the printing setup for layout export. I need reliable control over how boundaries and hatches are printed in the final drawing output, not just how they appear in the viewport.

There should be a setting somewhere that allows a clear print override for these elements or just a solution that let’s you somehow force settings.

Also, scaling is hard to understand. But that is another issue.

The kind of output I am aiming for is:



Note that we need control over boundary color, boundary lineweight, boundary linetype, background color, hatch linetype, hatch lineweight, and hatch color, either per elements or per layer, including control over their arrangement and hierarchy.

I cannot stress this enough: all of this is part of the grammar of drawing. If something has the wrong lineweight or color, it can also cause problems during construction. This is not just a feature; it is essential. Otherwise, it is not really usable.

Edit: I am also getting confused by the terminology itself: print width, lineweight, etc.

Hi @rajaa - now it looks this tools very nice! Thank you for your hard work!

Just one problem persist as in Rhino 7, 8 … Man can see lines behind section which must be hidden but they are visible in “visible not Sectioned” layer even though man uncheck “hidden” in task window. Interesting - not all this lines…

Can you please share the file where this issue happens?

Hi @rajaa Yes, there is. See Markups…

example.zip (1.6 MB)