Clipping planes still too painful. Will it get better before V6 launch?

[gustojunk (Gustavo Fontana)]

Hi RMA team, (cc @rajaa, @dale )

Sorry for being an extra pain lately but I’ve been working on Rhino A LOT these days so I’m seeing more things still a bit broken, and they are affecting by productivity more. So unlucky you that you get to hear me complain more these days.

Now let’s talk Clipping Pains:

I need to have clipping planes that are not extra objects to manage in my scene. I need them as a way to view stuff and take screenshots. So here’s what’s broken IMO:

1. ONE click way to enable/disable all clipped geometry on my viewport.

Dale oroginally had created this plugin in V5: Clipping plane tool/script/plugin/nuggets out there? - #11 by dale

@dale

DisableAllClippingPlanes/EnableAllClippingPlanes

When will V6 have plugins? I'd love to move to V6!

http://mcneel.myjetbrains.com/youtrack/issue/RH-34047 If this doesn’t make it into V6, then I’ll cook you up a plug-in again…

2. better way to know which viewport is using a clipping plane:
When you have more than one ‘Pesrpective’ viewport this approach is not useful

3. Cap geometry regardless of open closed polysurface. I think that cap if open, do not cap is close it’s a nice default. It’s also a good way to know (in case you didn’t) that your object is not a closed polysurface. The problem is that most times I’m looking for interference is actually on interference/collisions between my model and imported components from all kinds of places:

• imported engineering assemblies (and we all know how bad RHino Step importer can be to bring solid geometry here)
• McMaster Carr/DigiKey or other supplier models (not always closed solids)
• Grabcad (the 3D version of the Craiglists free section)

Example: here is hard to see if I have collisions with this imported component in green (it did not import as solid & I or my client have no need/interest/time to doctor that model to make it a solid):

In needs to look like this regardless of the object is solid or not:

4. Easy way to set section appearance, including making a hatch on sections.
I need to set appearances on sections without going on a wild chase of options or hunting for layers. I’m aware of the existence of the SetLayerHatchData command in the SectionPlane command (Prototype: SectionPlane (ClippingPlane Enhancements)) …but I don’t understand it and it seems way more complicated than just having a clipping plane property. in the only plane I want to go: the clipping planes properties panel:

I know you have a sinkhole there and your are very afraid to go near, but I think it’s OK, we can use that space!

5. Clipping Object, not just plane.
You had in V5 this useful plugin called DinamicDisplay, and had a command called _ddClippingobject

I don’t even use it in V5 either, because even though I own it it’s a total pain in the ass to figure out its licensing. I think you have to send a message in a bottle and wait until it arrives to Spain, and then maybe they email you back… The thing costs $25 I think? …well my billing rate costs more than that so I can’t afford to deal with its nonsense licensing. Also it’s useless unless everyone I work with also has it. This needs to be inside Rhino, and stop this madness.

6. A simple X, Y or Z sliding/dragable section.
Even Adobe PDF has this. And every shitty iPad 3D modeling app. And every El Cheapo 3D printing slicing software. Come on guys, that’s a basic functionality of section tools.

Love,

G

[dale (Dale Fugier)]

Hi @gustojunk,

Regarding the DisableAllClippingPlanes and EnableAllClippingPlanes commands I worked up, I didn’t get much feedback from you so I wasn’t sure they were useful.

Do these command provide anything ‘better’ than just hiding clipping planes or putting clipping planes on their own layer and then turning the layer off and on?

Thanks,

– Dale

[wim (Wim Dekeyser)]

@dale

Do these command provide anything ‘better’ than just hiding clipping planes or putting clipping planes on their own layer and then turning the layer off and on?

Not sure I follow… (and I did read through the linked discourse threads and RH-34047).
G wants a command that disables all ClippingPlanes [in the active viewport]. Hiding a CP or putting it on a layer that is off will not disable the clipping action of the CP.

[gustojunk (Gustavo Fontana)]

@dale

