View Full Version : opengl rendering's lack of precision

12-29-2002, 12:28 AM
I've made a subdivision system for terrains rendering, but I got a problem with my faces. It doesn't joint correctly when opengl render the scene (but I'm sure of the vertex coordinates) so it must be a lack of precision from opengl..
here's an illustration of the problem: http://divide.3dvf.net/dwerror.jpg
Is there a solution to this problem ?

12-29-2002, 01:22 AM
You have T-junctions in your geometry.

12-29-2002, 01:30 AM
yes that's true but the coordinates of theses T faces should makes them joint correctly (I zoomed and zoomed that area without seeing any hole) so the problem comes from opengl rendering.

12-29-2002, 01:38 AM
The artifact you see is a result of trying to combine a lower resolution mesh with a higher one. If you combine the meshes the way you do, it creates T vertices. To resolve these errors you need to implement a meshing algorithm that addresses these issues. www.vterrain.org (http://www.vterrain.org) is a good place to start.

12-29-2002, 02:05 AM
do you mean there's no way to get correct rendering with T vertices (even with high precision) ?

12-29-2002, 04:29 AM
so the problem comes from opengl rendering

It isn't OpenGLs precision, it's the data type precision. The more bits your data type has the more accurate your seems will be, but at a HUGE cost...one that I'm betting you don't want to spend.

It's best that all polygon corners meet at other polygon corners.

12-29-2002, 07:24 AM
Originally posted by divide:
do you mean there's no way to get correct rendering with T vertices (even with high precision) ?

no, u need to go


12-29-2002, 08:34 AM
I just wanted to point out that T-junctions are not an OpenGL problem and are issues even in production renders. IIRC the Advanced Renderman book has a section on how PRMan tries to fix up T-juctions caused by subdividing but I believe it points out that this is still not perfect. As mentioned above floating point math is extremely sensitive to order of operationds etc. If the number system can't reliably make:

x*(a + b) == x*a + x*b

It is impossible, to not crack with T-junctions as the math to interpolate to the point will be slightly different on both sides of the edge.


12-29-2002, 02:19 PM
To repeat what ehart said, and add just a little bit of my own input:
T-junction artifacts are inherent in a system that uses finite-precision, floating-point arithmetic; the more significant problem for modern real-time 3D graphics is that the artifacts are amplified by using point-sampled pixels.

The solution is to eliminate all t-junctions. If any vertex lies on any edge (not including its end points), then that edge merely needs to be split into two edges that happen to be colinear. How to do this for real-time LOD'ing terrain meshes is going to be highly dependent on your LOD algorithm, and chances are that people have already spent a lot of work on the problem for your approach.

12-29-2002, 02:51 PM
divide, you should win a prize for the most concise and eloquent description of a problem using an image.

12-29-2002, 10:09 PM
Well... it means I'll have to rewrite a big part of my code, arggh...
I tried this T junction method to avoid massive subdividing, like in ROAM algorithm.
Well I'll shake my brain and prey god for a fast and simple solution before I hit the "delete" key...

12-29-2002, 10:19 PM
There is an easy solution. Just add a vertex to the long straight edge of the T. That way you have four matching edges instead of 3 that cannot be transformed with infinite precision.