Clipping Plane Fills! Please

Alan’s post up near the top about Section Tools is what I would now echo.
I’ve gone back to it. I find Section Tools awkward, but it’s the only efficient reliable way to create fills, and as far as I can tell it’s the only way to do it on some open polysurfaces.

But I’m only using it to create the fills, and using clipping planes* for clipping sections. That’s because though the st fills appear in the model in any view, the st section can only be set to clip in one view (as far as I can tell) which means clipping planes are required for every other view. This means creating a clipping plane plus a Section Tool section for every section view (except one).

It’s cumbersome, but it’s the only reliable way to create section fills, as far as i can tell.

*that’s for 3d view viewports. For 2D views I’m using VisualArq Section/Plan Views (not make2D) because they’re updatable. To align 2d views with st fills I move the 2d views to where I’ve put “stLayouts” (the name st gives for stfills placed independently from the model in the project). I don’t move these stLayouts to the 2dviews – 2 reasons for this 1) stLayouts can’t be placed with precision when they’re generated and 2) they can never be moved (stMoveSection only moves the plane where the section intersects the model.)

Maybe this points to a resolution.
Mayeb a one word command trigger this script in this post: Surface to hatch (inverse of explode hatch)

Maybe spend a couple of hours to understand and combine the two scripts. Create custom toolbar and button and make the button run the script? :thinking:

That doesn’t sound like much work for a developer or someone who codes but it seems like a lot more than two hours’ work for someone who knows nothing of coding (like me, for example.)

What frustrates me is when someone is assuming that people don’t have desire to learn because they are not willing to code every simple stuff by their own. Especially, when there are a lot of users asking for the same functionality to be added/fixed/enhanced.
A day for all of us have only 24 hours and some people just want to keep healthy proportions in time spent between designing or actual work and workarounds, coding their own tools.

I can agree upon that nowadays with current tools, being a 100% designer is not the best strategy. But when it comes to highly demanded, not very customized tools and options (like one mentioned in this thread) it is alright to aks for them.

This is an opinion from the person who finds a lot of satisfaction in forging his own tools. Unfortunately, at the end of the day, the design is what I am asked for (and what my initial goal was) and no one cares if I made myself a script in the meantime.

There is always not enough time for the good design and a need for smart tool is what brings people to Rhino. Many of them are hoping that with Rhino they can spent more time on their work, but instead of too often they are hearing that it should be the opposite - more time on custom tools/less on the design.

And again, I would like to emphasize that I personally like to spend time on developing tools, getting to know them better, but sometimes it goes to the extend that is ridiculous.
I got a huge respect for this community and their plugins - especially for the grasshopper, but I understand the frustration of some users.

4 Likes

On the other hand…whatever.

I am back to hatching manually for Section FIlls.

I’ve found that Section Tools will too easily corrupt itself if it’s present in a detail window. Some actions (I’m not sure all of them, but one is copying a detail window) causes all project Section Tool elements to suddenly become present in Layout Space and disappear from Model Space.

@rajaa

Yes, you cannot trust third-party plugins to do what you want them to do. (even if the 3rd-party is McNeel themselves)

Btw, you should start a new thread reporting this issue under section tools category in this forums.

Good Idea.
I keep looking for one but still can’t find it.

I believe it’s under Serengeti as a sub-category

Hmmm…I am mistaken apparently.

Just create the thread under Serengeti.

Perhaps because Section Tools is still under development it has not its own category yet.

@Asterisk @Bogdan_Chipara @djhg @osuire @wolfius
I want to revisit this topic because I have some ideas to make hatches in drawings (semi) automatic with a script. I’m thinking about making different hatches based on material or other to be defined criteria (in principle target at use in layout space but might also work in model space).
So I wonder on which criteria you would imagine hatches to be different. Do you do this per object properties, material, user text, layer or maybe otherwise? A simple example file would also be helpful.

Well, I’m thinking It should be like everything else in Properties. Default should be By Layer, then By Parent or custom.

image

this is what visualArq enables. But yes, Rhino would ideally have that (without an additional plugin that is used to a small part of its potential)

Since I will solve things with a script I won’t be able to add these kind of things to the Rhino interface. But I might be able to assign a marker to objects that I can read out in a script to use for deciding which hatch it should get.
In that case the workflow would be to first add markers to objects in the scene that you don’t want to have hatch based on the layer it is on. Of course it also means I need to figure out what is the best way to assign a hatch pattern to a layer since there is currently not such association.

Btw the script will only serve as a workaround and will in the best case be a prototype to explain what we want to have implemented in v7

1 Like

Well, best to have it in the interface, so maybe it should be done in V7, together with snapping on the resulting hatch boundary.

I fully agree this would be the best. Until that time I aim to make something useful that can reduce the pain of waiting for that to happen. Snapping to the boundary might be simply a matter of extracting the fill surface edges although I have no idea what happens with those curves if they are flush with the clipping plane.

What I have in mind would be (after a to be defined set-up) a two button solution. One to (re)generate all hatches for all clipping planes and one to remove them from the model.

You can do some GH. Add custom patterns for contour lines… It’s in realtime.

1 Like

is it really that difficult to implement such simple funcionality once well and for good ?

I am running to these issues right now too.

Fills only work with basic geometry. Not on geometry within the blocks, which is a bug definately.

1 Like

Make sure the display mode shows fills.

The strange thing here is that I made a custom tool that extracts the clipping data and it appears that the clipping data for many objects are available, just not visible in the view.
@wim do you know who that should be addressed to? It seems like a bug.
And I have also noticed that the clipping data is shown facing the wrong way: