Garshasp Development Blog

We’re in the process of redesigning and rewriting the CPU and GPU-side code for Garshasp’s rendering pipeline. What I’m thinking about (and what we more-or-less have already) is an HDR, per-pixel-lit rendering with (pretty slow) shadow maps.
The new pipeline that I’m thinking about is like this:

1. Shadow Pass (once per shadow-casting light that affects the frustum):
   Render all shadow-casting geometry from the light view point and keep all the depth values in the render target.
   Hardware requirements: FP32 or (at least) FP16 texture support. I can pack the depth value in an A8R8G8B8 texture if this turns out to be a limiting requirement.
   Notes: OGRE handles this by default, and it probably does a better job than me (I never got the hang of all the different methods for PSM frustum calculations. )
2. Depth pass:
   Do an initial rendering of all opaque geometry to initialize the Z-buffer and also write the view-space pixel depths to a floating-point texture (because we SM3.0-era PC-developers can’t read from the Z-buffer directly.)
   Hardware requirements: FP32 or (at least) FP16 texture support. However, I can pack the depth value in an A8R8G8B8 texture if this turns out to be a limiting requirement.
   Notes: I should investigate interactions of this with MSAA.
3. Shadow Map Generation Pass:
   Render all shadow-receiving geometry and calculate whether each pixel is in shadow or not (and how much) using the information form the last two passes. The PCF and gang should be run here. If we decide to allow multiple shadow casting lights, we can do this calculation for four of them in this pass and write the result in different components of a single A8R8G8B8 render target. More will need MRT.
   Hardware Requirements: Nothing special.
   Notes: OGRE claims that it handles this by default. But it also provides an “Integrated Shadow” option which should give me more control (and more chances to mess things up!) I should think about whether I can integrate this pass with the last one. The only problems I see are the MRT prerequisite and the different render target bit-depth requirements (8 vs. 32.)
4. Render Pass:
   Render the glorious scene including the translucent objects and objects that need special treatment (fog volumes, light volumes, water,) using the shadow map generated in the last pass and the depth values from the pass before that (for the special effects.)
   Hardware Requirements: Will probably need SM3.0 or SM2.x if we want to support more than one or two lights. This is preferred to turning this into multiple passes, because of the number of our triangles and the large number of animations (rather costly vertex programs.) Also, will require FP_ARGB_16 for the render target; I’m hoping that every SM2.x card supports this with ease.
   Notes:
5. HDR Bloom:
   Very effective visually, although requires many, many passes (the number is also partly dependent on output resolution, because of the down-sampling.)
   Hardware Requirements: SM3.0 allows to dramatically reduce the number of required passes (from 10-15 to 4-5.) But I don’t think I have time to write two sets of shaders. Will have to see what our recommended requirements would be.
   Note: Other effects can be achieved while we are at it here (e.g. glow maps.)
6. Tonemapping:
   In effect, this is integrated into the last pass, but it’s too important not to get its own pass!
   Hardware Requirements: Nothing special that I can see.
   Notes: I need to read more on this. The few methods I have tried give great results but only on certain situations.

The easiest way of putting all this together is with a many-pass compositor. Yet OGRE does not let me access the intermediate textures easily (but I’ve seen this in the OGRE compositor demo! How is that done?!) Maybe I will be forced to put them one after the other in code, or at least generate the compositors in code, which is beneficial any way (easier adaptation to hardware and user config, etc.)

More to come.