Occasionally I'll have these crazy ideas; sometimes they come from something I've read, other times they seem to pop into my head from nowhere. Sometimes they are complete moonshine, other times they end up being useful and good.
The current one is relating to lightmaps. Handling lightmaps correctly (i.e. fast) in a multitextured renderer is not too easy. The way DirectQ currently does it is:
- Lightmaps are built in texture order.
- Tall but narrow lightmaps are used. Tall so that we can get a better chance of all surfs that use the same texture using the same lightmap. Narrow for dynamic light upload optimizations.
- For rendering, first we chain all surfaces by texture.
- Then we walk through each texture chain building up sub-chains by lightmap.
- Finally we walk through each lightmap chain doing the actual rendering.
So now we come back to today's crazy idea. The goal is to increase the number of surfaces that can be stored on each lightmap texture without affecting performance. Two ways spring to mind.
Lightmap textures could become cubemaps, with each face of the cubemap corresponding to a traditional lightmap. Some twiddling of texture coords would be needed to address the proper part of the cubemap, but texture changes could be cut by a factor of 6, thus enabling bigger batch sizes. The downside is that I would have to say goodbye to my tall-but-narrow lightmaps, as each face of a cubemap must be square. This might hurt dynamic light performance.
Alternatively lightmaps could become 3D textures. Each slice represents a traditional lightmap, addressing is easier (you just need to know which slice to use), we get to keep tall-but-narrow and all the other benefits, but we have additional restrictions on 3D textures imposed on us, including stricter size restrictions (but it might be possible to store all lightmaps for the entire world in a single 3D texture, thus totally eliminating texture changes).
Both of these are in the realm of the purely speculative at the moment, and I definitely haven't thought everything through. For example, DirectQ allows variable-sized lightmaps; how would they fit into such a picture? At what point in the past did 3D textures become commonly supported in hardware? Becchmarking of a tex2D vs a tex3D lookup also needs to be done.
However, if something works out from this it would be an exciting and interesting addition to 1.9; we'll see how things go.
Now back to 1.8.666!
1 comments:
That sounds interesting, I'd like to see what comes of it.
Post a Comment