I'll dive directly into the actual issue I'm investigating: Rendering smoke!
Smoke rendering is a very complex problem in real-time 3D graphics, because there are a lot of interacting parts. As it deals with transparency, the ordering becomes non-trivial and an order-independent rendering technique is ideal to avoid the requirement of sorting. Further complexity arises when lighting is supposed to be applied to the smoke, as the smoke can self-shadow. In addition, multiple separate smoke "systems" with different properties and scale (say a cloud, some cigarette smoke, fog on an early morning and atmospheric-scale scattering effects) can all interact and require merging and sorting together for accurate effects, as the different smoke clouds cannot be handled separately.
My project will NOT be about how to simulate smoke motion, and will not involve complicated self-shadowing. although the algorithm described IS compatible with such advanced techniques. Instead, the project will focus solely on the issue of sorting, merging and lighting multiple intersecting smoke clouds in an efficient way on modern GPUs.
Smoke rendering, like any kind of volumetric rendering, requires integration across the smoke volumes per pixel. This is essentialy ray-tracing, which is commonly avoided for real-time graphics due to its steep performance cost. Still, GPUs nowadays are fast enough to take hundreds or even thousands of samples for each pixel on the screen and still maintain real-time performance, but even with thousands of samples it is still often not enough to accurately represent effects of vastly different scale.
Physically-based & Unified Volumetric Rendering in Frostbite is a very interesting presentation that details an implementation of the most common modern approach to this problem. In essence, the view frustum is split up into "froxels" (a frustum-aligned voxel), which each contain the smoke parameters of a certain part of the frustum's volume. With the froxel buffer set up, different smoke clouds can be ray-traced independently and injected into the froxel buffer. Once all smoke clouds have been integrated into the froxel buffer, the buffer itself can the be lit by lights and shaded independently of the different smoke systems that were used to build the buffer. This means that a cloud, some cigarette smoke, some fog and the smoke from a large fire can all be integrated into a single data structure, which can then be lit independently of these smoke systems. This decouples smoke "sorting"/merging from smoke lighting, allowing for much more scalable performance. It's essentially the smoke version of deferred shading/lighting, which provides a similar advantage for opaque rendering where it decouples lighting from the objects and triangles that are being rendered.
Froxels have some big problems though. They use a lot of memory as they need to store a lot of volumetric data. In practice, this needs to be mitigated by significantly dropping the resolution of the smoke rendering, which makes it hard to catch detailed smoke effects like thin cigarette smoke. In addition, the limited number of layers along the depth of the camera can cause issues as well as the spacing of these depth layers depend on the depth complexity of the scene. For a large-scale outdoor scene, the layers will have to be spaced so far away from each other that the algorithm no longer provides a meaningful way of sorting smoke clouds along depth, instead simply merging the two into the same froxel layer. This can again increase blurriness and make it difficult to mix smoke effects on different scales with adequate quality.
The algorithm that I'll be investigating in this project provides a related approach, but there are some key differences that can provide significant advantages over the depth layer/"froxel" approach. My next blog post will detail the basic idea behind my new algorithm.
No comments:
Post a Comment