PostProcessing addon to irrlicht, your opinion/suggestion?

[Luben]

Hi. I'm making a post-process addition to my irrlicht-project. Eventually, i might try to get it accepted into irrlicht, if it's nice enough.
I'm asking for different opinions and suggestions in this thread, as i want the system to be as good as possible.

To begin with, i will describe how i want it to work, somewhat, with an example of how to use it.

Code: Select all

	IPostProcess* pp=device->createPostProcessor();

	//Set the size of the render targets
	//This is not needed, since they are set when we create it.
	pp->setSettings(ScreenSize, ...)

	// Loads and registers all effects and chains from this folder
	pp->loadFromFolder("./Data/PostProcess/");

	// Add an empty PostEffectChain, with the name "Effect #1"
	IPostEffectChain* MyChain=pp->addPostEffectChain("Chain #1");

	//Add an empty PostEffect, with the name "Effect #1 with longer name than needed"
	MyEffect=pp->addPostEffect("Effect #1 with longer name than needed");
	//Downfilter x4
	MyEffect->setScale(0.25f);
	//Load whole effect description file
	MyEffect->loadEffect("./Data/MyEffect/MyEffect.ppe");
	MyChain->addEffect(MyEffect);

	// Add a built-in or preloaded effect
	u32 VBlurIndex=MyChain->addEffect(pp->GetPostEffect("Bright_Pass_x4"));
	//The chains store their own effect parameter copies
	f32 Lum=0.05f;
	MyChain->GetEffectAttributes(VBlurIndex)->setAttribute("Luminance", &Lum, 1);

	//Add a whole effect chain
	//Actually 'copies' the source chain
	MyChain->addEffect(pp->getEffectChain("Bloom"));

	//Set this as the active chain. We could pass a pointer, but we use the name because we can.
	pp->setActiveEffectChain("Chain #1");


//Main loop
	beginScene(...);
	//scene->drawAll();
	pp->drawAll(scene);
	gui->drawAll();
	endScene();

The IPostEffect and IPostEffectChain classes are used for loading passes and defining the passes and parameters to use.

