Jump to content
  • Advertisement
  • entries
  • comments
  • views

Multi-pass rendering

Sign in to follow this  


As a related aside to my explorations of the programmable pipeline, I've been giving some thought to how I'd make a graphics engine.

Not from a programming language/architectural point of view, but from a theoretical - if it just automagically existed, what would it do...

I don't have time to dig up the exact references, but I remember reading that someone suggested that complex renderman shaders (arguably where we want real-time shaders to be) could be broken down into a lot of relatively simple passes... and the final renderman shader executed as a series of 10...20...50...N passes.

That's a nice idea, but in that context probably isn't real-time. Yet.

I do also remember reading that John Carmack cited the previous talk as, in retrospect, a defining statement:
There was an important paper that came out at SIGGRAPH a few years ago by someone at SGI.

He presented one real-time renderer and he presented something that showed the decomposition of Renderman shaders into multi-pass stuff that required floating-point and pixel stuff.

It was amusing because I remember people completely discounting that paper, which I think is going to be looked back at as one of the most seminal things in interactive graphics.

People were saying the Renderman shader was ridiculous - it took 500 passes to do this simple shader. People just hit this number - 500 passes, and clicked it out of their brain as not relevant.

But a pixel in Doom 3 may have 80 textures combined on to it.
- One of the many sources for this quote

Modern interactive graphics on consumer hardware is going in that direction - in one form or another a lot of engines perform a lot of passes to build up an image. It might not be the 20...50 (etc..) passes required for a renderman shader, but it's showing signs of going in that direction.

So, there are two areas that multipass seems to revolve around - at least, as far as my conceptual idea goes.

  1. Compose the intitial scene rendering
    This seems to break down on the number of lights used in a scene. It is possible with shaders to perform multiple lighting calculations per-pass, but that's more of an implementation detail than the theory. For each light we calculate it's contribution to the scene - especially with shadow information. I see shadows as one of the important parts of a modern interactive graphics engine.

  2. Perform post processing effects
    Now this stage could be optional in some respects, but for my conceptual graphics engine i'd have to demand a high dynamic range post-processing. Maybe not necessarily the overdone "new lens flare" bloom effects, but definitely a higher dynamic range of colours adjusted to a correct exposure/balance. With the power available to us in consume hardware, I see this as a basic forward looking feature. HDRI rendering, both "true" and "fake" implementations work on the basis of multiple passes.

So you'd end up with a set of initial passes that would composite an HDRI image together. The ability to store HDR values should be a very important concept for the multi-pass additive lighting (which I used in my D3D9 article here). The engine would then take this HDR image and split out the LDR and HDR values, perform the necessary filters on them, measure luminance and determine the adjustments required. Composite it all backtogether to give you a final image.

Each of the involved steps is relatively simple, but the result as a whole would be phenomenal. Such is the power of a multi-pass approach.

I've run out of time tonight, but if anyone wants me to cover the actual rendering process with a couple of diagrams send me a private message or leave a comment below [grin]

I hope that was of interest!
Sign in to follow this  


Recommended Comments

Very interesting indeed. Someday I'd like to make a modern graphics engine.

Share this comment

Link to comment
You probably want to take a look at "deferred rendering" (aka deferred shading) for a novel but powerful twist on multipass rendering. [smile]

Share this comment

Link to comment
Thanks for the comments..

Someday I'd like to make a modern graphics engine.

As per my initial entry - Easier Said Than Done™ [smile]

Although, my final year dissertation is involving offline surface analysis and HDRI-based real-time surface representation, which is essentially an implementation of what I've described...

You probably want to take a look at "deferred rendering" (aka deferred shading) for a novel but powerful twist on multipass rendering. [smile]

I've had a quick read of some of the Nvidia/ATI (think it was one of those two..) papers and got the general idea... but never had a chance to look into it properly and fully understand how it works. It does look interesting though - thanks for the tip!


Share this comment

Link to comment
I dont know enough to say anything meaningful and so shall instead note that *ahem*, you are using colors again.

So uhm...what are you doing? Why is the number of colors in that post so high? Havent you learned your lesson already? tsk, tsk.. I'll let you off with a warning this time.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!