Which cplane is active?

is there any way to indicate the current Cplane?

it would be really helpful

thnx,
D.

1 Like

Good remark (question). There should be an indication. :+1:

If you have saved a named CPlane and select it in the named panel, there’s a small axis indicator in the 3D view for it at least:

image

That doesn’t show the current one, just the one that you click. If you have many cplanes in that list this is useless.

1 Like

The current CPlane is the CPlane in the active viewport. As far as I know if only one viewport is displayed then it is the active viewport. If multiple viewports are displayed then the active viewport is indicated by “highlighting” of the viewport name. In the images below the Perspective viewport is active.
ViewportHilite2 ViewportHilite

what you are suggesting could be correct in the following situation:

you are using “named views set Cplane”
image

and you have never modified the cplane within that viewport afterwards.

but that is not really a reliable concept, at least not for the way I am used to work. I do use the Cplane stack(next/prev) quite a lot and sometimes I simply want to know which of the saved planes is active, and if it is not a saved Cplane it should indicate origin and axis directions(not only in viewport), imho,

1 Like

If you use OneView mode and set its UpdateCPlane and ViewLabel options to Yes, you will see the name of current construction plane, including named construction planes, in the top-right corner of the viewport.

I believe that the name of current construction plane should be displayed in the Properties panel, but it is not.

1 Like

@dk2079 For now, here’s a quick Python that may help. I don’t know if the scale is right, but it may be a start.

WhatPlane.py (3.3 KB)

To use the Python script use RunPythonScript, or a macro:

_-RunPythonScript "Full path to py file inside double-quotes"

-Pascal

1 Like

thanks Pascal,

for my needs it is totally sufficient that it displays the Cplane in the CommandPrompt.
But the scale in the viewport is fine too.

AS Andrew stated, I think it would be a good place to indicate the currrtent Cplane in the viewportProperties, but also highlight it in the named Cplanes if it is one that is stored there.
That detail can be very helpful… am I actually working with a pre-setup cplane or has something been modified (acidentally)

thank you,
Daniel

Last month I proposed that feature in another thread, along with a few other ideas, and hopefully most of them will get implemented in Rhino 7.

1 Like

Yes, as part of the Viewport properties might be good actually. The name should be near the top so as to be visible without scrolling, probably just under “Projection”. The CPlane axis vectors could be in a separate section further down. If the CPlane is not one of the standard or named CPlanes, the name field should just say “Custom CPlane, Unnamed” or something similar.

2 Likes

You know, I would accept even if it was simply checked when you go into the drop down context menu of a viewport. Currently the cplanes are listed but there’s no indication which one is active.

1 Like

Well, classically, the grid and the grid axes have been the on-screen indicators. There are those people that turn both off because they don’t like the clutter. Personally I keep just the axes shown most of the time. Also, I have modified my grid colors so that they are pretty subtle and don’t disturb when I have it showing.

However, if you have a lot of different saved CPlanes that are close together, picking them by name is a lot more reliable than trying to figure out which one is active by looking at the grid/axes.

This is how I usually work:

I don’t care much about cplanes in simple projects but on one usecase I had to create 300+ cplanes. Then you can see the problem. Also the fact that you cannot undo actions on the cplanes is quite annoying.

1 Like

not quite sure what you are reffering to, but just make sure, you are aware of this?:

create new cplane and then CTRL+Z

CPlane manipulations do not go into the main undo stack, they have their own.
This is similar to view/viewport manipulations.

1 Like

I know this but it should be an option/a setting and not to ask the user to script a custom undo command

I think it makes sense that it is within a seperate undo cue.

there is a toolbar for it, and there are also preDefined keyboard shortcuts for it.

image 2019-09-25%2014_41_27-C__Users_dkerbler_Google%20Drive_MAK%20Barrierefrei%20(GD)3d_190923_MAK_Berrierefrei

I don’t think like this, this is why there should be a setting/option that user can set.