Real-Time Terrain Rendering Technique Exploration (RTTRTE??)
Posted: Fri Jun 09, 2006 10:10 amAs you might know, we've been developing a terrain workflow for our game project that's in development.
One of the goal's of the project is the most visually realistic outdoor enviornment yet achieved in real-time.
When researching LOD algorithms and the like (we eventually decided on geoclipmapping as a model), we struggled with the problem of requiring much higher detailed terrain at every given distance than any LOD system could reasonably accomidate. Even the hottest game engines, (Crytek's, Id's, ec) cannot represent terrain that has a reasonable level of detail at all distances.
One concept that we turned our attention to, was normal/parallax mapping. In game models, these techniques can indicate that a model has much more complexity than it actually does. The only real problem with these techniques is that they cannot "break silloutte," although some newer implementations have achieved even this hurdle. We have used the techniques extensively with our character and other model assets so it's only natural that we attempt to apply them to terrain.
The psuedo-workflow goes like this:
1. Create a terrain heightfield at double the size that you intend to use in-game (in our case we generate a terrain at 8192x8192). Apply as much complexity and realism to your maps as possible. We like to start with a L3DT design map, create the HF, then bring it into World Machine to add more algorithmic complexity and erosion (note you need the Standard Version of WM to do this). Then we bring it back into L3DT and regenerate the design maps.
2. Generate all additional maps: diffuse (in our case 8X instead of 16X due to the doubling), lightmaps, and normal maps.
3. Scale the heightfield down by 2. We've been using Photoshop for this and experimenting with different filters (they have varying results). This generates our real-time heightfield.
4. Create mipmaps (or your own LOD technique) of our RT heightfield (necessary in many LOD schemes including geoclipmapping).
5. For each Heightfield Mipmap level (other than 1 in our case), generate normal maps from the difference between the HF MM and the highres heightmap. Create different mipmap levels for the several normalmaps (+alpha if you're doing parallax mapping), using the same resizing technique (bicubic, nearest neigbor, etc...). To be effective I'd recommend quadrulpling the heightfield resolution on all levels but 1 (closest to cam).
6. Use a shader to apply the changes real time. Theoretically, we should see a much higher level of detail than would be geometrically possible, that extends into the distance.
As all texuring and lightmaps are based on the higher resolution heightfield, the effect should be smooth. For the nearest LOD level we plan on using normal maps to represent our detail layer (per type), rather than the high mesh geometry, as it could cause complications with its interaction with characters who use a physics hull based on the actual geometry rather than implied geometry. Depending your LOD algorithm your mileage with this particular challenge may vary.
That's the basic idea. We're in the process of testing it out on third-party rendering engines right now. We'll like to hear any thoughts or feedback from the community, or perhaps just spark a few peoples interests in trying it for themselves.
One of the goal's of the project is the most visually realistic outdoor enviornment yet achieved in real-time.
When researching LOD algorithms and the like (we eventually decided on geoclipmapping as a model), we struggled with the problem of requiring much higher detailed terrain at every given distance than any LOD system could reasonably accomidate. Even the hottest game engines, (Crytek's, Id's, ec) cannot represent terrain that has a reasonable level of detail at all distances.
One concept that we turned our attention to, was normal/parallax mapping. In game models, these techniques can indicate that a model has much more complexity than it actually does. The only real problem with these techniques is that they cannot "break silloutte," although some newer implementations have achieved even this hurdle. We have used the techniques extensively with our character and other model assets so it's only natural that we attempt to apply them to terrain.
The psuedo-workflow goes like this:
1. Create a terrain heightfield at double the size that you intend to use in-game (in our case we generate a terrain at 8192x8192). Apply as much complexity and realism to your maps as possible. We like to start with a L3DT design map, create the HF, then bring it into World Machine to add more algorithmic complexity and erosion (note you need the Standard Version of WM to do this). Then we bring it back into L3DT and regenerate the design maps.
2. Generate all additional maps: diffuse (in our case 8X instead of 16X due to the doubling), lightmaps, and normal maps.
3. Scale the heightfield down by 2. We've been using Photoshop for this and experimenting with different filters (they have varying results). This generates our real-time heightfield.
4. Create mipmaps (or your own LOD technique) of our RT heightfield (necessary in many LOD schemes including geoclipmapping).
5. For each Heightfield Mipmap level (other than 1 in our case), generate normal maps from the difference between the HF MM and the highres heightmap. Create different mipmap levels for the several normalmaps (+alpha if you're doing parallax mapping), using the same resizing technique (bicubic, nearest neigbor, etc...). To be effective I'd recommend quadrulpling the heightfield resolution on all levels but 1 (closest to cam).
6. Use a shader to apply the changes real time. Theoretically, we should see a much higher level of detail than would be geometrically possible, that extends into the distance.
As all texuring and lightmaps are based on the higher resolution heightfield, the effect should be smooth. For the nearest LOD level we plan on using normal maps to represent our detail layer (per type), rather than the high mesh geometry, as it could cause complications with its interaction with characters who use a physics hull based on the actual geometry rather than implied geometry. Depending your LOD algorithm your mileage with this particular challenge may vary.
That's the basic idea. We're in the process of testing it out on third-party rendering engines right now. We'll like to hear any thoughts or feedback from the community, or perhaps just spark a few peoples interests in trying it for themselves.
