Home | Software | Articles | Photos |
---|
Introduction |
Closer look reveals possible cause, there remain serious usability problems related to typical global illumination software, mainly:
Problem of full interactivity has been studied with interesting results from Keller [1], he offers fully dynamic and realtime solution, rendering is slower, speed depends on requested quality. Keller's results from 1997 are hard to compare with todays renderers, so we reimplemented it on nVidia GeForce 6600: 30000 triangle scene with 1000 light samples was rendered at 3fps, including generation of 1000 shadowmaps. Speed may be increased by caching intermediate results. New approach with very high quality realtime outputs is presented by Kristensen et al [2], but it is suitable only for relighting of static geometry, expensive precomputations are required.
Problem of incompatibilities between global illumination solver and arbitrary local illumination renderer and ways to smooth integration probably haven't been studied.
We present novel approach to integration of global illumination solver into arbitrary realtime local illumination rendering systems. Our approach makes no assumptions about local illumination model and extends it to global illumination while not slowing it down. So when applied to arbitrary realtime local illumination renderer, it contributes also to domain of interactive radiosity.
Our process uses local illumination renderer to output specific images, those are analyzed and complete input information for global illumination renderer is automatically extracted.
An example is presented in form of realtime radiosity viewer.
Integration |
First, material properties of scene surfaces must be acquired. This is handled by rendering all scene surfaces into several texture(s):
This way we detect basic properties, which is often enough for adequate global illumination. It is possible and option for future experiments to acquire complete BRDF function for every pixel in scene. This could be done by repeatedly placing light and camera to different positions relative to face being rendered.
Although acquiring BRDF would take seconds to minutes for medium size scene, material properties detected in this step don't change during light or object manipulation in scene, so eventual slowness of detection doesn't affect later realtime rendering and relighting during scene manipulation.
Second, local illumination present in scene must be acquired. This is done by clearing texture to black and rendering scene surfaces into it using all local lights present in scene. RGB colors in texture correspond to material's response to local illumination + material's own emittance. For conversion between RGB colors and radiometry units, we use standard 0.45 power approximation.
Rendering all faces into texture without affecting local illumination may require changes in renderer. We use optional position overwrite at the end of affected vertex shaders. Whole vertex shader, possibly including lighting/shadowing computations, works with its usual 3D positions as if rendering to screen, our face position in texture is loaded before shader end from additional vertex stream.
For realistic response to primary illumination, it is important to render into float texture, so oversaturated regions are processed without clamping to max displayable color.
This step is repeated after each light or object manipulation in scene, so it should be as fast as possible.
We found that 3D scenes typically contain only small number of large faces, so after adding small number of vertices and splitting large faces, we may detect local illumination per face instead of per pixel, without visible loss of quality.
Third, illumination calculated by global illumination solver (using material properties and local illumination detected in first two steps) is added to local illumination renderer as ambient term. In case of our example viewer, it is added per vertex.
Scene Sponza atrium is example of not adjusted scene with large faces
on the floor. Local illumination in our example viewer is detected per face
and indirect illumination rendered per face,
which causes visible errors in illumination.
Viewer |
Viewer may freely manipulate camera and light positions in scene. Global illumination quality is temporarily decreased after each light manipulation. Currently there is no possibility to manipulate scene, but it may be added in future version, since it would make only small performance loss.
Light in viewer has no distance attenuation, but anyone can add it by modifying GLSL shaders. Changes of local illumination model are completely transparent and don't require recompilation.
OpenGL 2.0 capable graphics card is required, tested on NVIDIA GeForce 6600, ATI Radeon X800. May work with other .3ds scenes, but it wasn't tested.
Thanks to
Download |
Realtime radiosity libraries are available at Lightsprint.
Conclusion |
References |
Author |