Rhino 8 Mac CPlane

Hello,

I am trying to understand CPlanes. I have 2 buildings in a model, with differing front alignment angles. I want to create Layout Details for each building, with each orientated to the relevant angle. My understanding is that the trick is to activate a Layout Detail and set the relevant CPlane, then set the Camera to the relevant CPlane Front or Right elevation.

On the Layout page, the left Details relate to Building A on the World CPlane. The right Details relate to Building B on the TS CPlane.

The lower right Detail shows the Right image aligned correctly to the TS Plane, although I had to select Camera CPlane Top.

In the Perspective view, I note that the TS CPlane lines are red and green for X and Y, but the arrow colours are confused - red instead of green, blue instead of red, and green for Z.

The upper right Detail is intended to show the Front image, but it only shows when I select CPlane Right or CPlane Left, and then it is rotated at 90 degrees.

CPlanes01.jpg was captured after activating the World Top CPlane, and it shows 2 sets of coordinate arrows, with colour confusion. CPlanes02.jpg was captured after reactivating the TS CPlane, and it has removed the World coordinate arrows.

I am seeing similar results on Windows, so it is highly likely that it is due to my misunderstanding. I have watched some videos and hunted through the documentation, but I have not found the magic.

I used TiltView -90 to rotate the upper right Detail after attaching the model.

After reopening, the duplicated coordinate arrows disappeared.

I think I have found the magic. I created a Named View in the Front view after activating the TS CPlane. I then set that Named View in the Layout Detail. Fingers crossed.

Regards, Garry.

KDRCPlane.3dm (3.8 MB)



SystemInfo.txt (5.1 KB)

Hello,

I think that I am on the right track, but I am seeing odd behaviour on both Mac and Windows with the Front view.

The revised model has Named CPlanes for Top, Right and Front. It also has Named Views for Top Right and Front. However, I cannot get the desired Front CPlane view. When I set the FrontTS CPlane in Front view, the Set View from CPlane buttons and commands do not provide the expected view…

Set View Front View of CPlane provides the Top view.

Set View Right View of CPlane provides the Right view, but rotated 90 degrees.

Set View Top View of CPlane provides the expected Front view.

The behaviour seems to be hit and miss. I have looked at the green and red reference lines and the direction arrows in Perspective view. I am still seeing colour confusion. It seems that I am still missing a key element here, or there is a gremlin.

The Named Views work OK, but after activating fire FrontTS, the Set View Front View of CPlane provides the Top view. To see the correct Front view, the Set View Top View of CPlane must be activated.

Regards, Garry.

KDRCPlane.3dm (3.8 MB)

Hi Garry -

That’s correct.

I’m not seeing that here.

[I’ve added some features to the buildings and different colors to the layers to make it easier to keep track of building and orientation…]

When I select the “TS” named construction plane in the panel, the arrow colors seem fine …

… and making a new detail where the construction plane is set to “TS” lets me get the correct view when using SetView -> CPlane -> Right.



When you have set one view that is as you want, you can use Detail -> From Detail to get other projections from that detail. The result depends on where you place the new detail. I use a keyboard shortcut “DF” to quickly make those details.

Once they are created, you can move them around in a different position.

I haven’t been able to get two CPlane widgets to be shown at the same time. Is this something that you can reliably reproduce?

I never use the SetView workflow but always use named views instead. Most often, I need a section and save a named view with that clipping plane active. It’s then easy to set a view and remove the section if required. Also note that, with the default settings for named views, those also set the CPlane. And with the default AutoCPlane turned on, when you sub-object select a surface on your model and save a named view, that will also save the CPlane. This allows me not to worry about saving custom CPlanes but simply save the views I need.

In your new file, when I select the “FrontTS” custom CPlane in the panel, this looks correct in the perspective viewport:

When I then double-click that to make it active, the grid aligns as expected:

And then running Plan, gives this:

