Testing for surfaces "geometrical" equality FAILS when reparameterized [BUG?]

working in ghpython, testing if two nurbsSurfaces are “equal” using NurbsSurface.EpsionEquals() and GeometryBase.GeometryEquals()

It does not detect two surfaces that are geometrically the same exact thing. Why Not? What Am I missing? Should I use another method?

thanks

feeling very stupid here

profoundly…

Solved, python component geometry casting was the culprit. Worked with “geometryBase” and plain “no Type hint”.

I would like to understand why casting to “surface” was throwing false results, I doesn’t make much sense to me.

What conditions are necessary to satisfy so two surfaces pass the GeometryBase.GeometryEquals() test??

I’m facing more errors with equility test: If same surface (taken form single face brep) is reparameterized, equality start to fail again. What’s going on? could someone confirm if this is a BUG or is it me? How can I check if two “equal” but reparameterized surfaces are effectively the same?

(input parameters are set as “No Type Hint” to avoid any intromision)

the same goes in C#, so it’s not ghPython specific


GeometricalyEqual FAIL.gh (6.5 KB)

I’ve reported RH-62548.
I’ll have to check what causes this not to work. I suspect something deep inside Rhino.

Thanks,

Giulio


Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

1 Like

Hey @aitorleceta,

I’m confused, why are you reparametrizing the surface? Generally speaking, this is a bad idea.

Also, Rhino’s GeometryEquals isn’t really that sophisticated. Basically the data structure of the objects must be equal.

– Dale

I always has believed that reparameterization is a “geometrically neutral” operation. Why is a bad idea?
At the moment, I used to have more meaningful parameter values, but certainly a srf.Interval.T0 / T1 would be enough, without the need for a reparameterization.

So, you think that GeometryEquals test could be failing because of this reparameterization?

Hi @aitorleceta,

Poorly parameterized objects may not intersect and trim properly when combined with other objects. “Poorly parameterized” means the curve’s domain or the surface’s u or v spaces are tiny or huge compared to the size of the object.

When curves and surfaces are parameterized with a [0,1] domain, both the accuracy and the precision of geometric calculations like intersections and closest points are reduced, sometimes dramatically. Ideally the domain of a curve is close to it’s length and the domains of a surface is close to is average breadth in the appropriate direction.

We try to have parameterization match the length of a curve or some measure of the width of the surface. Derivative information is better if we do it this way.

If you need normalized parameters, for some calculation, etc., then use the methods on Interval for converting from “regular” parameters to normalized, and vice versa. These are simple math calculations, and a far better approach than re-parameterizing curves and surfaces.

Regarding the GeometryEquals issue, this has been fixed. See the link to the issue above for details.

– Dale

1 Like

Thanks Dale for your explanation, it was very instructive and of great interest.
Also thanks for solving the issue, nice to see the sdk getting better and better.