Clipping Plane Fills! Please

I was about to ask you :sleeping:


assign a material (texture) to that clipping plane and it should work (or simply copy over the clipping plane from the file I posted to see its settings)

1 Like

Are you sure this is correct?

well, I mean no bitmaps

There’s the catch, so you lied

same thing bitmap = texture :smiley:

you almost got me

He did lie. :stuck_out_tongue:

and here’s the image I pulled out of the material:

guilty as charged


So, I played with materials to emulate clip hatches. It’s not easy/simple or straightforward. It’s also a huge performance killer. The more objects clipping plane cuts through, the lower frame rate you get. It’s not gonna be viable for medium to large architectural models. You’re going to hate life even setting up your views in your details.

1 Like

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.


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.


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.