Align and BoundingBox - Major inaccuracies due to mesh settings

(This thread was inspired by https://discourse.mcneel.com/t/why-rhino-is-not-accurate-enough-with-cplanes/178237.)

The accuracy of the results of Align and BoundingBox can depend on the render mesh settings when surfaces or similar are involved. Depending on the mesh settings when Align or BoundingBox is executed this can result in errors considerably greater than the absolute tolerance setting.

Example of Align error. A plane is aligned to the right side of a simplifed torus. The torus sits at an angle, and has an outher diameter of 300. AlignRenderExampleDC01.3dm (2.0 MB).

Align was run twice, with the NURBS meshing slider to the left at “Fewer polygons”, with the NURBS meshing slider to the left at “More polygons”

The Align error with the coarser mesh is 1.62 . This is obviously larger than any absolute tolerance.

Example of BoundingBox error. The same simplified torus at an angle was used.
BBRenderExampleDC01.3dm (2.0 MB)

NURBS meshing slider to the left at “Fewer polygons”:
World coordinates:
min = -135.08865356445312,-150.00000000000003,-99.099037170410156
max = 134.97492980957031,150.00000000000003,98.991752624511719
dimensions = 270.06358337402344, 300.00000000000006, 198.09078979492188

NURBS meshing slider to the left at “More polygons”:
World coordinates:
World coordinates:
min = -136.59068298339844,-150.00000000000003,-99.989486694335938
max = 136.59756469726562,150.00000000000003,99.996353149414062
dimensions = 273.18824768066406, 300.00000000000006, 199.98583984375

The differences in dimensions reported by BoundingBox are: 3.13, 0.00, 1.90.
The maximum difference in dimensions is greater than one percent of the largest dimension. This difference is larger than any tolerance.

The user should not need to ensure that they are using mesh settings which are result in a fine enough mesh for accuracy.

This needs to be fixed sooner rather than later.

Update:

With the NURBS mesh slider set to it’s midpoint which results in a mesh which appears to be smooth:

Align error with the mid setting is 0.1721038818359375
AlignRenderExampleDC02.3dm (2.0 MB)
This is still larger than the recommended absolute tolerance range.

BoundingBox dimensions with the mid setting:
World coordinates:
min = -136.35881042480469,-150.00000000000003,-99.800262451171875
max = 136.42546081542969,150.00000000000003,99.867591857910156
dimensions = 272.78427124023438, 300.00000000000006, 199.66785430908203

The difference from the finer mesh in the dimensions reported by BoundingBox are: 0.44, 0.00, 0.32. This difference is larger the recommended absolute tolerance range.
BBRenderExampleDC02.3dm (2.1 MB)

4 Likes

Hi @davidcockey,

I’ve logged the issue so we can look into this.

https://mcneel.myjetbrains.com/youtrack/issue/RH-81226

Thanks,

– Dale

1 Like

@dale @wim @stevebaer @Gijs I looked at the discussion on YouTrack, and that discussion appears to be based on a misunderstanding of this issue.

This issue can be fixed while retaining the use of single precision meshes in Align and BoundingBox.

It is NOT caused by the use of single precision meshes. (A change to double precision meshes would not fix this issue.)

This issue is caused by Align and BoundingBox using too coarse a mesh due to the use of a mesh resulting from the “mesh settings” in Document properties.

The fix for this problem is to ensure the mesh used by Align and BoundingBox is sufficiently refined (at least locally near extrema) to ensure accuracy within the user set absolute tolerance.

As shown with the example the errors in Align and BoundingBox can be significantly larger than the absolute tolerance, and lead to fundamental problems with geometry. It needs to be fixed soon, not several years in the future in 9.x.

1 Like

We’ve not proposing this as a solution.

– Dale

@dale I don’t understand what you mean by your response to my statement. What do you mean by “this”?

The significant issue described in this thread be fixed while retaining the use of single precision meshes in Align and BoundingBox. It appears that this has not been recognized by anyone at McNeel.

Although bb is partially mesh dependent, in the original example that Bobi posted / the yt that I made I tried several mesh settings to see if I could improve the result. But the result did not get any better at extreme high mesh settings. In case of a torus with a coarse mesh, the bounding box can get significantly smaller than the actual object if the isocurves don’t pass through the extremities.

While good mesh settings improve the bb result if the bb is too small, it does not fix the issue. In the case posted in the yt, the generated bb was always slightly larger.

@Gijs Thanks for your reply. But it looks like there is a misunderstanding. This thread is not about

I understand the issue I describe above appears at first glance to be essentially the same as Bobi’s issue. However it is fundamentally different, and which can cause significant inaccuracy, larger than the absolute tolerance. It affects the Align command which can be essential for some modeling. I also suspect it affects BoxEdit but have not tested that command. This issue needs to be fixed sooner than several years in the future in “9.x”.

I understand. I think the yt Dale posted shoots for a more definite solution while your proposal is for a fix within the current limitations.
I wonder what is needed to ensure a correct bb within tolerance and if that doesn’t potentially make bb related commands unusably slow. It has to work with complex polysurfaces as well.