algorithmic modeling for Rhino
Hi all,
I'm struggling to reconcile a difference in what I am seeing as output from python (using the rhinoscriptsyntax library), and what i am seeing output from grasshopper.
I can orient a point onto a plane using Point Oriented in grasshopper and get a resultant plane with origin point (-152.78838, -1065.812137, 1436.310291). If I perform the same operation in ghpython with Point.At the resultant point is -153.792951019493, -1065.84279597442, 1436.31029129594). The x/y/z vectors defining the plane are identical. The difference seems small (.03mm), but once curves are drawn on the planes, it is the difference between CurveCurveIntersection working at a normal tolerance (.01) and only working at a really slack tolerance (.2).
So, I have two options. One is to understand what is tripping me, and the other is to find another method to orient a point to a plane using u/v/w parameters. Any ideas?
Thanks so much, Kendra
Tags:
Hi Kendra,
are you sure that the plane vectors are completely identical? Or are they only identical to within the 6 decimal places that Grasshopper usually uses to display numbers?
--
David Rutten
david@mcneel.com
Poprad, Slovakia
Hi David, thanks for the reply. I looked into this more, and no, the planes were not entirely identical - close, but not identical. I traced this back to a difference between calculating an angle from two vectors using grasshopper components ( returning radians ) and calculating an angle from two vectors using rhinoscriptsyntax in python( returning degrees ). Using rhino grasshopper components, the sum of the angle of the two vectors, and the angle of one vector and the inverse of the other is exactly 180 degrees. When I do the same thing in python, the sum is 179.982xxxxxxxxxx. This also means that when applied to a plane, the two rotations do not produce co-planar planes. Do you have thoughts on how to achieve the same precision as with the grasshopper components using rhinoscriptsyntax in python? Appreciate any ideas you have.
Hi Kendra
just quickly adding some thoughts to the discussion.
The error that you are experiencing seems to be too high to be due to using degrees.
I might not be able to help further, but I was curious what Point.At is? rs.EvaluatePlane is in some ways the rhinoscriptsyntax equivalent to PointOriented. rs.VectorAngle is to some extents the equivalent to Grasshopper's Angle component.
Just some thoughts.
Giulio
--
Giulio Piacentino
Weaverbird development
Hey Giulio, thanks, I just tested out rs.VectorAngle really quickly , and came up with two angles using the same vectors as before which add up to 180.0000000000001. I need to understand more about it to get the angles I am looking for though. PointAt() is from the Rhino library, which I think does the same as rs.EvaluatePlane .... import Rhino, myPlane.PointAt(U,V,W).
Kendra
Hi again Kendra,
yes, 180.000000000000001 is not an issue, usually, numerically, if you take the right precautions. Grasshopper itself has to probably to do some low-significance noise reduction in these cases, too. The number differs from 180 by 5.6*10^{-16}, which is basically unsignificant and unavoidable with floating point calculations, and similar roundings will also happen in Grasshopper (there are some discussions I can remember on here, if you feel like searching).
On the other hand, 179.982 differs from 180 by a whopping 1*10^{-4}, or 0.1‰. That is not usually, from what I saw happening myself, the result of just floating point inaccuracy.
There are high chances that Grasshopper internally itself calls Plane.PointAt to get the point, and David might be able to tell more about that part.
Maybe you need to post some example for anyone to be able to help further?
I hope that helps, at least a little,
--
Giulio Piacentino
Weaverbird development
I suspect all methods in RhinoScript, RhinoPython, RhinoCommon, Grasshopper and any other development platform we have end up calling the same methods. I certainly didn't write my own Plane.PointAt() evaluator.
I agree with Giulio that the discrepancy seems to high to be due to typical floating point inaccuracies, perhaps numbers are rounded by accident somewhere?
--
David Rutten
david@mcneel.com
Poprad, Slovakia
© 2020 Created by Scott Davidson. Powered by