Page 4 of 9

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 12:44 pm
by smso
aaammmsterdddam wrote:nice, but what about stability and/or bugs. is it fully tested (Even all obscure shader combinations)?

I will download it, because it is awesome.
Good snippets though some glsl shader codes do not compile. I've learnt much in converting the hlsl to glsl shaders. I admit that I have to refactor the snippets to see how they work.

Regards from smso

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 12:47 pm
by mongoose7
I had no trouble. The actual combination of shaders normally wouldn't have an effect on stability because the processing is always the same, just repeated.

But, there may be an unusual situation. For bloom, I think there is a shader sequence that renders to successively smaller targets. Though maybe you can't change this sequence using configuration.

All the shaders compile for me so maybe it is a driver issue. Or are the shaders written for Nvidia?

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 1:23 pm
by smso
mongoose7 wrote:I had no trouble. The actual combination of shaders normally wouldn't have an effect on stability because the processing is always the same, just repeated.

But, there may be an unusual situation. For bloom, I think there is a shader sequence that renders to successively smaller targets. Though maybe you can't change this sequence using configuration.

All the shaders compile for me so maybe it is a driver issue. Or are the shaders written for Nvidia?
I am using Mesa DRI driver (fc15) for the crappy Intel GMA 3100 vga chip. Maybe it's a driver matter.

Regards smso

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 2:14 pm
by ACE247
Its Drivers, but also Nvidia chipsets are far more tollerant of slight errors in glsl code than ATi/AMD cards are.

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 2:34 pm
by tbw
I had a deeper look into the shader codes and currently I'm reworking the shader files (I compiled them with the AMD shader analyzer, thanks again to christianclavet for his work).
As you can read in the comments in the shader files some of them origin from nvida shader library and it's a fact that some of them don't work on ATI/AMD.

I fixed the fxaa algorithm for opengl and I will upload the new code in the next hours...
BTW there is one big mistake I m made: The opengl driver ignores the entry point definition for the shaders -> It always uses main! So the opengl branch works different to the directx branch (downsampling for example doesn't use downscal2x2 but main). I didn't realised that in my previous posts.

It will be fixed in the new release

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 2:56 pm
by mongoose7
I wondered about the unused code. I'm looking forward to the next release.

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 4:14 pm
by 3DModelerMan
Is it possible to use floating point render targets with this, to do tone mapping?

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 4:40 pm
by ACE247
32bit Render Targets? Hmm, I'm not sure but lets wait for tbw to tell us, If so that could be a real cool feature!

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 7:20 pm
by tbw
I' ve uploaded the new release
http://www.van-helsing-band.de/irrlicht/postprocess.zip

Floating point render targets should work (I used ECF_A16B16G16R16F = 6 for the depth map to get more acurate depth information)

Code: Select all

<RenderTarget id="rttDepth" colorFormat="6" scale="1.0" />
please refer to rtt.xml for furhter details
The next step is to create a hdr pp-effect similar to the ldr adaptive bloom (I'll post it here when its done)
There is a new pp-effect EPPE_UNDER_WATER. I use this in combination with a reflective/refractive/specular water scene node.
I think the fxaa is a good alternative to rendering twice the screensize and downsamling again.
I'm very happy that this works now also for opengl :D

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 7:34 pm
by Granyte
the newer version outputs only black when i turn the effects on in dx9 while they work fine on openGL

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 7:51 pm
by tbw
maybe you hitted 'p' before you switched to mode one. (by pressing 'm').
The final pass is now located at position number two, so hitting p before m leads to a black screen. Of course it should be possible to switch through the other effects.
Mode two should run in either case.
I don't have an idea what else could happened :?: ....

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 8:19 pm
by ACE247
(A16B16G16R16F) thats 64bit! Nice so HDR and tone mapping is go! :)

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 8:27 pm
by Granyte
no all combinaison of p and m lead to black screen in dx9

and mode 2 also lead to black screen

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 9:29 pm
by tbw
Hey Granyte,
Currently I haven't got an idea. I tested it on two machines (both nvidia) and had no problems.
On Monday I will do some tests on other gpu's. I hope I can find a solution....

Re: xml based postprocessing framework

Posted: Fri Jan 13, 2012 10:27 pm
by Granyte
i'm using an ati cfx setup there might be an issue there ill look if disabeling CFX fixes the issue
EDIT

no avail dx mode is still not working on my machine even in single gpu mode

did any one with ati GPU test?