We import architecture IFC’s and convert them to meshes for fast view manipulation, and often need clippingplanes to see different floor plans. But on some of these models the clippingplane freezes up and get’s stuck due to some complex situations that aren’t interuptable. So Rhino needs to be killed.
Reproduce:
Can you look into what’s going on? I extracted some parts of a file that reproduces the issue.
Just draw a clippingplane for perspective view on the XY plane.
Drag it upwards with the gumball.
This doesn’t happen in other apps so I would like for Rhino to update the clippingplane as fast as possible, but not interrupt my dragging if it is laggy. (Terminate calculation if moved since calculation started)
Option for not generating clipping geometry, so we can have speedy manipulation on complex files. ClippingPlaneBug.3dm (4.1 MB)
Yes it locks up Rhino 7 for me according to your description, had to shut Rhino down with the task manager. Incidentally it works in the xz plane no problem. I even took that xz plane placed it above the objects and rotated that clipping plane 90 degrees, when I moved it downward it caused the lock up as well.
I presume this is due to a collapsed mesh face or something, causing the clipping geometry to fail in generating a curve or something.
I made a WebGPU viewer that reads Rhino files and that has a clipping plane, and this works fast and flawlessly, so it is possible to visually clip this model with ease, indicating that it is something else going on, probably on Rhino’s side in generating clipping faces (fill) or intersection curves (edges) with one of the objects mesh faces in the file.
Since I didn’t hear anything about progress on this I needed to bugtrack it so we can use Clippingplanes safely. So I isolated the problem object and SplitDisjointMesh and isolated the two meshes that caused this issue.
It is two T shaped beams (See file) and if I CullDegenerateMeshFaces on them then clipplingplane works.
So the fix here would be to make sure Clippingplane handles this by monitoring objects or it’s behaviour, so if it freezes it disables the features causing it and continues to work as a simplifed clippingplane.
Priority:
DON’T freeze
Clip the geometry
Draw the clipping edge
Draw the clipped geometry
I presume generating the clipped geometry from these objects cause the freeze, but I don’t know.
Personally I would like to have this as an on/off toggle for clippingplanes anyway, so we can choose to have a much faster behaving clippingplane that works in realtime on mega-complex files too.
Tested on some other files and running CullDegenerateMeshFaces on them prevents the issue there as well. @wim tested in Rhino 9 and saw that SplitJoinedMesh also culles degenerate mesh faces automatically.
This is not a solution since it doesn’t fix the problem, but it avoids the problem. So please look deep into how Clippingplanes struggle with geometry that is “faulty”. (A collapsed mesh face isn’t faulty per say, it just doesn’t have an area at the moment and thus cause issues with ClippingPlane’s calculations)
Note that all of the files I have tested successfully clip in other software, so this leads me to think that it is the generating of clipping geometry that causes the freeze. (As stated above, but since it’s 2026 and people don’t read full threads from top to bottom any more I thought it was smart to repeat it )
)