Real time

Real-time

Possibilities

There are multiple Integrators oriented towards real-time rendering:

• PrimTracer is able to display results ranging from normals, uv coordinates to direct lighting.
• GameTracer ( diagram below) tries to approximate the rendering equation in two steps. First it carries out direct lighting at the primary hit point; then it samples 4 random outgoing directions, and at these hit points it carries out another direct lighting computation. All this is done per 4 pixel neighborhood to achieve smooth results with less noise. It can also average the direct/indirect computations with the last frame to reduce temporal incoherence. The goal here is to reach something around 20 FPS without much noise, obviously sacrificing any realism. WARNING Active Development
• WavefrontPathTracer is inspired by the work of Samuli Laine; Tero Karras; Timo Aila in Megakernels Considered Harmful: Wavefront Path Tracing on GPUs. Separation of ray tracing kernels and connection kernels is done, although no separation for different material types. This gives a speedup of about a factor of 2 compared to path tracing in a single kernel. Sometimes this is enough for pseudo real-time although temporal noise is a problem.
• FastTracer can be used in ginormous scenes where all other options are too slow. It does only one trace for each pixel and plots the depth value.

Limitations

The root problem with real-time applications in this library is the interface of the bsdf/emitter sampling. It uses structs with a significant amount of members which for realtime are mostly irrelevant. This generalism of course enables all physically realistic integrators but is a hindrance here. It would be necessary to determine which classes are actually needed for realtime path tracing, for example if there are any other light types besides area lights. Using such an approach, some of the Aggregator classes can be left out and lane level divergence reduced.

Another limitation is the fact that the skeletal animation module has to be run while there is no active rendering happening. This can be avoided by using a double buffering approach where the animation frame BVH rebuilder uses a buffer which is currently not in use on the GPU. The BVH rebuilder itself works on the host which is sufficient for small or only few models. This will definitely not scale well to game level scenes with hundreds of animated models. There are two possibilities here: either use a GPU implementation for BVH rebuilding, thus leaving less time for rendering. The other option is to build less optimized BVHs by performing less tree rotations and perform a complete rebuild every other frame.

Further Development

The BVH layout and Kepler code of Understanding the Efficiency of Ray Traversal on GPUs is used here because it was extensively researched by the authors. In recent years there were other papers in this field such as Stackless Multi-BVH Traversal for CPU, MIC and GPU Ray Tracing. Implementing this resulted in only subtle differences in traversal times and in more complex memory structures.

Other papers such as Occluder Simplification using Planar Sections might be worth implementing for real time shadow tests.