Irrlicht Post Processing Effects Chain

[marco.siino]

I'm developing some new classes in Irrlicht sources that allow to implement multiple Post Processing effects with shaders supported by irrlicht (HLSL, assembly, etc..). The project is almost completed, at least for the "core" functions.

At the moment the following things has been implemented:

New classes added to Irrlicht source are IPostProcessing, CPostProcessing (the implementation of IPostProcessing abstract class). A new method as been added to IVideoDriver (createPostProcessingChain) that allow return an IPostProcessing pointer to the PostProcessing object created by the driver.

In the createPostProcessingChain you have to pass the shader filename, and pixel/vertex shader type (E_PIXEL_SHADER_TYPE and E_VERTEX_SHADER_TYPE). The created IPostProcessing implements the filter (or effect) in the shader file. Then you can add more effect by calling IPostProcessing::AddEffect, and passing the same kind of parameters plus the dimension of the result render target size, and an integer that specify the input effect to which the shader will work (0 rappresents the base scene, 1 the output of the first effect, and so on)

Each effect is a "pass" stage, this means that each effect, also explained before, takes in input the output of another effect (added before) or the base scene. The last effect renders directly to the frame buffer (and in this case the specified size of output render target is ignored).

The size of ouput render target is useful, for example, if u want to implement effects like Bloom filters.

With this things i think the most post processing things can be done. But if i can i consider to add more features to it.

In the next days i will upload these classes to be added to your Irrlicht sources, so you can tell me what can be adjusted or what can i add, or even some one can add more features to make this classes like, or bettere, the Ogre Compositor service.

If someone explain me if there is a better way to publicate the class sources on something like a CVS i will do it, istead of using code snippets.

Thanks!

[hybrid]

I think the post processing should go into the scene tree instead of the driver (of course it needs some backing in the driver, i.e. the driver specific implementation). That way you could add post-processing to parts of the scene without passing the information down to lower levels. So my first guess of a better public interface would be the SceneManager.
I guess that one could also implement PostProcessing classes which are not based on shaders!? Otherwise the interface should be slightly abstracted. So having a CShaderPostProcessing and CImageManipulationPostProcessing seems to be a good thing (esp. with respect to software driver implementations etc.).
A better way than providing full source files is to supply patches against either the latest SDK, or even better the latest SVN revision (which makes integration into the core simpler, but might introduce more work for you due to unstable intermediate code). For patches against the SDK please use the command 'diff -Naurp ...'

[marco.siino]

You mean to simple add something like the createPostProcessingChain method to ISceneManager istead of IVideoDriver?

I forget to say that postprocessing effects apply to the rendering in this manner (pseudocode):

videodriver->begin..
postprocessing->Prepare();
scenemanager->drawAll();
postprocessing->Apply();
videodriver->end...

[white tiger]

ciao marco (sei italiano vero?) [hi marco. are you italian, aren't you?]

can you post a screenshot, please?

Thanks

[marco.siino]

Ciao white tiger, si sono italiano

Posterò degli screenshot al più presto, sto cercando di far funzionare per bene il filtro bloom che sto implementando con questo sistema per il post processing che ho fatto

(i will post some screenshots soon, im fixing some problems with the bloom effect i'm implementing)

Ciao

[hybrid]

I thought of

Code: Select all

smgr->getPostProcessing()->push_back(postProcessor);
...
driver->beginScene
smgr->drawAll
driver->endScene

Each postProcessor object would implement a method which is called at the end of drawAll in the order of the manager's queue. Each process() method would take an addresse (ITexture seems to be too expensive, I'm not sure about this) to write to and return a (possibly new addresse) where the next effect will work on (similar to I/O streams). Different render targets should thus work as expected. Parameters of the stages can also be handled inside the postProcessor objects.

However, this is only an early sketch, I never implemented anything in this direction. I think omaremad had a similar postProcessing design as you proposed, but he used a top-level scene node instead of integrating it into the drivers (wihch is not a clean solution IMHO).

[sio2]

Watch out for the two extra blurs:
1. a 640x480 rendertarget, for example, will currently be reduced to 512x256 in the DX9 driver, so there's not a one-to-one correlation between the rendertarget render and the framebuffer.
2. Multiple drawAll() in a single scene will advance time-sensitive scenenodes so, once again, there's not a one-to-one correlation between the rendertarget render and the framebuffer. [Pausing the timer is one solution, but animated scene nodes will still be reskinned on the cpu, for example.]

[marco.siino]

what u mean sio2 ? i don't understand what u are talking about

[sio2]

1. What do you think will happen when you remap, say, 512x256 back to a 640x480 framebuffer?
2. Obvious enough.

Also, I assume that any HDR will be "fake" - unless you're adding float rendertarget support. I currently have an issue with saturated luminance calculations due to lack of fp16 (or fp32)...

[marco.siino]

i didn't said i'm implementing HDR, i only said im doing a bloom filter, not a really HDR effect. As bloom filter i mean something like lens flare on high-luminance source, creating by filtering the high-luminance part of the scene, downfiltering the result image, and applying a gaussian blur (i don't know if this is the correct name) remapping it to the rendering target and mixing with the scene color.. not a real HDR. I know that for HDR i need floating point render targets with the good precision, but it is not this i'm doing now

I don't know what happen if i remap a 512x256 back to 640x480 framebuffer...what happen ? and why are u saying 512x256 (is it just an example of smaller rendertarget?)

thanks