I haven’t looked at the V7 WIP yet, so my apologies if this is already implemented.
We would like to have an option that allows the clipping plane fill to inherit the colour of the object being clipped. Currently (in V6) it’s one colour only.
Thanks,
Dan
Yeah, the ability to apply per-objects or layers properties to clipping planes is on my top wish list for V7. I hope we can get this, having custom colors or hatches per-object would open a whole new world for layout presentation.
Hi Dan - If I understand you correctly, in Rhino 6, set Rhino Options > View > Display Modes > [your_mode] > Clipping plane objects > Show fills > Color usage to Viewport.
Didn’t know that feature, thanks Wim.
Hi @wim, i wondered why this does not work over here and it seems that if color backfaces is enabled, the backface color is used instead. So the clipped face seems to count as backface ?
_
c.
Hi @clement,
I see that here, yes. Filed as RH-51055. Thanks!
When you use the factory-default Shaded display mode, what does it looks like on your end?
(you could use the model that is attached to the YT item if you want to compare 1:1)
Hi @wim, when i do not use color backfaces it works as expected of course. Thanks for adding a YT item for it.
_
c.
Hi @wim,
I didn’t know about this option. It’s exactly what I needed. I do see the bug with the back faces too, but I have a separate display mode set up to display backfaces so it’s not a problem for me.
Thanks,
Dan
This is how this has always worked…even all throughout the V5 development cycle…and I believe that it was even requested to work the way it does now. Changing this behavior at this point is going to require some kind of massive agreement among all of you and possibly others, because my guess is that there are users out there that rely on it working the way it does now…the fact that no one here seemed to even know this feature existed tells me you’re not the ones I’m concerned about.
The clipping of an object reveals its “insides”… which said another way… shows the object’s back faces. The clipping plane isn’t shrinking the objects, or moving the object’s surfaces around, it’s “clipping” the object. So I think this is subjective at best.
I’m moving the YT item to a “wish” for now…because I’m not yet sure it’s really a bug.
-Jeff
This is not much of a justification, as clipping planes was for most of the V5 development cycle - how can I put this - disappointing. It started far worse than that and was a complete waste of beta tester time.
By whom??? The way it works is, indeed, a way for it to work.
Now that it’s to the point where users don’t need to use up their “special” vocabulary discussing it, it is probably time for them to speak up with a discussion of the full breadth of how it should work based on the visual communication preferences and standards of individuals, organizations and industries.
Please don’t take this personally, Jeff. You are still one of the All-Star players in the display game as far as I am concerned.
It wasn’t meant to be any kind of justification… The only point I was trying to make is that the way it works now is the way it’s been working for over 10 years…and we’re just now talking/hearing about it? In my experience that usually means:
a) It is something that nobody uses.
b) It is something that only a few people use, and it’s working the way they expect it to.
c) It is something that a few users have recently discovered, and it’s not working to their expectations.
If you can prove “a”, then I will be glad to fix it right now. If you can’t, then “b” and “c” people need to have it out.
I don’t know exactly who requested it…but I assure you, 99.999% of everything that the display does in Rhino, it does because someone(s) requested it, and not because I felt it should. This specific “feature” is not something that happens due to a bug…the code is specifically making sure that the back face setting is getting used in this specific case…which means I purposely made the code work the way it does…which in turn means…someone asked that it be done that way. But since this was done so long ago, I haven’t got a clue who the names are.
I have no problem changing it… I’m just concerned that I’ll be breaking something for others…which means I’ll then need to add yet another set of options to the clipping plane fill usage 
-J
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…
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…
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.
Best Regards,
Gustavo
It is important to avoid confusing the two main possible causes for this situation:
I believe clipping planes right now is solidly in the #2 camp.
There’s probably plenty of this too.
Regarding the threshold of usability, I’d say that I’ve have had periods of using/not using clipping planes based on the availability of a functionality that @dale coded for me back in early V5 WIP days with a plugin called GustoJunk.rhp.
This is now 2 test commands called _TestEnableAllClippingPlanes and _TestDisableAllClippingPlanes
Without this, using clipping planes in a complex file with hundreds of parts and many layers is an absolute design crime.
Today, without this functionality you might have a file where the clipping plane/s that can be in one or ALL of these situations:
…and you still have this elusive plane clipping your geometry and you do not have a way to know for sure that:
A. your geometry is clipped by a ghost clipping plane, not actually cut and capped/uncapped.
B. Have a way to find the clipping plane and deal with it.
This reality is absolutely nuts. and the fact that this has been going on for 10 years is 10X nuts.
So @Jeff, what you are justifying as ‘the reason for preserving the Status Quo’, is what’s for many of us the continuous frustration of working with Rhino: Most of the commands live and stay in continuous and precarious work in progress state, and no one at McNeel is putting the time to design these experiences, or at least no one with enough dedicated time, experience, training, capability, information about your industry, and attention to detail to do it right. Instead you are all relying on getting things soooo frustrating for us, so we have to stop doing our day jobs, to do yours, for free. This is not cool. Not cool at all.
There are so many tools like this, and I better stop thinking about it because it’s maddening.
G
Please everyone stop thinking I’m trying to “justify” anything… I am not. I have one concern and one concern only when it comes to changing the behavior of anything… Is the current behavior working as expected for some people, and will changing the current behavior therefore break it for them? That is it! That is all!
You can can come up with all kinds of glorious reasons for making the change, which I’ll admit Gustavo, you have certainly done here…but that doesn’t change the fact that changing the behavior for some will probably break the current behavior for others, and no amount of justification for that change will make that statement false.
I am not lobbying here to keep the current behavior… I am not disagreeing that the suggested change is a good one. Those two points are completely irrelevant when it comes to changing the behavior of something that potentially thousands of users are expecting it to work the way it does currently.
I’m probably completely wrong and paranoid here…but changing current behavior of something that’s been around for a while has come back and bit me/us in the behind on more than one occasion. That is my only point here, that is my only concern here.
Somehow though, I don’t think “fixing” this minor issue is going to address any of the real concerns mentioned in this thread. Clipping planes suck, I get it…but I assure you that they don’t suck because the backface material setting is being used for the fill color.
I guess I’ll roll the dice on this one since I’m obviously not getting through, and go ahead and make the change. Prepare yourselves for huge “I told you so” moment 
… but most likely this will end up with a fizzle …LOL
-J
Thanks for the context Jeff. I think explaining this makes me much more at ease with my frustration.
I was extrapolating your concerns as: “it is the way it is, and no need to change it”. That’s obviously a simplistic reaction on my part that ignores the realities of what a precedent the current functionality has already created.
You are right that disabling the backfaces appearance won’t fix all these issues. I think it would make more sense to fix at least all the ‘appearance issues’ holistically. Separately of all the other sucky behaviors of the clipping planes (some that I also mentioned in this thread, and many of us have mentioned in many other threads).
G
I know you were…and I want to make it as clear as possible that that is NOT what I’m saying… You know me Gustavo, and how fast and ready I am to make whatever change you want…but sometimes, I have to say “wait a minute, what are the ramifications of that change?” … and that’s all I’m doing here.
Thanks,
-J
A simple fix may be another option named something like “Viewport front faces” and rename the existing option to “Viewport back faces”.
Ugh… ok ok let’s try fix this.
@jeff, before I do anything, let me get some clarity on what’s feasible:
you can detect which faces are being created by the clipping plane, and to which object they belong, correct?
can you detect faces (let’s assume planar for now) that exist in the model, but are already coincident to the clipping plane?
can you detect if coincident faces with the clipping plane are overlapping? Like this:
Thanks,
G
Hi @Jeff, maybe you can just add another option to let the user decide if the clipping plane fill shows the backface color or not, so it can use the object color instead. This way nobody looses what has been there and others who think this is a bug can just change it.
Imho, it is disputatious if a clipping plane fill should show the back side or the front side and what is right or wrong about it. I think that (if the backface color option is disabled), we see the outside as the clipping plane fill obscures the view of the inside. Therefore it should show the outside and not the backside. On the other hand, if an object is seen by the user as a solid object, the clipping plane fill (or cut through the solid) would reveal the inside, or cutting face, but seen as a solid.
Not if you let the user decide with a new option. You just add functionality without removing anything. If the old behaviour is the default, i doubt someone will notice it.
btw. i am sorry if my report (bug or wish) caused so much trouble.
_
c.
