I have new three “suggestions / questions / issues” for improvement regarding current workflows:
1. Functionality of Sections in the “Background” Layer - I am a bit confused about how sections work within the “Background” layer. Currently, no curves are being saved to the “Visible” sub-layer; instead, everything is being placed into “Visible not sectioned.”
Looking at Image 1, the clipping planes “Front” and “Top” (which do not actually cut through the geometry) should logically generate lines in the “Visible not sectioned” layer. However, all other actual sections should ideally generate lines in the “Background - Visible” layer. Is this the intended behavior, or am I missing a setting?
2. Surface-aligned Hatching for Furniture Design (Grain Direction) This is more of a technical challenge. When modeling furniture, we use specific hatch patterns that must remain perpendicular to the surface of the board material (e.g., chipboard, plywood – see Image 2).
The issue arises when I create sections of a single board from two different view angles: the hatch orientation does not align correctly with the material’s orientation in both views. Is there any existing way to lock hatch orientation to the object’s local coordinate system or the board’s surface? I suspect this might be difficult to implement, but it would be a greate for technical documentation in woodworking.
3. Editing Section Blocks for Custom Hatching One last thing — how can I enter a block created by the Section tool, for example, to manually add or edit hatches? (See the last image).
The hatch for the curved plywood part should look like the one in the reference, but I am unable to use the boundary curves to manually create the pattern without exploding the block first. When I double-click the block, it only opens the Section update dialog/table.
I would like to add that this is my number one Rhino frustration, and it would be really amazing if it could be implemented in Rhino 9. Thank you @wim for adding a ticket number, it’s something my whole industry would benefit from, thanks.
Could the curves generated by the clipping drawing retain the GUID of their source Rhino objects?
I’m developing a workflow that uses leaders with user text to annotate object attributes in Rhino. If each generated curve explicitly preserved a reference to its parent geometry, I could use text fields linked directly to the original object. Then, when the parent object’s attributes change, the annotation would update automatically.
At the moment, only blocks are baked into Rhino. There is no practical way to annotate the generated curve attributes unless the block is exploded. But once exploded, the connection to the original geometry is lost, so the text-field link can no longer update with changes to the parent object.
Preserving the parent object GUID on the generated curves would make this workflow possible.
Hi @yuchouw
Currently all drawing objects apply all source object User-Text, so you can assign User-Test to source objects, and it updates in the associated clipping drawings. Does that help?
You are right in that there is no support to view the user-text of block components’ through sub-object selection for example. You will need to explode the ClippingDrawing or run BlockEdit first. @Trav may be able to elaborate. However, using scripting, you should be able to traverse block components and view/annotate drawings with their user-text.
Clipping drawing to annotation. Regardless of source object, just explode the clipping drawing to annotate. Or like you mentioned, traverse block components.
Source geometry to annotation. Regardless of clipping drawing, text field will link to the source object directly.
For the second workflow, every time after changing source object user text, I don’t need to update the clipping drawing, then redo the annotation with scripts to traverse block componets. Because they are linked directly to source objects, it will be easier to maintain the drawing.
So the structure is changed from:
source → clipping drawing → text field annotation
to:
source → clipping drawing
→ text field annotation
My personal way is to first write guid to source object as user text, then do the clipping drawing.
yeah, exactly. That’s what my team is developing, to build a quick drawing generation workflow for structural and mechanical element with low maintain cost.
I really like the feature of new sectiontools, it will replace make2d of course. It can be better!
I would be hesitant to add a “Source” user-text to all drawings objects. You can always add user-text to source objects with their GUID using simple script, and this get carried to the drawing elements. Would this be sufficient? @wim can you also add your thoughts here?
yes, these days I was also rethinking about the text field behavior. because sometime the source would be block as well. and not sure if this feature is useful to other users.
I don’t know if it’s possible, maybe exposing the TextFields class to user, then let user make their own parsing functions. So that Rhino can be intact.
Anyway, current workflow that setting the guid by myself is working.
