Multipass Shaders In OpenGL

toneburst's picture

This is a general question, really.

Just wondering if the following is possible in OpenGL (and hopefully also in a QC Plugin):

I'd like to:

  1. Create a dynamic mesh using a parametric formula and a Vertex Shader

  2. Use a Fragment Shader to compute a depth-map for the resulting geometry

  3. Take the geometry created in step 1 and apply a 2nd Fragment Shader, using the depth-map created in step 2 as a texture.

I'm imagining this is possible using VBOs and PBOs (or some other kind of 'BOs'), but is this the case?

a|x

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cwright's picture
*BO & passes

Why are steps 2 and 3 separated? (couldn't you calculate the depth map in step 2, and also apply the step 3 fragment shader to the results, all in the same shader?)

Assuming that it needs to be separate, it is probably possible in OpenGL.

VBO = Vertex Buffer Object -- just stores arbitrary geometry (and normals, and tex coords, and vertex colors). Doesn't care about shader stuff at all (but works in them).

PBO = Pixel Buffer Object -- just stores arbitrary pixel data, like a bitmap. Old extension, similar to FBOs, but not quite as transparent (extra copy steps are required to make them into textures, etc).

FBO = Frame Buffer Object -- just like the normal screen (with depth buffer, accum buffer, etc), but can be recycled as a texture and used on-screen, without a context switch. Very handy for rendering into a texture. Newer extension.

toneburst's picture
hmm...

cwright wrote:
Why are steps 2 and 3 separated? (couldn't you calculate the depth map in step 2, and also apply the step 3 fragment shader to the results, all in the same shader?)

I'm not sure. I think you have to render them to a discrete texture in order to do fancy texture-lookup stuff in the next pass.

I'm thinking of this kind of thing: http://http.developer.nvidia.com/GPUGems/gpugems_ch16.html

a|x

cwright's picture
different eye points

Ahh, you're going to need to render twice, from different view points (once from the light's POV, then from the eye's POV) -- definitely multi-pass :)

In QC, that's going to be really difficult... (multi-rendering for multipass isn't really elegantly possible, so everything needs to be an entirely unique custom patch, which isn't particularly versatile..)

toneburst's picture
But you could implement the

But you could implement the entire kit and caboodle in a plugin, I guess, and simply output the final lit, shaded etc. object....

Actually, I think in that tutorial, the depth-map only has to be rendered once (from the POV of the light), unless I misread.

It's still multipass, though.

a|x

cwright's picture
orient

once, until the object's position/orientation changes relative to the light source. Then you need to recalculate the depth map.

If it's static, you could just use the fog patch inside a render in image to fake the depth map, and use that as an input to the glsl shader that uses it to calculate depth stuff in eye-space.

toneburst's picture
True, but...

You need to use the same geometry for the next pass, so that would mean duplicating all the objects (and their positions etc.) inside the Render In Image and the GLSL patch doing the final render. Which isn't very elegant...

Oh, and you'd need to calculate the depth-map every frame, I'd have though, unless it's a completely static scene.

a|x

cwright's picture
elegance

There really isn't any other way to do multi-pass in QC though -- there isn't a simple, correct way to render arbitrary geometry that other red patches would draw. (the "really difficult part a couple comment up by me was hinting at this without going into detail). I guess if you weren't using any external renderers, or didn't want to them to be applied in the scene, it'd be ok, but that's fairly limited (ok, so not really, since kineme3d or gltools can now handle arbitrary geometry with varying levels of performance).

it really something qc wasn't designed to handle -- I'm not sure how the design could change to make this simple though... it's a pretty tricky problem, even without QC's graph limitations in the way.