I don’t fully understand clipping plane management.
I’m never sure if it’s best to use fewer clipping planes, and gumball them around where I need them or if I should make several in strategic positions and activate them when necessary. Either way, I never feel that the method works smoothly.
Why are ClippingPlanes assigned by viewport rather than a view? The wording is also a bit confusing. In the properties tab, you have a clipping plane tab where there is the option of selecting a “view”.
but it should say viewport because that’s what it does.
In my working viewport, I continuously activate different named views to go to a specific spot of the project. The C-plane updates with the view (which is handy). In order to activate a clipping plane I need to do one of the following:
I turn on the layer where I store clipping planes, I select the right one amongst many, I go to properties, I tick active on the viewport I’m using, I hide the layer.
I have set up some named positions (which I don’t entirely trust), I use the named positions to reposition the clipping planes in strategic locations. The clipping planes must be always active and when not used, are set to clip away-from-the-scene.
Recently I’ve been experimenting with a grasshopper script that repositions clipping planes when it detects that the name matches the view name in the active viewport. Handy, but needs setting up and the script must be running in the background.
Happy to take suggestions if someone knows a better workflow.
Hi Guido - the way that I used to work with clipping planes is exactly by linking them to named views.
My default template has one clipping plane on a layer that is off.
I have two named views in that template: they are called v0 and v1.
When I type v1, the scene is clipped. When I type v0, the scene is not clipped.
When my design progressed and I needed more section views, I would create a new clipping plane and make a new named view with that clipping plane active.
-wim
I tried to test the behaviour of the named views with clipping planes assignation
I made a box with two clipping planes in two planes and tried to save two named views with some clipping planes activated or deactivated.
Observations:
It is completely strange because when i double click LALALA in the named views both clipping planes are activated which is wanted behaviour.
However, when i double click blablabla in the named views, expected behavior should be to deactivate both clipping planes because thats the way i set it and then saved the view.
It is not happening:
I dont know but this seems like serious bug when there are two different named views saved under the same name and the program iteratates between them…
Hi Ivan - thanks, that’s clearly a bug. I’ve filed that as RH-57043.
Of course. A named view is just one of the components of a snapshot.
Generally, I find that my brain is not big enough to use snapshots… It’s probably fine when one needs to present a final design in different ways, but during the concept modeling phase where objects are created and deleted all the time, I found that I couldn’t keep track of snapshots.
-wim
Wow, I’m really surprised this works! Maybe it just should be more explicit then. I was assuming that it linked to viewports (not views) because the list in clipping plane properties shows active viewport names. Or maybe I was expecting to find something like this in the named view tab
Initially, I was very excited about the Rh6 Snapshot introduction. With time I found that the use of this feature works well if limited to creating transitions to a simple animation. Always best to save as detached study because it can seriously mess up you WIP file. Positions, for instance, restore all your model geometry transformations not just selected elements (i.e. named positions).
Interestingly, snapshots with a clipping plane object ticked do indeed save the clipping state but will only apply changes to the viewport that was active when it was created.
I don’t see any real distinction between a view and a viewport
I’m not sure what I’m looking at in that picture.
If that works for you, that’s fine, of course. But do note that this feature was specifically not intended for the animation of transitions. There is no control over how the transition happens.
That’s the way it’s supposed to work, yes. A clipping plane has to be active to have its state recorded as active.
-wim
Thanks, controlling clipping planes by named views is working very well.
Allow me to clarify a point.
I’m referring to the active viewport, not active clipping planes.
Other Snapshots properties like display mode work for any viewport. Intuitively I would expect a snapshot to work on the active viewport not to jump to another viewport and activate the clipping plane.
If the original viewport has been closed the snapshot seems to activate a random viewport or does nothing at all.
Maybe this is what confuses me. I refer to “viewport” as the rectangular divisions that host a view. I would say that I don’t see any real distinction between a camera and a view.
Ultimately I say that clipping planes are linked to viewports, not views, because if change the view Menu>View>Set view(any standard view) this will replace the view in the active viewport affecting the clipping plane properties, hence the viewport is the constant.
Lastly:
if you attach a file that has an active clipping plane to a worksession it has a tendency to be clipping the same viewport (e.g. top right) that had activated clipping, regardless of the hosted view …but there is plenty in that for starting a whole new thread.
I’m afraid I probably only added to the confusion with my simplistic statement. I think I need that level of simplicity to be able to just use Rhino.
In use, there is no view without a viewport and no viewport without a view. Behind the scenes, though, they are distinct entities and each has its own properties. I try not to think about what is a property of what. A clipping plane, for example, probably isn’t a property of a view or viewport. The list of views is rather a property of a clipping plane. But I might be wrong…
-wim
