Is it possible to get Cplane transformation data from the existing named Cplane (rotation and position movement data)?
Is it possible to set Cplane to some exact transformation (set rotation and position data)?
This could be extracted from the differences in Cplane and world coordinates of 3 points.
Cplane command without an option translates the Cplane origin to an input location.
Cplane command with Rotate option rotates the Cplane an input angle about an input axis.
Cplane command with 3Point option translates and rotates the Cplane using input points.
The ConstructinPlane class in Rhino common has a Plane property which “Gets or sets the geometric plane to use for construction.”
https://developer.rhino3d.com/api/rhinocommon/rhino.docobjects.constructionplane
https://developer.rhino3d.com/api/rhinocommon/rhino.docobjects.constructionplane/plane#
1 Like
@mdesign is this something you want to do through a script? In other words, does this belong to the scripting category? Can you explain what you are after?
I haven`t plans like this but it would be awesome to have set and get cplane transformation script
It’s probably not too difficult to get the information you want, but it’s still not clear to me what you want to do with it.
I have QuickSurface software to find the perfect symmetry of 3d scan. I imported to Rhino both versions of the scan before and after centering. By using Orient3pt I move one scan to another to determine the transformation data of the 3d scan object block (both scans are inserted blocks). I used that transformation also to move a big proxy triangle to allow call me Cplane>3pt and work over a perfectly centred scan without touching its original transformation. I don’t use named Cplane cause I’ve found that when I recall named cplane it has small differences. That`s why I would like to set cplane from having numerical values to be sure that I have exactly what I want to have. Hard to explain.
@mdesign The Cplane command allows direct keyboard input of the transformation data. Type the coordinates of the points and enter the rotation angle?
What size are the differences in the Cplanes when
What size are the differences when you recall a named Cplane? There should not be any differences from when the Cplane was saved.
1 Like
I can`t repeat this today, but when I did it yesterday, the X, Y, and Z lines were not exactly on the axis where they should be after the named plane recall. We should assume that it was my fault. Thanks for that info about plane coordinates. I didn’t know that.
It was small tiny differences and yesterday it was a few times like this. today I can’t repeat that.
Do named cplanes have exact accuracy or is it some rounding to unit accuracy? Maybe it was a problem with units. I have an accuracy of 0.005mm but I took cplane rotation and position from 10m square edges.
Disclaimer - I am not associated with McNeel and have never seen the Rhino code. I do have some background in computational geometry and numerical methods. My knowledge of Rhino is based on use, testing, exploration and this forum.
Rhino uses double precision floating numbers for almost everything. (The one exception is final output for display). Double floating point precision is 15 to 17 decimal digits. Repeated calculations can result in deviations accumulating. The worst degradation I’ve seen is 13 decimal digits. For a distance of 10m this means precision to .00000001 or better.
Cplanes are not affected by the “absolute tolerance” setting. Absolute tolerance is only used when an exact result is not possible and an approximation is required. Then the accuracy parameter is used to find an approximation with a maximum deviation less than the accuracy - a common example is the intersection of two curved surfaces which generally cannot be represented exactly as a NURBS curve. Planes can and are represented exactly (within double precision floating point accuracy).
Potential causes of Cplane deviations:
Osnap not used when creating the Cplane. “Snappy” turned off in Gumball. For accuracy snapping needs to be used. I’ve had discrepencies which I traced back to uninadvertently having Osnaps turned off.
Using an inappropriate Osnap - for example “Near” when the intent is to snap to the end of line or edge. I’ve made this mistake more than once.
High level of zoom - Rhino can be zoomed to a magnification level beyond the numerical precison of the display. As mentioned above the final screen display uses lower precision than the remainder of Rhino. If the relative position of two objects appears to jump around when zooming or panning then you have zoomed beyond the accuracy of the display (although the internal accuracy is much higher).
Round-off errors converting from decimal input to binary used by computers. For example 0.1 cannot be represented exactly by a finite number of binary digits. While this error is very small with double point floating precision (15th to 17th decimal place) and irrelevant in real world situations it has been previously discussed in this forum as an “error”.
1 Like
… did not read all posts above
… refering to your initial post:
check
_namedCplanes (to store several cplanes)
and
_remapCplane (to use cplanes to “drive” transformations (rotate / move))
and I posted a wish 3 years ago, that did not get much attention - but you might like it:
1 Like
I think I’ve found the problem.
I’ve noticed that I`ve put value X:-1.812 and I’ve got cplane position X:1.81 (rounded). The position was not a problem but the angle was rounded the same as this.
It was needed to change display precision in Preferences:
Do you have any script to know what rotation (X,Y,Z angles) and position translation has the current CPlane (named or not)?
output Yaw Pitch Roll of current c-plane of active view.
might not work n layout space…
no error handling…
but a startingpoint:
#! python3
import Rhino
import Rhino.Geometry as rg
planeTarget : rg.Plane = Rhino.RhinoDoc.ActiveDoc.Views.ActiveView.ActiveViewport.ConstructionPlane()
xform : rg.Transform = rg.Transform.PlaneToPlane(rg.Plane.WorldXY,planeTarget)
success,a,b,c = xform.GetYawPitchRoll()
#Rhino.RhinoApp.WriteLine(f"Radiants Yaw: {a}, Pitch: {b}, Roll: {c}")
ad = Rhino.RhinoMath.ToDegrees(a)
bd = Rhino.RhinoMath.ToDegrees(b)
cd = Rhino.RhinoMath.ToDegrees(c)
Rhino.RhinoApp.WriteLine(f"Degrees Yaw: {ad:.3f}, Pitch: {bd:.3f}, Roll: {cd:.3f}")
1 Like
Thanks a lot.
I prefer to do transformations by snapping to points and ends of lines when possible in the various scale, orient and rotate commands, rather than entering numerical values. Two reasons - accuracy and less likely hood of a mistake. Snapping uses the exact internal binary form of coordinates, equivalent to 15 to 17 significant figures.
1 Like