Dear @rajaa is there a way I can avoid having my Grasshopper content clipped by a clipping section without baking?
The grey mesh with curvature display is
Can you please share your files, and the version of Rhino you are using?
Sure. I’m using the latest Rhino 8 BETA.
Here’s a sample Rhino file and a Grasshopper definition:
gh_clipping_problem.3dm (146.5 KB)
gh_clipping_problem.gh (2.8 KB)
Thank you. This does look like a bug. Logged here…
2 Likes
I think I posted about this as well thinking of it as a bug 
and now, to be the devil’s advocate, I see it being beneficial if you were using a workflow where, instead of baking, you are mostly previewing geometry on the GPU via Custom Preview to save file size and baking computation time.
However, I think this opens up a can of worms with Custom Preview related to hatches, section fills, and so forth.
Just food for thought as it MAYBE could be nice to have the option to effect GH preview geometry but by default should not…
1 Like
@michaelvollrath I can see a case where if the ClippingPlane in Rhino is set to clip “ALL” objects, then it clips all GH objects as well, but ideally, there should be a clipping plane component in GH that can be set to clip specific selection of objects.
3 Likes
Thanks for your response @rajaa ,
A clipping plane component in GH would be ideal and it makes sense to have that separate from Rhino.
This has actually been a wishlist item of mine for awhile 
2 Likes
I have a cutaway material to my wishlist
1 Like
Related:
1 Like
Awesome, thank you @maje90 this is how I’ve created section cuts in Unreal Engine as well (working in shader space) I then would have the backfaces of cut objects be set to a poche color with 0 reflection, specular, etc. so that it “looked” poched/solid filled but technically it was open as you see in your GHGL section cut but just didn’t receive or reflect lighting information.
that should be possible by using the plane as a big mesh quad face, and doing the opposite trim with the cutted object.
Actually, I think the best “tool” devs should aim to in this field is a mesh-mesh clipping (always on shader space).
Planes are boring!
Let’s have a custom mesh to do the clipping of another mesh!
By counting odd/even z-depth passes and checking which of the two meshes is visible, we can literally do a fake solid boolean difference/intersection, real-time! 0 cpu load at all!
(google “opengl depth peeling”)
I tried to pass shader buffer from a ghgl component to another, but failed big time.
I asked Steve for help but … in the end I couldn’t reach my goal.
Today I remember absolutely nothing of how openGL/ghgl works 
2 Likes
Yea the nice thing with the shader method is you are essentially creating a clipping mask and it works with any shape (in Unreal) so I gave users the option for Sphere, Box, Plane, Multiplane, etc. and the section plane was not a plane but rather a “section object” of specified shape/size.
I wonder how one would calculate volume differences/area differences on “fake booleans” though. That’s one of the big issue I see (with a workflow of needing accurate area take offs)
I’ve been oscillating between the new bake components and pushing as much “geometry” to the GPU as possible lately. I’m trying to find the balance between visual representation of all objects (covered pretty well with Custom Preview (now that it accepts Rhino Materials)), performance overhead of geometry modification in regards to dynamic/live baking, and still having the ability to “snap” to referenced geometry. Furthermore, I still need everything to be able to print to vector .pdf if called to do so…
My ideal scenario would be that geometry is on the GPU, visualized as needed, yet points/lines of said geometry could still be snapped too for further geometry creation/manipulation in Rhino. This last bit (i think) is quite tricky?
So would it be possible to create a cutaway material with a PBR material?
PS: ten years ago today I joined discourse
2 Likes
I’m going to step out of my knowledge and say yes. How, in GH is the question though.
Happy anniversary! 10 years you should get the whole cake not just a slice 
Thanks Michael 
I’d think the material would be created in Rhino and then referenced in Grasshopper.
1 Like
Perhaps too in the future when more material/UV creation support arrives in Grasshopper native components it can all be handled in GH and then optionally baked to Rhino
1 Like
Just to clarify a bit since this thread has taken a bit of a wandering course. We do plan on adding native support in GH for clipping/section planes. However, until that happens, we reviewed how GH objects are currently clipped by clipping planes and this behavior is the same as what happens in Rhino 7… so changing any behavior here would be a breaking change from how things have been working. I think I’m hesitant to make any changes like that until we really dive in and provide native support for section/clipping planes directly in GH. When we do add this, you’ll be able to provide full control over what does and doesn’t get clipped.
In addition, we do plan to add greater controls for material creation and UV mapping, but that is a much larger project and will take some time (likely years) to really pull together. Just a little clarification.
2 Likes
Fair enough.
Clipping sections were introduced in Rhino 8. I thought there could be an option in a clipping section style to exclude or include Grasshopper content would be nice.
@martinsiegrist Agreed. It would be nice… but the internal structure of how section/clipping planes would work was fluctuating as it was being developed… so we decided to hold off until that was settled before adding support for it in GH1. As I said, we do anticipate adding support for those data types as soon as we can.
1 Like