Bug? Rhino isn't accurate far from origin

[Holo]

In theory yes, but in reality I don’t know how much that would be. Subtracting a fixed number from those numbers is something a cpu does lightning fast. And working with smaller numbers could potentially be faster, so it might even it out, it would be interesting to see it in real life.

[menno (Menno Deij - van Rijswijk)]

I expect that many graphic cards will use single precision for rendering. That means that even though your render mesh may be defined in double precision, it will still look jagged on screen.

[stevebaer]

@menno

I expect that many graphic cards will use single precision for rendering. That means that even though your render mesh may be defined in double precision, it will still look jagged on screen.

Almost all (if not all) graphics cards use single precision. OpenGL apis have functions for double precision, but I haven’t seen a card yet that really uses those numbers as doubles. When Rhino geometry is far from the origin, we place a scaled and translated copy of the geometry on the GPU with values that are “nice” for floats. We then apply the transform to the world to clip matrix in double precision on the CPU before setting the world to clip transform in a shader.

There is a difference between visual inaccuracies and numerical inaccuracies for geometric calculations. We should have most of the visual inaccuracies fixed at this point. If there are samples where things look wrong in Rhino 7, please let me know.

[davidcockey]

@Holo

This could be solved by a max drawing bounding box where all calculations handled by the graphiccard uses that bounding box as “world”, and eliminating objects outside that box. How difficult it would be to incorporate I don’t know, nor how much of a performance hit, or gain for that sake.

@stevebaer

When Rhino geometry is far from the origin, we place a scaled and translated copy of the geometry on the GPU with values that are “nice” for floats. We then apply the transform to the world to clip matrix in double precision on the CPU before setting the world to clip transform in a shader.

Looks like Rhino already does what Holo suggested.

[Holo]

@stevebaer

If there are samples where things look wrong in Rhino 7, please let me know.

Hi Steve, this seems to be rather buggy:

The circle is 1 meter wide.
The yellow polyline goes from w0,0,0 to this position (UTM32).

It would be great if the display pipeline could draw correctly the close-to-camera part of the curves if that would be possible.

I understand that these long curves are rare, but it illustrates an issue with tolerances.
So since you asked for “bugs” I felt the urge to provide

[stevebaer]

This is a super hard case to get right without performing all calcs on the CPU and bringing display speed way down. Luckily it is a bit on the rare side.