The “RightTS” custom CPlane, however, is not as I would expect:

Are you using standard construction planes or universal construction planes?
-wim

@wim I will work through your comments in detail, but for now I will answer your questions.

I have tried switching CPlanes this morning, but cannot reproduce the double widget scenario. If I see it again, I will let you know. It was appearing regularly.

I am using standard CPlanes.

Regards, Garry.

@wim In Top view, with the World Top CPlane active, I activated the TopTS Named View. It seems to be OK when changing Named CPlanes. That changed the CPlane, but retained the World CPlane widget. I am not sure what triggers the display of the widget for the active CPlane, but at least this demonstrates the remnant widget for the deactivated CPlane.

Regards, Garry.


@wim I have reproduced the widget colour confusion…

In Perspective view, activate the TopTS Named CPlane.
All is good.
Switch back to Perspective view.
Activate the FrontTS Named View.
Switch back to Perspective view.
The colours are confused.

The same colour confusion occurs on the Perspective view even when the FrontTS Named View is activated from the FrontTS ortho view.

Regards, Garry.

Hi Garry -

That’s simply having it marked selected in the Named CPlanes panel.
It’s by no means an indication of a CPlane being active!

I’m not seeing that here yet.
A few questions…

What does “activate” mean here? As I noted, simply selecting a CPlane in the list will show the widget in the viewports but will not set the CPlane. You need to double-click an entry in the list for that to happen.

How do I switch back to perspective when I never left that viewport?

Just to make sure, it’d probably be good to have details on that as well.

Here, yes, the perspective viewport has been turned into a parallel viewport. Do you set that to perpective in the Properties panel or do you do that a different way?

Cheers,
-wim

@wim I will address each of your points below.

  1. In the images that I provided in posting 4, I had double clicked the TSFront Named CPlane in the list. You will see in the images that the CPlane is set accordingly. However, the widget does not appear there, but remains on the World Top location. I expected the widget to shift to the new location. I do not always see the widget, which is why I was not sure what sets it. Perhaps the reason that I am not used to seeing the widget is that I have only started using a custom CPlane in the last few days.

  2. No response required.

  3. By activate, I mean double clicking in the list. That is what I have been doing.

  4. Understood. I had probably switched to a parallel view in the interim.

  5. I double clicked the FrontTS Named View.

  6. I switched back to Perspective view via the view name drop down menu Set View.

Regards, Garry.

Hey Garry -

In posting 5 that has images (posting 4 doesn’t), you write:

Posting 5 doesn’t mention anything about custom CPlanes, but, from those images, it looks like the default world Top CPlane has been marked in the Named CPlanes panel.

I don’t see that, no.
These are your images:

The first one shows a parallel view with a custom “Top” CPlane. The unrelated CPlane widget is at the world origin and shows the world X and Y axes.

The second one shows a perspective viewport where the active CPlane is aligned to the front facade of building B. The CPlane widget shows that the “World Top” CPlane is still selected in the list of named CPlanes.

As I wrote earlier, the widget merely indicates which item is marked in the Named CPlane panel. It doesn’t denote an active CPlane and doesn’t move to a different location unless a different item is marked in that panel.

Perhaps I’m finally starting to understand what you mean with color confusion…
(I tend to need the teaspoon…)

Does this image show that issue?

If so, that’s because there is no correlation between the widget and the active CPlane. The widget shows what’s selected in the list, and the grid with the axes show the active CPlane. If both did the same, one of them wouldn’t be needed.
Cheers,
-wim

@wim Your image does show colour confusion, but the images in my original posting are more relevant. The CPlane red line has a blue widget arrow. The green line has a red widget arrow. The Z direction has a green widget arrow. Your comments regarding no correlation between the widget and the active CPlane helps my understanding. I now see that the colour confusion arises after selecting say RightTS in the Named CPlanes list, then double clicking say TopTS in the Named Views list. Vice versa produces the same disconnect.

