PDA

View Full Version : Grid tesselation



JoshKlint
06-26-2009, 07:52 PM
I am working with roads on terrain and want to use a road mesh that conforms perfectly to the terrain, like how Crysis has. I do not want to raise the road mesh off the terrain. Attempts to adjust the depth offset with glPolygon offset have failed to produce good results. This is the problem:
http://www.leadwerks.com/post/roadbug.jpg

I have a road mesh constructed from a cubic spline. I want to divide the mesh up along the grid lines of the terrain. Is there any way to do this, besides calculating it myself on the CPU?

Ilian Dinev
06-26-2009, 08:41 PM
The only way to avoid z-fighting like that without offset is to use the _exact_ same floats (vec3) and transformation-matrix. So, your terrain will need to have that road imprinted on it; or the road must only reuse vertex-positions from the terrain.

I guess in Crysis they manually offset Z by multiplying the transformed Z by 0.99 (instead of subtracting a small number), and have depth-write disabled.

JoshKlint
06-26-2009, 09:52 PM
The only way to avoid z-fighting like that without offset is to use the _exact_ same floats (vec3) and transformation-matrix. So, your terrain will need to have that road imprinted on it; or the road must only reuse vertex-positions from the terrain.
That is what I am trying to do.


I guess in Crysis they manually offset Z by multiplying the transformed Z by 0.99 (instead of subtracting a small number), and have depth-write disabled.
Switch to wireframe view in the Crysis editor and you will see the roads use the same geometry as the terrain. However, they don't change when the terrain LOD changes, which makes me think they are using some kind of grid tesselation in DX9/10.

HellRaiZer
06-26-2009, 10:18 PM
AFAIK they don't do anything complicated. They just compute an extra mesh for the road by cutting the underlying terrain triangles. You can see that in two ways:
1) There are some edges on the road mesh which don't align with the terrain's triangle mesh edges (I wouldn't expect something like that if it was handled on the GPU/per-pixel;otoh i might be wrong)
2) Their road mesh generation is performed in another thread whenever you alter one of the control points. If you run the editor on a slow CPU, you can see the road disappear and pop in again.

You are right that the road doesn't follow the terrain's LOD. I guess they somehow offset the road (or the terrain) as Ilian said.

HellRaiZer

zed
06-27-2009, 01:21 AM
>>I have a road mesh constructed from a cubic spline<<

In that case polygon offset wont work (as you have found out)

Thus you will have to do what Ilian saiz

>>Switch to wireframe view in the Crysis editor and you will see the roads use the same geometry as the terrain. However, they don't change when the terrain LOD changes, which makes me think they are using some kind of grid tesselation in DX9/10<<
I dont think so, More likely theyre something like Ilian saiz

remdul
06-28-2009, 08:15 AM
FYI, in Battlefield 2, they slice the geometry along the terrain's grid lines and diagonally to match the diamond style triangle layout. The triangle soup is then cleaned up afterwards, merging vertices that are close. This is then stored for runtime use, presumably sub-divided in chunks to aid frustum culling. It doesn't change when terrain LOD changes, they fade out the roads in the distance; the underlying terrain has the roads baked in the texture. You can still see the terrain geometry stick through the road geometry at times (due to geo-mipmapping), but not often noticeable. There's no z-fighting, they do use glPolygonOffset/glDepthMask equivalent tricks.

Perhaps an interesting alternative would be to pass the spline to the terrain shader, and compute the road UVs from that (find closest point on spline), sample the road texture and layer it on to normal terrain texture. It would be completely geometry - and LOD - independent. IIRC, finding the closest point on a spline is difficult and probably GPU intensive though. I would store the spline data in a texture.