Point.At (python) vs. Point Oriented (gh)

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

Replies to This Discussion

Permalink Reply by David Rutten on October 24, 2012 at 2:44am

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

Permalink Reply by person on October 28, 2012 at 11:21pm

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.

Permalink Reply by Giulio Piacentino on October 29, 2012 at 4:00am

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

Permalink Reply by person on October 29, 2012 at 9:13am

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

Permalink Reply by Giulio Piacentino on October 29, 2012 at 10:58am

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

Permalink Reply by David Rutten on October 29, 2012 at 1:10pm

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

RSS