From the documentation…

Named views

Named views set CPlane

Restoring a named view also restores the construction plane saved with the view.

I had expected that the displayed widget would relate to the active CPlane. I cannot see why the widget does not mirror the active CPlane. I see your point that the widget represents the selection in the Named CPlanes list, but I cannot see why it is not redisplayed to reflect the most recently activated CPlane, which could have been via a double click of a Named View. Is there a reason why the secondary action of selecting the relevant Named CPlane is required to reposition the widget after double clicking a Named View has repositioned the CPlane?

Regarding the problem outlined in posting 2, this morning I deleted the Named Views and recreated them with the benefit of the additional knowledge gained from your comments. Initially, the buttons were not producing the expected views. The Top and Bottom buttons were OK, but Front produced Top, Back produced Bottom, and similar results were seen on Right and Left. Then..

I found the magic. In order for the 6 buttons to work as expected, the active CPlane must represent Top view. My Named Views had activated CPlanes representing Top, Front and Right for each parallel view. After I set the active CPlane to TopTS in all 3 parallel views, the 6 buttons work as expected.

Thank you for your comprehensive support. It is much appreciated.

Regards, Garry.

@wim This is still causing confusion. Even after I set the active CPlane to TopTS in all 3 parallel views, the 6 buttons work as expected, with the exception of the Right view, which requires TopTS instead of RightTS. RightTS provides a right view, but rotated at 90 degrees. To see this, set the Right view to the normal Right, then activate the RightTS CPlane, then set the view to RightTS. To add to the pain, there is an inconsistency. Sometimes it works correctly. Bounce around the Right views and CPlanes and you will see the problem.

The other annoyance is that when I activate a Front or Right named view, the right mouse operates the perspective orbit function instead of the parallel drag function. I then have to set the camera to CPlane Front / Right to return to parallel view. This does not occur in Top view. Very annoying.

In another model where I am trying to get this working, I can select objects in Top view, but when I try to Zoom Extents or Zoom Selected in Front and Right views, the messages shown below are displayed. Zooming in Top view is OK.

Regards, Garry.

SysInfo.txt (5.0 KB)

@wim I have found the cause of the 90 degree rotation in RightTS view. It appears that the named view had been saved with the RightTS CPlane. I resaved it with TopTS CPlane, and now all 6 view buttons provide the expected results. I have now deleted FrontTS and RightTS CPlanes, as it seems that they are of no benefit, and only lead me into trouble.

The Orbit / Drag and Zoom issues remain a mystery.

Regards, Garry.

Why in the world would you want to do this? There is no reason to set a Top CPlane in the Front or Right views, that will simply make it impossible to draw anything in them. Each Rhino viewport has its own CPlane associated with it, and when working in parallel ortho viewports it is best to keep the viewport’s CPlane parallel to the view - i.e. the CPlane Z-axis coming vertically out of the screen towards you. So Front view should have Front CPlane and Right view should have Right CPlane. You can move the CPlane origin around or rotate the plane around the Z axis - I don’t recommend this at all though - but do keep the CPlane Z-Axis vertical to the view direction in parallel orthographic viewports, otherwise you will quickly have issues.

@Helvetosaur Thank you Mitch. Got it, to a degree. I have reinstated the FrontTS and RightTS CPlanes so that the Z axis points to my noZe. The set views are still working as expected, and EvaluatePoint provides the expected values. It has also overcome the zoom problems, which probably arose due to the axes being out of whack for the views.

I think the only remaining issue is the right mouse activating orbit instead of drag. It is too far past midnight, so time to watch the inside of the eyelids for a few hours.

Regards, Garry.

The concept of individual viewports each having their own construction planes is often confusing to beginners, but once you get used to it it is quite useful.

Check this setting in Options (Preferences):

(this is Windows, Mac will have the same setting but the UI will look a bit different.)

