We bundle 12 world space direction segments into separate buckets, based on their generated ray direction. In order to get coherent data access, we bundle our rays into separate workgroups (or in terms of the OpenGL 4.2 implementation: different draw calls). This optimization alone saves 30% of the first bounce of secondary rays, depending on the scene.įor specular, we basically do the same and vary the number of local samples based on the materials roughness and metallic-value. If a screen space intersection wasn’t found, we path trace the ray in our BVH (Fig 1). If we’re able to detect a hit in the last frame’s irradiance buffer, we even get a local multi bounce reflection for free. Deferred path tracingįirst, we try to cast the diffuse rays in screen space. We ported the stackless traversal algorithm to run on OpenGL® 4.2 hardware, so that the kernel runs in a plain fragment or vertex shader without the need for Compute Shader or OpenCL™.
We vary between different tracing kernels across different hardware setups to achieve the best possible performance. We use Radeon Rays (formerly AMD FireRays) for the BVH construction and traversal. BVH unfriendly geometry with a high variation of polygon sizes.Risk of cache incoherence, thus destroying SIMT efficiency.Noise with varying spatial frequencies (like fireflies).High demand for memory bandwidth during traversal.We faced the following problems after naively implementing it: The core algorithm of classic Whitted-Style path tracing is brute force in nature, so we need to optimize here. Combined with screen-space diffuse rays, it gave plausible results, but the amount of cubemaps had to be enormous to cover medium frequency GI phenomenas. This was done at runtime and the cubemaps were updated when the lighting (or scene) had changed in their radius of influence. It placed cubemaps at positions where the average lengths or random rays that were cast from the cubemap were locally maximized. Even Voxel Cone Tracing struggles with pixel sharp off-screen reflections.įor the previous version of our renderer, we used an automated cubemap placement algorithm. Therefore, solutions like Light Propagation Volumes are not suitable. Since we want to change the time of day instantaneously and want very little loading times, light map baking is not an option.Īdditionally, glass is a design element of high importance – which means, we need sharp and correct reflections. Ideally, we want a GI solution that can be scaled across different hardware capabilities and can even produce photorealistic, crisp images at offline quality – if given a bit more time. Even for undetailed geometry without a lot of lights, it enables the viewer to grasp the underlying ideas and scales. Since CAD data is not specially prepared for real time rendering, global illumination is of high importance.
0 kommentar(er)
