When I zoom in, a surface and its outline become separated. This makes it difficult to tell if things are overlapping or not. I’ve tried increasing the mesh parameters but didn’t do anyhting.
But you have to zoom in a very long way, way beyond the drawing tolerance. I just tried this in a drawing with tolerance set to 0.001 and the apparent offset between line and fill is around 0.0000007 (it fluctuates a little as you zoom).
Your green and blue objects don’t overlap to tolerance (indeed probably don’t to a far tighter degree, but that is a meaningless concept when you can only work to a tolerance).
I don’t understand your point. if lines the points are coincident within tolerance, they should be displayed that way
They are displayed that way at (and beyond) the drawing tolerance. But zooming in further doesn’t tell you anything more about whether the items overlap, regardless whether the line and fill match up or not.
So I guess the point is that while the offset is disconcerting when one first notices it (and Rhino has always exhibited this behaviour) one ends up just accepting that’s how it is. And one stops zooming in further than necessary so one stops seeing it, and eventually forgets about it.
This is within tolerance, but this is probably a side effect of the V6 GPU tessellation in Options > View > OpenGL.
If you uncheck the option, Rhino will clean up that display quirk, but your display performance will suffer greatly as well.
I tried turning off GPU and using very small tolerance but it hasn’t done anything. I’m not sure how I’m supposed make precise models… the gap is way bigger than the tolerance I have set
Also tried Rhino 5 with no graphics acceleration, which just makes it worse. Same problem with hatches, not only surfaces
Don’t pay attention to the color fill. Pay attention to the edges themselves. Those matter. Fill doesn’t. Ignore it. You may need to click on your objects to select them to bring to front so you can compare other edges against it.
How far from the origin are your objects?
1 Like
@parex
The other possibility is how far your model is from the 0,0 World origin.
When you’re working near that surface, what is the coordinate display on the left end of the Status Bar at the bottom of the Rhino application window?
Isn’t this kind of a moot point? I mean, working visually to see if your edges line up… sounds like not the way to work; for increased accuracy, use your object snaps instead of depending on how things appear at different zoom levels.
1 Like
the problem doesn’t seem to be present with meshes. only surfaces and hatches
No more reply or explications from mc neel?
Thanks,
Roy
Hi - please post a file that misbehaves on your system.
-wim
You are seeing the results of the finite precision of the digital arithmetic used in the graphics calculations. You can tell it is due to the graphics calculations because the ends move relative to each other as you change zoom level or pan. The largest apparent gaps are around. 0.000002 units in size. In contrast the absolute tolerance in your file is set to 0.01 units or 5000 times larger.
Is this causing any actual problems?
Hi David,
thanks for your reply.
The only problem for me is that sometimes to be sure some edges are adjacents i zoom to watch it and this situation confuse me (only in some case of course).
I think it could be better if the zoom could be “Stopped” at a step before to show this problem. Rhino is a precise software and i think Mcneel could be find a better solution.
That’s of course is only my opinion! (to avoid messages of people that each time I make a critic to Rhino , they get nervous…lol)
Been there, done that. I now use CrvDeviation to check. In addition to lines and curves it accepts edges as input.
1 Like
I’ve tested your method.
I have two edges from polysurfaces created using snaps (so they must be adjacent), showing me a maximum deviation of 1.13687e-12…why not 0?
and if I’ve created some polysurfaces on different levels and i wanna know if they are correctly aligned I need to spend one day using CrvDeviation to check one edge at the time…
1.13687e-12 is 0.0000000000113687. For most purposes that is essentially zero.
Several possible reasons why it is not zero:
-
Finite precision digital arithmetic. Computers work with a finite number of digits which leads to truncation/rounding errors. For example to write 1/3 exactly as a decimal number requires an infinite number of digits: 0.3333333… with the three repeating. Similarly the sine of 45 degrees cannot be represented exactly using a finite number of digits. So many calculations have very small errors which can accumulate. Fortunately for most uses the accumulated errors remain small enough to be insignificant,
-
Limitations of NURBS mathematics. Intersect two NURBS surfaces with arbitrary shape and the intersections usually cannot be represented exactly as a NURBS curve. Project a curve onto an
NURBS surface and the projection usually cannot be represented exactly as a NURBS curve. But if enough control points are used the results can be approximated as a NURBS curve with any desired level of accuracy. The tradeoff is increased accuracy usually required more control points which is generally undesirable. The absolute tolerance setting helps guide Rhino into deciding how many control points to use. -
Modeling practices. Unless adjacent curves or surfaces have the same or compatible structures (degree, weights, number of control points, knot vector, location of control points) there will usually be a difference between them. Some Rhino commands have “Refine” options to add control points and/or restructure curves and surfaces to improve the matching. One element of precision modeling is learning how to structure models to reduce or eliminate this type of problem.
How accurate do the polysurfaces need to be aligned? For what reason?
The Align command can be used to align multiple objects within the limits of finite accuracy digital math. They can be aligned using with world or CPlane coordinates.
Orient, Orient3Pt, OrientCrvToEdge, OrientOnCrv and OrientOnSrf can be useful in aligning objects.
Another method is to use Move using corresponding points on two objects.
For planar surfaces or straight lines I use SetPt to ensure the surface or curve is at the desired location if I think it may be out of position.
Finally, work to develop workflows which ensure that the objects are where they should be within the required accuracy without needed to always verify.
1 Like