Also make sure that your views are actually set to parallel projection.

@Helvetosaur Your support is greatly appreciated. I have been using Rhino since 1.0 wore shorts, but still consider myself an experienced novice. GH remains a dream at this stage. One day…

You were correct re the Pan. It was not set to always pan parallel views. Fixed as shown below.

Pasted Graphic.png

I had created a memory jogger note when I was first trying to get my head around this matter. I have updated the note based on your input. I have included it here, hoping that it helps and that future readers follow the thread to this point to avoid my earlier incorrect reference to Top CPlane use.

Regards, Garry.

Rhino CPlane instructions

Axis orientation

In each parallel view, the CPlane orientation must be set so that the Z axis is pointing out of the screen, towards your noZe and eyeZ.

Create CPlanes

In Top parallel view, on the CPlanes tab, use Set Plane by X-Axis or other mode to create a new CPlane.

Use Save CPlane by Name to assign a name to the CPlane. Include Top in the name.

In Front parallel view, on the CPlanes tab, use Set Plane by X-Axis or other mode to create a new CPlane.

Use Save CPlane by Name to assign a name to the CPlane. Include Front in the name.

In Right parallel view, on the CPlanes tab, use Set Plane by X-Axis or other mode to create a new CPlane.

Use Save CPlane by Name to assign a name to the CPlane. Include Right in the name.

Activate CPlanes and orient Views

In Top view, activate the saved TopCPlane, then on the Set View tab, use Top View of CPlane to change the orientation.

Use Save View by Name to assign a name to the view orientation. Include Top in the name.

In Front view, activate the saved FrontCPlane, then on the Set View tab, use Front View of CPlane to change the orientation.

Use Save View by Name to assign a name to the view orientation. Include Front in the name.

In Right view, activate the saved RightCPlane, then on the Set View tab, use Right View of CPlane to change the orientation.

Use Save View by Name to assign a name to the view orientation. Include Right in the name.

@Helvetosaur With your help, I now have the CPlane based views as required, so can progress with the model.

However, I have found that its is not necessarily true to say that the Z axis should point out of the screen in all parallel views. Opening a New Model shows XY for Top, XZ for Front, and YZ for Right. That is perfectly logical for the World View, and equally logical for custom CPlanes.

I have discovered that the reason that the SetView buttons were not working as expected is that I was setting individual CPlanes for each parallel view - Top, Front and Right, each with the Z Axis pointing out of the screen. When I deleted the Front and Right CPlanes, and used a single CPlane definition for all parallel views, the SetView buttons worked as expected.

The Penny Drop moment was when I read the documentation again this morning and realised that the buttons set the view of the CPlane, not the view of the model’s objects. They set the view of the XYZ axes. That made me realise that the concept of individual CPlanes for each parallel view is contrary to the button iconography. If the Z axis is pointing out of the screen for Front or Right view, the buttons do not work as depicted by the icons.

My earlier notes are misleading, and do not fully resolve the situation. I have attached my test model with updated settings. Here is my revised memory jogger based on my findings. I hope it helps others.

Create only one CPlane for the purpose, probably defining it in Perspective view for ease of definition. Name the CPlane for its purpose, with no reference to Top, Front or Right.

In Perspective view, activate the named CPlane.

In Top view, activate the named CPlane. Use SetView CPlane Top to set the view to the named CPlane. Save the view with Top in the view name.

In Front view, activate the named CPlane. Use SetView CPlane Front to set the view to the named CPlane. Save the view with Front in the view name.

In Right view, activate the named CPlane. Use SetView CPlane Right to set the view to the named CPlane. Save the view with Right in the view name.

Use the same approach for Bottom, Back and Left.

After the views have been named and saved, activation of the Named Views will set the active view as saved. It might not activate the CPlane which was active at the time of saving. That may be done either before or after activating the Named View.

Regards, Garry.

KDRCPlane.3dm (6.6 MB)