Why does almost nothing in Rhino respect the active CPlane?

I just did a Cap and noticed this:

But then I also noticed that I’ve asked about similar things several times, because it’s so illogical!

It’s a “construction plane”. Why doesn’t ALL the things I construct respect it? :japanese_goblin:

1 Like

Hello - what would you gain by havng planar surface isocurves align to the the current CPlane?

In case it helps, here’s a thing that will let you set planar face UVs any way you like.
PlanarFaceDirection.py (4.7 KB)

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

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


1 Like

My understanding is the data for objects does not include anything about local Cplanes in use when the geometry was created or modified. All geometry is saved in the world coordinate system.

That is fine, but at the moment of creation there should exist nothing but the the active CPlane. But it doesn’t. Lots of core things in Rhino just ignore the CPlane and read straight from the world coordinates, which feels (I’m going to use that word again) inconsistent.


Yes this is a big problem. Today i realized it when i was copying and orienting and modifying blocks in different planes.
I think when defining block user should be able to control its plane not just insertion point, there would be couple options to respect cplane world or custom plane. Current behavior is insufficient to have blocks under control

Yes, please! Had this problem very often, too - a new block always takes the world coords, when it should take the active cplane.

1 Like

yes but optinally either world cplane or custom, program would ask you when creating block

1 Like

@pascal you were gathering where everywhere cplane should be respected. you have few suggestions here above.