Lightning Engine

Our first attempt on interactive editing of virtual textures.

Watch in high quality (recommended)

First some info about the video.
The virtual texture size is 128k x 128k with a 256 x 256 tile. Tiles are generated by a second thread on demand, using software rendering. There are 3 different layers and one decal in the above video. Currently only the diffuse color of each layer is baked, but the software rasterizer supports multiple render targets, so it shouldn’t be difficult to bake normalmaps or heightmaps at the same time.

Rendering virtual texture tiles
As it was mentioned in a previous post about virtual textures, our goal was to be able to use them with our existing terrain tools. Currently terrain texturing is done using material splatting and decals for extra detail. Inside the editor, the user selects a layer which he can paint on the terrain. The underlying structure keeps track of the weights of each layer and the renderer mixes all the layers together using shaders and framebuffer blending. In order to minimize the number of required draw calls when rendering a large heightmap, a prebaked base texture is used for distances above a threshold.

The demo used for the above video uses a similar structure for keeping track of the weights of each layer for each vertex, and generates the required tile data using software rendering. Blending of different layers is performed in one pass (independent of the number of layers) using shaders written in C/C++. Decals are rendered in separate passes in order to be able to rotate/scale/translate them on the terrain. As a side bonus of using separate draw calls for each decal type, we can skip shading and blending if the decal doesn’t affect the current tile. Whenever the user paints on the terrain, all the affected tiles are invalidated. Only the tile corresponding to the last mipmap level is forced to be generated synchronously, and it’s used until the other tiles are regenerated by the second thread.

Unfortunately, despite some small and obvious optimizations we were able to apply to the software rasterizer, each tile requires 18 msec on average in the case of a single layer and approximately 40 msec in the case of all three layers. This raises a problem if we are requesting all newly introduced tiles every frame, from the worker thread. Even with a rendering speed of 60 fps (16.7 msec), the second thread can only generate approximately 1 tile per frame. While the camera moves fast, a lot of new tiles are introduced every frame, and the worker’s thread queue gets full pretty fast. The end result is a long delay between tile requests and their availability. In order to avoid such situations, the class responsible for requesting tiles from the worker thread (lets call it “tile queue”) keeps a priority for each needed tile, which is updated every frame. This priority is based on the following factors:

1. The time of the last request. Tiles required for the current frame get a higher priority than those required in previous frames
2. Number of requests. Tiles which have been requested many times in the past frames get a higher priority because they will probably be needed in future frames
3. The tile’s mipmap level. Tiles covering a larger area of the terrain (higher mipmap levels) get a higher priority than more detailed tiles (lower mipmap levels)

At the end of each frame, the tile queue gets the chance to request the first n tiles with the highest priorities from the worker thread. This mechanism, paired with a hdd level cache for keeping recently generated – but not currently needed – tiles, gives us the fastest possible updates of the virtual texture. There is still some visible popping when moving around (especially when moving sideways or turning the camera fast), but this should be reduced further as the rasterizer gets faster. We are still working on optimizing this thing.

That’s all for now. There are still a couple of things we would like to test on the current demo, but I think it’s time to start implementing virtual textures inside the engine. The next post on the subject will probably come when we finish the integration, with a more interesting video from inside the terrain editor.

Thanks for reading.

JD

Tags: rendering, virtual_textures

This entry was posted on Saturday, November 15th, 2008 at 12:46 pm and is filed under rendering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.