Daniel Pohl has a new article at his site about his efforts to ray trace the game Quake Wars at interactive rates. This article is not heavy-duty, and has some interesting tidbits and visualizations. For example, it turns out that cut-out textures (used for making trees, for example) are pretty expensive for his ray tracer. The problem is that a new ray must be spawned after each intersection is detected. The headache for ray tracing (at least in this system) is that the texture itself is not accessed at the time of intersection – deferred shading, essentially. So the ray tracer does not know that the ray has, in fact, not hit anything (i.e., hit a fully-transparent texel) and could continue unaffected. He also talks about other optimizations that have helped and might help in the future.

What I find exciting about Daniel’s work is that he’s working with data that was optimized for rasterization, not for ray tracing. If ray tracing was suddenly 10x faster than GPU rasterization with existing hardware in, say, DirectX 11 (keep dreaming), it wouldn’t matter that much in the short-term. For most companies there’s a lot of investment in training, workflows, and tools for producing games. For example, look how long it took normal mapping to become a mainstream feature, well after all new GPUs could support it (around 2002 with SM 2.0). So, ray tracing existing models I see as useful for determining whether ray tracing is feasible for current games, while also finding pain-points (such as cutout textures) that will be present in artist-generated content for some time to come.