I didn’t get much feedback from you so I wasn’t sure they were useful.

Sorry, silence means everything is awesome.

@dale

Do these command provide anything ‘better’ than just hiding clipping planes or putting clipping planes on their own layer and then turning the layer off and on?

Indeed. Hiding a clipping plane or turning of its layer only hides the plane, not the clipping. it does NOT disable it. So then you have to go on a while goose chase trying to find where is the clipping plane that’s clipping your model.

If clipping plane visibility (by hiding the object or the layer) would also disable the clipping plane then we would be all set. That in fact would be my preferred method of interaction. And then if you want to see or not the actual plane object you toggle that in the display settings/tab. But no matter which way you go you’ll upset half the users.

Best,

Gustavo

[AlW]

Gustavo pretty much has it.

There’s actually two important things that need to be capable of separate and instant toggling: visibility of the plane itself and the actual “cut” display.

I also think that as long as only clipping planes are offered (as opposed to a collection of more complex objects), another suggestion I saw here on discourse should be implemented: Any clipping plane should have it’s movement constrained to be along it’s normal, either direction. There’s no reason for any other translation. Rotation around two axes orthogonal to the normal, I suppose, could be available, but need not be at as high an accessibility priority as translation.

I also think the clipping plane definition by layer is the best way, although I think a unique identification scheme (layer label color) and/or their own grouping in the layer list could be helpful. I think having the layer on or off should control the clipping plane’s visibility in ALL VIEWPORTS.

I think the actual use of a clipping plane in the viewport should be via an additional button next to the viewport title that when clicked will provide a dropdown list of all the clipping planes in the view. When a particular plane in the list is moused over it’s use in that view should be toggled on or off. Mousing over the plane in the list should also highlight the plane in the view. Use should be BY VIEWPORT.

When a CP is in use mousing near it should be selectable, showing it in a selection dropdown if necessary, and when selected it should allow translation, rotation and turning off.

I agree with Gusto that the CP system is definitely not ready for prime time, and the thoughts above are what have occurred to me as I have struggled with it the way it is.

It also needs to work right with Raytraced.

[wim (Wim Dekeyser)]

@gustojunk

But no matter which way you go you’ll upset half the users.

That’s for sure!

My clipping planes are always on a layer that is OFF. I control the clipping of a viewport by reinstating a named view that either has the clipping enabled or disabled.

@AlW

I think having the layer on or off should control the clipping plane’s visibility in ALL VIEWPORTS.

No way!
I definitely need to have one viewport clipped and another one unclipped. One will typically be a floating maximized window on the secondary screen and the other will be a maximized viewport on the main screen.

@AlW

It also needs to work right with Raytraced.

Yes! That’s the only thing that is missing right now.

(That and hatches per layer or object; clipping objects; a better way to identify which clipping plane is clipping which viewport; an easy X, Y, or Z slider; and having TestMooCow working in RH6 again :o)

[AlW]

@wim

I definitely need to have one viewport clipped and another one unclipped. One will typically be a floating maximized window on the secondary screen and the other will be a maximized viewport on the main screen.

AlW:

I think you may have misunderstood. To explain in (perhaps excessive) detail:

There are two aspects to this clipping plane thing:

1. the definition of one or more clipping planes.
2. using one or more of the defined clipping planes to actually clip the displayed geometry in one or more viewports.

My comment that you quoted was meant to apply to 1). I think Layers are a good parking place for these clipping planes because the way the layer system works just seems like it would intuitively work well for the purpose, especially if a given layer’s use as a clipping plane parking place could be visually depicted for immediate recognition as such. Maybe also automatically sorted to the top or bottom of the layer list. I think that it would be advantageous if clipping planes were allowed only on unique, clipping-plane-only layers. If a layer already has geometry on it and an attempt is made to put a clipping plane on it the user would be warned and asked if he/she wants to create a new clipping plane layer or use an existing one. Conversely if he/she attempts to put anything besides a clipping plane on an existing clipping plane layer. Multiple clipping planes could be defined either all on one clipping plane, spread out over several, or even one per layer, depending on the user’s desire for using several clipping planes as a unified group. I suggested that the visibility of the actual cutting planes themselves, as opposed to the EFFECT of the cutting plane on the viewport display, be either on or off for all viewports. My thinking is that the user would like to see them ON when setting up the cuts, but OFF when using their effect in a viewport and a one-stop shopping approach would be preferable to turning them on and off in each viewport.

