Control points don't line up with geometry

Hello. I’m having an odd issue where my control points don’t line up with my geometry.

Has anyone else seen this? See attached image. This is a very zoomed up view of a corner point.

I was wondering if it’s some kind of graphic card issue?

1 Like

Hi Drew - how zoomed? What is the length , roughly, of the bit of surface edge that we can see there?



Super Zoomed… I was just messing around. Zoomed way up on a corner and noticed it’s off…

I drew another curve above this and those control points seem to be ok. The length of the top line is .0001"…

1 Like

:joy: :beers: nice haha. Push Rhino to the limit don’t hold back :grin:

I’m wondering if it might be ‘trim’ related, and maybe could use a ‘rebuild edges’ operation :blush:

1 Like

lol. yeah… what’s one more zero in the tolerance level? Speaking of… my Tolerance for RebuildEdge just says 1e-05… so I’m guessing that might as well be zero…

I dunno… moving on. Thought maybe it was a bug or me not understanding something… I don’t need to be that accurate. Just was curious.

1 Like

A trimmed surface usually does not have a control point at a corner of a trimmed edge.

My understanding (perhaps incorrect) is Rhino uses double precision floating point for geometry calculations and storage, but the GPU uses single precision floating point for turning the 3D geometry into 2D on the screen… Zoom in enough and you will see the limits of the display precision. If the discrepancy appears to jump around with magnification level then it almost certainly the limitations of the display precision.

1 Like

That sounds like the exact issue I’m having. Fascinating. Thanks for the insight!

Yeah I usually use that default scientific zero setting :sweat_smile:

Well maybe true, but I did fail to mention what can happen to surfaces over time as they are joined and exploded from time to time, and the edges can become ‘pulled away’. So there’s that too.

This is an interesting description of something I’ve never really understood. :star_struck: :beers: Definitely makes sense. :smiley:

Perhaps Rhino lets us zoom in too far :joy:

“0” in many Rhino settings means use the default value, not “zero”. And the default value may be very different than zero.

1 Like

Single precision arithmetic has not changed in the last 20 years.
Rhino’s display when zoomed way in is now designed to be inaccurate.
20 years ago using Rhino4 a user could zoom way in and and measure the distance between endpoints of 2 curves that were e-11 apart.

Every version of Rhino since Rhino4 has become less and less accurate when zoomed in.

Here is a file created in Rhino4 zoomed_in.3dm (20.1 KB)

This is what it looks like in Rhino4 and Rhino6

In Rhino4 you can accurately snap to the endpoints of the blue and green and Rhino4 command line will tell you Distance = 6.98573e-11 millimeters.

In Rhino6 you can no longer accurately snap to the endpoints (the snap points are not on the endpoints) and Rhino6 tells you Distance = 0.0000000 millimeters

In comparison to previous versions of Rhino, what you see when you open the file in Rhino8 is a joke.

In Rhino4 you can easily select the 2 red curves and run curve deviation.
Rhino4 tells you
Minimum deviation = 2.35453e-10
Maximum deviation = 9.27501e-09

In Rhino8 it is difficult to select the 2 red curves and Rhino8 tells you the crvdeviation of these 2 parallel lines is
Minimum deviation = 0
Maximum deviation = 2.44987e-10

1 Like

True, but I was specifically referring to:

Which is basically 0.00001 , so almost 0 :sweat_smile:

:exploding_head: :sob: now I miss R4 :sweat_smile:

I’ve asked about this issue internally.
fwiw I get this in Rhino 7:

and this in Rhino 8:

With command Testnumberformat (thanks @pascal )
I get this in Rhino 7:

so at least that seems to be on par with Rhino 4

Yes. That is what I am getting today, also. The numbers I copied and pasted above were from whatever version of V8 I had back in February.

But anyway, the issue is really only about the display precision. You have to zoom way out about 20 clicks of the zoom wheel to even pick the two red curves and then as anyone can see from your screen shot the points from CrvDeviation are far removed from the curves that those points are supposed to be on. I suspect the points are accurately shown where they are supposed to be, its the curve display that’s off a bunch.

In Rhino4 zoomed in to that level there was essentially no degradation of display accuracy. In Rhino4 you can zoom in a lot farther still without any degradation.

Rhino7 is not terribly bad. The degradation of the display in V7 at this level of zoom is only off by a few pixels at most. At this level of zoom, the inaccuracy in V8 is off thousands of pixels.

Yes currently Rhino 8 does odd things when zoomed in. I think that is covered in the linked thread’s YT, but I will check this again after that has been addressed.

@jim I also logged RH-81220 Different results on CrvDeviation

1 Like

OMG I wish you had not done that…

Crvdeviation is probably the most accurate command left in Rhino.
And now that you brought up crvdeviation as an issue the response from Rhino developer team will be to make crvdeviation as inaccurate as they have made everything else.

The point I was making is that in previous versions of Rhino the user could zoom in and measure stuff as accurately as curve deviation does.

@jim well, the reason I logged it, is because Rhino 8 gives a different result than previous versions, which I found suspicious and imo needed investigation.

Maybe I misread something in the reply of @GregArden / @brian, but I think the gist is that with numbers this small it is approaching the limits of what can be measured in the first place.

I’m curious how numbers this small will affect your work.

The zoom bug is solved in current dujour builds btw.

I’m curious why you think a difference of around e-10 in crvdeviation is something that needs investigating? Distance measurements in general are limited to an accuracy of around e-7 or maybe e-8 on a good day. Why aren’t you investigating what can be done about that?

That is nonsense. The distance between points can be measured to e-15 (worst case).
The fact that Rhino refuses to show the user that level of accuracy does not mean it can’t be done.

I posted to this thread to complain about the inaccuracy of the Rhino8 display not about the accuracy of measurements.
But since you asked: Accurate numbers are important to me because they are vital in making a rock-solid case that Rhino8’s display when zoomed in is completely FUBAR.
Without accurate numbers to back up your case you get gaslighted by people telling you that its is just too much to expect the software and hardware to work at all when zoomed in. And of course that is not the only bug that has been uncovered and fixed over the years due to accurate measuring.

The reason I posted to this thread is that the example case you were using was just orthogonal lines. The display when zoomed in needs to work for all cases - not just orthogonal lines.
In another thread I just posted an example of point editing a curve to change the curve deviation from .0062" to .0016". I was unable to do that in Rhino8. The Rhino8 display is so screwed up when zooming in that it was impossible for me to make such small edits to a curve.

I certainly hope so.

I found it odd to see that Rhino 7 and Rhino 4 would give the exact same result, and Rhino 8 would give a different result. That’s all, I don’t know what the cause of that difference is and how it might affect other things that are significant. I leave that up to the people that wrote the code to decide.

When using Software OpenGL the display is fine.