Tolerance - scaling trimmed surface results in invalid geometry

[mse]

Hello!

I’m having some problems with my tolerances. I need to scale my GH geometry (in meters) by a 1000 because Revit work in mm and I’m using RiR to send stuff over to Revit. But once I scale my trimmed surface it becomes invalid.

-The object is 80meters from our 0,0,0 UCS
-I tried setting my my rhino tolerance differently. Everything between 1 and 0.001 (mm)
-I noticed the trimmed surface becomes invalid after I scale it more then 214 times.
-Once I Untrim the surface, scaling works perfectly. So I assume it has to do with the tolerances of trimming.
-It work If I Untrim scale, and scale the curve from the Trim separately and trim the surface after the scaling (see screenshot)

Does anyone have any suggestion how to fix this issue?

Thank you!

tolerance issue.gh (236.4 KB)

[Japhy]

Hi Mse,

I’m going to change the category to GH and see if anyone has any ideas.

Scaling baked geometry in the Rhino Document seems fine.

[inno]

I think the problem is not related to the Scale component, but the same that is currently being investigated by developers, like for these topics:

Grasshopper Bounding Box differs greatly from Rhino Bounding Box

it looks like a similar problem from this discussion (same youtrack log indeed ) in that discussion there was a polysurface that could be exploded and rejoined (solving the problem) but here there is a single untrimmed surface, can’t explode and rejoin, so I thought applying a zero-amount transormation could work: [image] BoundingBoxTest_Re.gh (145.9 KB)

Box generation for Brep returns unaccurate Box object

I have a brep geometry that is aligned to the world XY axis and is generated from boolean operations with other breps. When I want to calculate the Box of that object using a reference plane that is oriented along the YX axis, the dimensions of the box do not match the brep anymore. See the image below. [image] The issue is solved when I explode the brep and join it again in Rhino. But I would like to understand a bit better what the problem is and how I can avoid it in the future. Is there …

if you apply any kind of zero-magnitude transformation to your original geometry, then the Scale component works correctly:

tolerance issue_Re.gh (124.3 KB)

[wim (Wim Dekeyser)]

Hoi Maxime -

@mse

• It work If I Untrim scale, and scale the curve from the Trim separately and trim the surface after the scaling (see screenshot)

That, too, is dependent on the Rhino document tolerances - with that set to 0.001, it doesn’t work:

At any rate, is that input object supposed to be planar? It is oddly not quite planar as it is now.
It also seems unnecessarily complex:

Projecting the edges to make them planar, creating a new surface from those, and scaling seems to work fine:

-wim

[mse]

Hei Wim,

The surface is indeed complex, but the level of detail and accuracy of this floor is necessary for the design we’re making. Therefor making it planar cannot help. But indeed, scaling the planar srf indeed works.

@inno Yes that does work! But I can’t seem to understand how the zero magnitude transformation is fixing this issue What exactly changed the surface?

Thanks guys

[inno]

it looks like in some particular cases the referenced Geometries (we have seen this happening for polysurfaces as well as untrimmed surfaces) are not getting interpreted by GH as they should (again, why this happens is way above my level of comprehension…)

but when you apply a transformation to those Geometries in GH, somehow they get translated into something that GH can digest just fine again

the important point is applying a transformation that actually does not change the Geometry, for instance a zero-angle bend, or whatever

this trick was found by trial and error, it for sure won’t be necessary anymore whenever the bug is solved, but in the meanwhile it looks like working smoothly