As to 2), I completely agree with you. That’s why I said:

@AlW

I think the actual use of a clipping plane in the viewport should be via an additional button next to the viewport title that when clicked will provide a dropdown list of all the clipping planes in the view. When a particular plane in the list is moused over it’s use in that view should be toggled on or off. Mousing over the plane in the list should also highlight the plane in the view. Use should be BY VIEWPORT.

On re-reading this, I think I should have said “When a particular plane in the list is CLICKED…”
Your technique of using named views to control the visibility is one I hadn’t thought of and may be preferable in some cases, but I think the approach of having an easily accessible button on each viewport would be much more user friendly and allow much quicker A/B viewing of a clipped/unclipped viewport display. I also think the viewport button approach as I described would satisfy this requirement pretty well:

@wim

a better way to identify which clipping plane is clipping which viewport;

especially if clipping planes could be named and their layer/name is automatically displayed when it’s selected or highlighted with a mouseover.

[dale (Dale Fugier)]

Hi @gustojunk,

@gustojunk

…it does NOT disable it…

Sigh…I guess I should have confirmed before I opened my mouth…

– D

[gustojunk (Gustavo Fontana)]

Hi @Dale, I think you assumed the most common, natural and expected way for this tool to work. I think this is a sign from the Rhino Angels. Let’s make it right!

G

[tobias]

While we are at it… I really hate the Model Views - Layout Views dropdown.
Everyone who ever tried using it in real life work situations will know why!

Actually that’s referring to the current V5 implementation…

[SamPage]

Hmm, perhaps I am misreading, but it sounds a bit like it is being suggested that turning off a clipping plane’s layer or hiding a clipping plane disables the clipping plane. If that is the suggestion, there has to be a way to have clipping planes clip without them being visible in model space or in a detail.

For any model / drawing package, I may have 10 - 50 clipping planes (often at least one per detail). I very much do not want to have to have them all visible while modeling, or have to choose to turn them off to model and have to remember to turn them back on when getting ready to plot.

@tobias

While we are at it… I really hate the Model Views - Layout Views dropdown.

Everyone who ever tried using it in real life work situations will know why!

YES!! The problem is that if you are tying to modify what detail a clipping plane is clipping, often the easiest place to select the clipping plane is model space. Every time you pull down the model / layout view, scroll all the way down to the sheet you want, sort through all the details to find the ones you want, then check or un-check a detail, it snaps back to model, and you have to do the whole thing again.

I wouldn’t mind a more robust clipping plane panel, or splitting it off into its own pallet (like layers) as more of a clipping plane manager. Allow viewing of both the views clipped, and current clipping plans, so it is a bit easier to see what clipping plane is applied to what view. Also, on the far wish side, the hatch brush idea for clipping planes, and Gustavo hatchign of unclosed surfaces / polysurfs:

[fraguada (Luis Fraguada)]

For hatches, wouldn’t this be more ‘Rhino’ if an object had a hatch attribute by layer, by parent, or by object? VisualARQ has had this for some time: http://www.visualarq.com/info/features/section-attributes/

Sections and clipping planes are kind of different, but the VisualARQ 2 section manager comes in pretty handy: https://www.youtube.com/watch?v=rp6AnuMj3Ro&t=2001s

[pascal (Pascal Golay)]

