We have either regressed this 2015 issue or it was never really fixed. Whatever the history, it is a problem.
When I am manipulating CPlanes, I need to know which CPlane is active in a Viewport because if I don’t have the CPlane expected then operations - scaling for example - can go wrong and if I don’t notice at the time, I end up with a crocked model and have to revert to a previous version, wasting time. Names are important because they are quickly assimilated, whereas trying to understand which CPlane is in use from Origin point and Axes vectors is slow.
Rhino has no indication of the CPlanes in use and I’ve asked for that to be added to the viewports. But impatient for a solution I decided to do something myself and started with some code to understand this aspect of the Rhino entity model.
Given there is no equivalence or equality function for the CP entity, one has to match attributes, extracting the Planes and (as there could be multiple named CPs with the same plane) the Names. But a misnamed CP isn’t going to match.
In the example below, the CP for the perspective viewport is named “Wonky Too” but its origin and axes are those of World Top, which was the CP last applied to that viewport, as is evident from the grid and the “Wonky Too” axes indicator.
Note also that Rhino is not just failing to apply the “Top” name over the prior named CP name in the perspective viewport, as per the original error report. If you apply the named CP to any of the orthogonal viewports they retain the orthogonal CP name, whilst taking on the named CP origin and axes. And if you apply a different world CPlane, the axes change but the name doesn’t.
This problem affects R8 and R9 - I haven’t checked earlier versions.
Here is a trivial model and a script that can be used to display the problem. Change the applied CPlane for a viewport and run the script to see what values Rhino holds. TestCPlane.3dm (92.3 KB) ListViewportConstructionPlanes.py (1.1 KB)
It looks like Rhino sets the name of the CPlane for the active viewport only when the CPlane is added to the Named CPlanes table.
It doesn’t ever update the CPlane name in the viewport when different CPlanes are applied to the viewport (whether named or not), nor when a named CPlane instance with the same name as the viewport CPlane is deleted from the table.
[Footnote: a Viewport’s CPlane is stored as a separate instance from any CPlane with the same name in the Named CPlanes table, rather than as a reference to the CPlane in the table.]
I am not sure I am going to answer your question or solve you issue. But here is some information that may be helpful.
Like Rhino views, construction planes can be assigned an optional name. In most cases a construction plane’s name property is empty, unless you run the _CPlane _World command option, save a named construction plane: _-NamedCPlane _Save, or assign the name yourself using a script or a plug-in.
Note, Rhino did not always set a construction plane’s name property. These YT’s relate to my comments above.
Also like Rhino views, construction plane names, if assigned, do not always provide an accurate indication of the plane’s definition. For example, its pretty easy to name a construction plane “Bottom” even though the the plane is set to the world xy plane.
If the orientation of the construction plane is important, it’s best to compare it with world definitions, in my opinion. See attached for an example.
Thanks for the prompt response and the example. I take the point that CPlanes can be given inappropriate names, but then anything can. Let’s assume that the people who will benefit from a working CPlane naming system are those who manage to be meaningful - probably the vast majority.
It seems to me that trying to categorise CPlanes according to orthogonal directions is missing the point that Named CPlanes are most useful for things that do not lie parallel to the orthogonal planes: roof structures for example. A present project has a CPlane named “1in40” which is a nice fall for a flat roof. But if I forget that CPlane is applied to my viewport and I scale a 3m horizontal member by a centimetre or so I may not notice that I am scaling on a skew. Displaying the CPlane name in the viewport can help me avoid that mistake.
While I would like that feature, if it doesn’t appear soon I can mitigate its absence by writing my own query. But that needs the viewport CPlane name to be updated alongside the plane whenever the CPlane changes. That seems to me to be quite a simple change…
In lieu of any changes to Rhino, here is a quick and dirty plug-in that draws the name of the construction plane in the viewport. If the construction plane has a name, it just uses it. If not, it looks to see if the construction plane’s plane is one of the known 6 world planes and, if so, draws the name of orientation followed by an asterisk. If there is no name and the plane isn’t something known, the conduit just prints <unknown>.
Load the plug-in and run TestJeremy to toggle the conduit on and off.
The display pipeline is great but unfortunately the information displayed is incorrect. For example, here the perspective viewport shows “Wonky Too” in the corner of the viewport whereas the construction plane in use is “Top” (aka “World Top”). You can see that the CPlane is not “Wonky Too” from the disparity between the grid and the highlighted CPlane axes, and from my interrogation of the model data.
The viewport is stuck with the CPlane name used when the latter was added to the Named CPlane table. Until every subsequent change to the viewport CPlane includes updating the name attribute to match the name of the replacement CPlane applied, the display will be actively misleading.
If the viewport’s construction plane has a name, the plug-in just displays it. In your example, the Perspective view’s construction plane is named “Wonky Too”, thus it is displayed.
When you save a named construction plane, the name you give to the saved construction plane is pushed back onto the viewport’s construction plane (RH-68003). We do this because, at this point in time, the viewport’s construction plane and the saved, named construction plane are the same.
Does this help? Do you want the plug-in to work differently?
Names have the purpose of conveying identity. Giving something the wrong name conveys the wrong identity.
Dale hires a car for his holiday. Frank is behind him in the queue. The clerk is lazy so instead of typing Frank’s details into his terminal he brings up Dale’s details and uses those. Later Frank runs up hundreds of dollars in parking fines. The authorities think Dale is liable…
A CPlane set in the Perspective viewport is saved with the name “Wonky Too”. A user sets the Perspective CPlane to “World Top” but Rhino is lazy and leaves the earlier name in place while changing the plane. Later the user wants to make a small Wonky-oriented change, sees the name “Wonky Too” in the corner and unwittingly changes something in the World Top orientation. The authorities think Dale is liable…
Or more likely, customers start calling McNeel support saying "CPlanes are broken: whenever I try to set a new CPlane, Rhino tells me it remains set to “Wonky Too” " (or whatever their last save was called).
No, the plugin seems great, pretty much what I would have stumbled toward if I had any idea how to code the pipeline. The problem is GIGO because Rhino is (metaphorically) being lazy with its record keeping.
Yes I do, and if I change to standard construction planes then the viewport CPlane name changes for me as per your experience. So it’s a universal cp problem only: well spotted!