The IPostProcess keeps track of effects and chains. The chain is called when rendering, and it calls the IPostEffects that are registered with it, and passes the current paramerets(When effect parameters doesn't come from the chain, the effect-default parameters are used). Then the effect does the actuall rendering.

What i'm currently stuck at is how loading of effects should be done. Since i want to make the structure of the system shader independant, effects must have a non-shader dependant interface, but then a problem with the current design arises; the effect is loaded with IPostEffect->loadEffect(...), which could cause problems, since the IPostEffect may be unable to load that certain type of effect.


Should some sort of factory be made then, like the scenemanager does?

Thanks for suggestions and requests which may improve this.

Luben

[hybrid]

A good idea to start this one. However, I cannot help you with the effect loading since I do not have an idea, yet.
But I'd suggest to change the names in your example (as "1" assumes an order on names which is probably not intended). Moreover, I'd expose a list or array interface (i.e. ude push_back and the [] operator).
And I still prefer a scene manager interface (or render target interface) for post processors. Of course this comes down to the driver at some point, but the point of time for post processing is determined by the scene manager resp. the render target.

[Luben]

Ok, the names are changed, hope it's more clear that they are names now.

Ok, expose list or array, but, ehr, which arrays? Those for the effects or chains or both?

How do you mean, render target interface?

At this point, where the interface ends up is not important, i think the interface can work from almost any place with small modifications.

However, for the moment the system requires 2 dll/source modifications. One is for the scene manager, so that when in PostProcess-mode, things are not animated and shadows are not drawn. Second, i've added a new function to the video drivers, forceMaterial. It sets the material passed, and sets a driver member variable. Subsequent calls to setMaterial then return immediately, until forceMaterial is called with NULL as parameter.

This is for making normal and position maps/textures. The post-processor forces a normal/position-shader material and renders into textures, if those textures are needed. The color texture is rendered with a normal call to drawAll(), which also draws shadows and animates nodes.

[Luben]

*bump*

Come on people, if you got a post processing system, what would you like to see in it?

[TheRLG]

Screenies of it in action?

[pyrokar]

well, in my opinion it should be:
- shader based (IMaterialRenderer based)
- having an interface as easy to use as possible ("make simple things easy")
-> easier than the current one
- using opengl/d3d9 optimizations if possible
- using a scene manager interface / render target interface as hybird suggested
- using irrlicht's coding rules very strictly.

just my opinion

[Luben]

I dont have any screenies of it yet. I got stuck when i couldn't decide how to deserialize the effects.

The normal, default effect will be shader based.

I can't see what optimizations i can get from making a whole new material renderer instead of using the driver independant solution that irrlicht provides.

With easier than the current one, what do you mean? The example code i posted? If that's not an easy to use interface, then i dont know what is.

What do you mean with scene manager/render target interface? I dont feel like locking the post processor to one scenemanager. But i could add something to the scenemanager like setPostProcessor(...) if that's OK.

I am trying to use irrlicht's coding rules, if you can prove me wrong then do and i'll correct whatever i did wrong. If it's a suggestion then ok, i'm working on it

[Virion]

Keep it up! Waiting for the demo...

[Luben]

Working on it, got some simple effects working yesterday. I've made a shader effect descriptor format, which gives you some of the things that DX's effects can use, such as pixel-to-texel conversion. In a few days i expect to have something nice to show.

A question to the irrlicht developers - What about floating point render targets/textures? Can we expect this in the next release, or should i try to add this at the same time?

[hybrid]

Adding new texture formats requires lots of work so I'm not sure when I get to it. Remember that you have to add lots of conversion routines etc.
The scene manager interface I mentioned is indded as you expected a way to bind a set of effects to a scene manager (resp. a render texture). That's just the point where I'd expect to add such things and where the handling happens. Also it's important to allow post-processing on arbitrary render textures, not only the final image.

[Luben]

Ok, i think i get what you mean.
Sortof like binding a special chain to a scene manager, not just one active chain, and making the scene manager call the post processing by itself when we drawAll()?


And yes, you can output to textures other than the screen too. This is what the current PostProcess->drawAll looks like

Code: Select all

	//! returns void on sucess and failure.
	virtual void drawAll(scene::ISceneManager *Mgr)
	{
		if(preProcess(Mgr))
		{
			postProcess();
			drawFinal();
		}
		else
			Mgr->drawAll();
	};

preProcess returns true when we got an active chain of effects. It also renders the needed sources like color, normal and position.
Did you mean that one should be able to set the source textures by yourself, to replace what preProcess() does? I could make some function for that too.


postProcess just passes the outputted sources to the active chain, and returns a pointer to the final output texture, which is also stored internally and rendered in drawFinal(). So you could use this texture for something else.
...Do you mean that one should be able to pass ones own texture to render too? It might be trouble if you pass this texture as one of the sources..


This function is inlined, so you could call them by yourself to get the texture which is outputted to.


Hmm, new texture formats may have to wait a while anyway. Better fix this right before i try to make another addition =)

[pyrokar]

I can't see what optimizations i can get from making a whole new material renderer instead of using the driver independant solution that irrlicht provides.

The point is that it will be confidant to adding a shader to a scene node.
E.g you could apply the same Material Renderer to a scene node and to the post processor.

What do you mean with scene manager/render target interface?

Ok, hybird already explained it.

I am trying to use irrlicht's coding rules, if you can prove me wrong then do and i'll correct whatever i did wrong. If it's a suggestion then ok, i'm working on it

Well, i didn't say you are not using irrlicht's coding rules.
I only said that it is very important to use them We should make it look like if it's part of irrlicht -> so there is more chance to be included in irrlicht some day or if not you at least do not see that it is not part of irrlicht while using it.

With easier than the current one, what do you mean? The example code i posted? If that's not an easy to use interface, then i don't know what is.

Well, i didn't want to say that your example is not easy.
Only a suggestion.

[Luben]

I can't see what optimizations i can get from making a whole new material renderer instead of using the driver independant solution that irrlicht provides.

The point is that it will be confidant to adding a shader to a scene node.
E.g you could apply the same Material Renderer to a scene node and to the post processor.

I don't quite get your point.. maybe. Do you mean that i should make a shader-effect from which you can get the 'MaterialType' and use it with your meshes?

Thanks for the rest of your opinions and suggestions =)

[Luben]

I've managed to get an effect working, and i thought i'd post a screenshot. It's a gaussian blur effect.

Here is the scene with no effect applied


And this is the scene with the effect. Perfect for people like me who got no artistic skills =)


I'm going to implement some of the effects from the post processing example that comes with DX, then i'm going to implement chains and then fix the final interface and release it.

Should i create a new thread in the projects forum? This is a project, sortof.. i'll keep posting in this thread until someone tells me to change forum.

[Virion]

Should i create a new thread in the projects forum? This is a project, sortof.. i'll keep posting in this thread until someone tells me to change forum.

yeah you can post this to the project announcement forum.