Hi Sam - in your image you have a layout (‘Sht_02’) that opens up to show details (‘Plan’ in this case) and from the details you can expand to see the clipping planes that are active, or could be active, in the detail, am I reading that right? (It seems like a lot of UI, but with the quantity of planes you’re using, I can see how that might be necessary - it almost wants a sort of LayoutManager panel with all of this and maybe other stuff like scale other detail and layout properties)

-Pascal

[pascal (Pascal Golay)]

@SamPage

sort through all the details to find the ones you want, then check or un-check a detail, it snaps back to model, and you have to do the whole thing again.

That seems like something that just needs fixing - @tobias - is that the problem for you or is there more to it?

I made a bug track item - there seems to be a glitch at the moment and I cannot make it visible to the public for some reason, but

https://mcneel.myjetbrains.com/youtrack/issue/RH-40570

thanks,

-Pascal

[cfee]

The ONLY problem I have with clipping planes is that you CAN’T SELECT an object to dis-include from clippping. I have NO TROUBLE controlling CLIPPING in a particular viewport, use a separate roving viewport REGULARLY, and I ABSOLUTELY have NO TROUBLE moving my clipping plane along ITS NORMAL when necessary.

Again, the ONLY trouble I have is de-selecting which objects I want to dis-include from clipping :

THIS is a visual representation of the ANSI/ASME requirement regarding SECTIONING, where internal diametrical components like shafts and bolts, along with any SPECIFIC design component NOT be sectioned in a view. IF the DESIGN REQUIREMENT I needed to present to the client was some feature of his bearing, lets say, and its fit on its shaft, maybe, or how I plan to constrain it axially, THIS is the ONLY proper way to present it. CURRENTLY, I’m forced to create an entirely seperate EXTERNAL duplicate of the detail or in some cases the ENTIRE ASSEMBLY, depending … and perform boolean CUTS where necessary, when a simple de-select is really the ONLY right answer.

So YES, Clipping planes is still too painful.

Thanks -

CFee

[SamPage]

@fraguada

For hatches, wouldn’t this be more ‘Rhino’ if an object had a hatch attribute by layer, by parent, or by object? VisualARQ has had this for some time: Documentation tools - VisualARQ

I think you are right, it would be more useful for that to be an object / layer property than a clipping plane property.

Hopefully not to getting too far off topic, I have often been intrigued by VisualARQ; but I’m not sure I would get great fit for the work I do. While film / TV / theater drafting share a lot of conventions with architecture, we have a lot of unique situations (most of our walls are single sided, many have to move, that kind of thing), which I’m not sure VisualARQ can handle. Native clipping planes in Rhino are quite flexible, and for the most part work for what I need, I just wish they worked better.

@pascal

[I]n your image you have a layout (‘Sht_02’) that opens up to show details (‘Plan’ in this case) and from the details you can expand to see the clipping planes that are active, or could be active, in the detail, am I reading that right?

My thought was just showing clipping planes that are active, which would I think make seeing what clipping planes are affecting the detail / viewport easier instead of looking over a giant, mostly empty list. The could be active clipping planes (which I would think would be all clipping planes) would in my mock up be on the right hand pane.

One handy thing about the available clipping plane list on the right of my mock-up is that it would also let you easily spot orphaned clipping planes (which I admit with my carelessness I often end up with several).

@pascal

LayoutManager panel with all of this and maybe other stuff like scale other detail and layout properties

(I’ve had this fantasy before Wish V6: Better Layout Management - #2 by SamPage )

[ejnaren]

Quick tip for the whole “I don’t know which viewport” problem with the layout/model drop down:
Name your viewport. The name will show up in the drop down.
But I agree a smoother workflow and fill regardless of closed polysurface would be very nice.

[gustojunk (Gustavo Fontana)]

That’s a great tip. Thanks! Problem is that I use a script to get to my perspective view ‘in style’ I need to tweak it to see if it lets me still use it ‘current active viewport’

[tobias]

Yes Pascal. That’s exactly what I meant

[dan]

RH-40570 and RH-41025 should be fixed in the latest RhinoWIP. Please give it a try.