Created on 28.05.2006 - 13:52

I propose a way to allow multi-pass shaders to run on Pete's OpenGL 2.0 plugin.

Scenario:
I have 4 shader files.
2 of them are vertex shader pass-throughs.

They are named:
shader(N).vs, shader(N).fs
shader(N+1).vs, shader(N+1).fs

N is a number.

The idea is that an option in the configuration menu allows you to set the number of pairs of shaders.
1 vs and 1 ps equate to a single pair.

In the scenario above I have 2 pairs.

In the rendering stage it would go something like this:

for Integer to NumberOfPairs{
enableShader()
drawToTarget()
disableShader()
}
displayTarget()

You only need a single render target.

The point of this is so people with earlier PS 2.0 cards can do some more effects.
I would like to demonstrate some of my techniques on Lunar 2 however they are multi-pass techniques and cannot run in a single pass which means I cannot bring them into Lunar 2.

Effectively I only use a single render target throughout.

Created on 06.06.2006 - 10:50

Do you need the output from a previous pass as an input for your next pass?

Anyway, a short overview how the OGL2 rendering is working right now:

a) the PSX game is drawing all kind of stuff to a 1024x512 offscreen buffer (p-buffer or FBO). The offscreen buffer may also be a multiple of the 1024x512 (1024x512 would be a 1:1 ratio, by selecting higher "internal resolution" it also may be a 2048x1024 or 4096x2048 buffer, for example)

b) an emulated "PSX vsync" is happening. That means for the plugin: show a certain part of the 1024x512 buffer at the screen. Which part is also controlled by the PSX game, for example the area "120,16x440,256".

c) the plugin activates the rendering buffer as a texture (either it copies the complete pbuffer content to a real texture of the same size, or it uses the pbuffer directly as a texture, or it uses the FBO as texture... all depends on the user-defined buffer mode).

d) the plugin activates the vertex/fragment shaders

e) the plugin draws the currently active visible area (in our example the small 320x240 area) to the whole gfx cards backbuffer

f) the plugin deactivates the shaders/framebuffer texture and activates the 1024x512 framebuffer as rendering target again.

now everything starts with (a) again...

This works well with one pass... with multi-pass the plugin could only loop in (d) and (e), since it cannot force the PSX game to render the same scene again (that's what a PC game would be doing in multi pass).

And that would mean one or more additional textures for storing the rendering results (we cannot sample the pixels of the last pass from the backbuffer on current gfx cards, so we need to render in all but the last pass to a texture instead, which can be used as input for the next pass).

And that leads to more decisions I have to make... somewhen, when I have lotsa free time at hand

Created on 10.06.2006 - 12:58

Thanks for both replies Pete.
To answer your question, yes I do require output from a previous pass to render the current pass which is what a lookup table is for, however I'm unsure whether I can write to my custom texture or just have initial values on which I can only lookup. That might be good to generate filtering kernels and store them in a texture and use the values when doing a convolution but it isn't much when you want to ping-pong data within your shader.

Judging by the rendering procedure I would agree that it is a pain in the ass.

My R300 only has 4 render targets maximum, I guess you could use much less but you'd have to combine them.
I would imagine performance would suffer a fair bit at higher res.

Thankfully I play all my PSX games at 640x480.