I’m experiencing a weird problem with Auto CPlanes.
The white blocks in the attached model have their origins on the black perimeter.
Depending on how I rotate the view, the Auto CPlane sometimes goes into the opposing direction.
Another useful improvement would be a Block Plane option in the Box Edit panel.
problem_block_auto_cplane.3dm (61.4 KB)
Hi Martin - I believe the auto-cplanizer attempts to orient the plane so that drawing makes some sense - e.g. X to the right. There is an advanced setting that looks promising
Rhino.Options.ModelAid.AutoCPlaneAlignment
but I am not sure what that does, so far.
-Pascal
Thanks for the reply. I’m not sure what that advanced setting does or should do?
It would be nice if the AutoCPlane was aligned with the block plane.
Gumball (Object) shows the expected alignment for all five blocks which means there’s a discrepancy between the alignment of the Gumball normal and the Auto CPlane normal for some of the blocks in my file.
Maybe the Auto CPlane command needs an option ‘Align to Block’?
Auto CPlane align to Block? - Serengeti (Rhino 8 BETA) - McNeel Forum
This looks to me to be working as expected. The Auto CPlane tries to keep it’s Y axis close to the views up direction. It does this by rotating the Auto CPlane in 90 degree steps so the axis of the CPlane are still where you expect. Compared to the gumball it’s just flipped so it gives you a good CPlane compared to where you’re looking from.
The Auto CPlane also tries to keep its normal facing the view. The gumball doesn’t do this kind of post processing.
Thanks for the information.
I guess I have to do my workaround then.
Hi Martin, in case it helps, this will (should) set the cplane to the block instance plane
import rhinoscriptsyntax as rs
import scriptcontext as sc
import Rhino
id = rs.GetObject("Select a block instance.", 4096, preselect=True)
if id:
obj =rs.coercerhinoobject(id)
xform = obj.InstanceXform
myPlane = Rhino.Geometry.Plane.WorldXY
myPlane.Transform(xform)
rs.ViewCPlane(rs.CurrentView(),myPlane)
-Pascal
I’m interested in what the current Auto CPlanes orientation prevents you from doing or makes more difficult.
Using BoxEdit like shown in the first post, an Object inside the block can not be manipulated consistently. BoxEdit requires a CPlane input and has no option for block plane. Nudge also doesn’t go in the direction of the block.
Also I think the CPlane guessing is a bad idea since an object like a line has a start and end point. That’s the normal direction for the Gumball and it should be for the CPlane. Any mechanism like this should be possible to deactivate. Basically like the ‘Text reads forward when viewed from behind’ option which can be switched on and off. In some cases this sort of guessing is really not beneficial.
Let’s go back to the model in the first post.
There are more efficient ways to do this but let’s say I’m adding a cylinder on the base plane of every every block manually. With the Auto CPlane I need to select a block, then _Cylinder, Enter, 0, whatever radius, Enter, height and Enter.
The cylinders should all go towards the center of the perimeter but depending on the view used to create the cylinders, so go inwards and some go into the opposite direction. This is a mess.
I opened an issue here to add an advanced option to disable orienting the Auto CPlane towards the view.
Thank you!
Hi @martinsiegrist - The new option to have the AutoCplane be independant of camera orientation RH-81260 has been added to 8.7. It seems to be working well! This build should be available in a few weeks, so this is just a heads up. You’ll find the setting in Options / Advanced: Rhino.Options.ModelAid.OrientAutoCPlaneToView.
Thank you Vanessa!
Hi Vanessa, I forgot about this topic.
This works as expected now with Auto CPlane set to Object
block_auto_cplane.3dm (73.2 KB)
