Hi @jeff, All,
I had some discussions about these issues with @Pascal and provided some examples. I totally agree where you are coming from regarding ‘clipping faces being backfaces’, it’s only after been working with this for a few years and looking at many many many complex models that I realize that in practice this makes absolutely no sense.
The problem is that multiples goals are in conflict:
When we have multiple objects we are coloring all of them differently for clarity, because we do want to see by coloring which one is which.
We also want to see a form of differentiation on the clipping surfaces so we know what what we are seeing is actually a result of the clipping plane.
These two goals create a conflict:
If we do NOT color the clipped surfaces as backfaces we achieve goal 1, but not goal 2.
If we DO color the clipped surfaces as backfaces we achieve goal 2, but not goal 1.
…and now I want to bring out a third goal of clipping plane. The one that IMO is the ‘One Job’ of clipping planes most of the times that I invoke them…
- I want to see if multiples ocjects are colliding with each other or not.
In Siemens NX, the default is that when volumes of multiples objects are intersecting, the shared areas of collision at the clipping plane (think of it as theirs curve Booleans) are rendered with a red ‘oh shit’ color. This is of course when no object is red, and no backfaces assigned color is red. So the tool is bringing out a new visual cue/alert that something else is going on.
There are also a few more major issues with clipping planes, but another very important and very flawed is…
- when an object is not a closed solid the clipped area is not filled with anything. So it looks ‘hollow’. I can see why technically this would happen if the intersection curve between the clipped object and the clipping plane is not a closed curve, but it also happens when an object is mostly closed and might have some missing faces or naked edges somewhere else (not touching the clipping plane). This is a major problem because many times we are using clipping planes to check interference between the objects that we are modeling and reference geometry. And guess what? Rhino keeps improving but still really sucks at importing reference geometry such Step files and keep them as solids. I’m not talking about clean files of course. I’m talking about real world shitty files here. And the majority of engineering models we get tend to be some for of a shitty file. And these are Step files that are always solid when imported to SolidWorks, Fusion, Spaceclaim, etc. So this arbitrarily decision to use clipping planes as a way of telling us if an object is a solid or not makes no sense IMO. In fact I think it would be 10x more useful if the clipping plane tells us of at object is/isn’t a solid at the clipping plane intersection, not somewhere else.
Its late here, but I wanted to reiterate the importance of making clipping planes more useful. i can produce some examples of this in the next few days. I also don’t think that because clipping planes have been defined certain way in V5, now that’s a reason they should not be changed. Evolution is necessary, especially when the evidence of such need is hard to argue with.
These issues are not something that I could have suggested based on a simple opinion or a hunch, but after years of dealing with this WIP tool. Yes 10 years, old, but still very WIP. I could not have been this articulate about these shortcomings when you first started making this tool, we all need time to live with it, and then that gives us a chance to give more actionable feedback. I’d love to hear what other users think about these issues.
There are many more issues with clipping planes but these are the burning ones.