A simple, robust and extendible postprocessing class

Announce new projects or updates of Irrlicht Engine related tools, games, and applications.
Also check the Wiki
anoki
Posts: 58
Joined: Fri May 05, 2006 8:31 am

Post by anoki »

Hello DavidJE13,

your class is very good. I like to extend it with some shaders.
I tried it with an NVidia 7300 and it runs very well.
Is the license of the code also zlib like irrlicht. Would be great.

Anoki
DavidJE13
Posts: 165
Joined: Tue Jan 09, 2007 7:17 pm

Post by DavidJE13 »

hi, I've had a look at the terms and it seems ok, so the code is released under the zlib license. The copyright is to David Evans, 2009
sprocket
Posts: 9
Joined: Thu Jan 07, 2010 1:07 pm

Post by sprocket »

I really like your class!
Espesially the lens flare effect.
But it is really slow. I get 30 fps when i look to the sun.
I dont know much about shaders but is it possible to do the pixel check for the sun in a pixel shader?
Like this one:
http://http.developer.nvidia.com/GPUGem ... _ch26.html

Great job again!
DavidJE13
Posts: 165
Joined: Tue Jan 09, 2007 7:17 pm

Post by DavidJE13 »

hmm, that looks very interesting. I'll give it a try when I get time, though this will probably be done in my new class (not released yet) because it has built-in downsampling & other niceties.

2 potential problems which come to mind;
* This cannot track more than 1 object, so having 2 bright spots will have odd behaviour (the flare being half-way between them). Could be fixed by giving a rough expected position & size, and using this for fine-tuning and obstruction checking.
* The method he uses for overlaying the duck is very inefficient - using a pixel sampler in the vertex shader and a standard pixel shader would be much more efficient.
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

Post by devsh »

haha... i have a better idea for you

multiply the sun (bright spot) billboard vertices by worldViewProj matrix (in irrlicht)

one you get them they are in -1 to 1 range
multiply by 0.5 and add 0.5
you get texcoords of where the sun is in the scene

(irrlicht has this function somwhere, I've seen it)
make a depth texture for the render target you drew your scene into

have a 128x128 (or 64x64 if the sun is small) render target.

have a screenquad with changing Tex Coords

turn on Anisotropic filtering

have a pixel shader that records the INVERSE (1.0-diff) LINEAR difference between sun depth and pixel depth

then another rtt which is half the size

render the content of the previous render target into that

and so on and so on untill you render into an rtt of size 2x2

in the sun flare vertex shader you can use that RTT (sample it right in the middle, the bilinear interpolation will avergae all 4 pixels) and its float value raised to some power and a cut off at 0.5 difference will provide a nice attenuating flare effect
sprocket
Posts: 9
Joined: Thu Jan 07, 2010 1:07 pm

Post by sprocket »

Glad to hear you are thinking of implementing this DavidJE13!
Could be fixed by giving a rough expected position & size, and using this for fine-tuning and obstruction checking.
That is exactly what i was thinking :D

Also, i have to admit that devsh's approach will probably have more accurate results. Calculating the
difference between sun depth and pixel depth
will not be color dependent and it will avoid the problem with white objects. I dont know about the performance differences.

*Off topic: Nice community ppl
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

Post by devsh »

my bad, if you calculated the difference it would be a fail, imagine a building at 0.99

you need to record 1.0 or 0.0 if the depth >= sun depth

then once you start scaling the RTT down the values will interpolate and you will get stuff like 0.5, 0.7, 0.3
sprocket
Posts: 9
Joined: Thu Jan 07, 2010 1:07 pm

Post by sprocket »

I did not think about the exact way it could work (the truth is i cant..)
I just thought that your idea of using the depth instead of the color might be more accurate.

Anyway, i think we made our point and it is up to DavidJE13 now, because he will write the actual thing. It is still great as is.

Another thing is depth of field. I wrote an example to make it "adaptive" using a ray from the camera and then get the collision point from the ray. After that i pass the distance between the intersection and the camera to your shader (i can post the code if someone wants, but i dont think it is a big deal).

Again i think it might be a more "gpu based" solution. What do you think?

Sorry DavidJE13 for throwing ideas and not write the code myself and post it, but as i said i dont know much about shaders (i just started learning some very basic stuff)
rootroot1
Posts: 44
Joined: Wed Nov 25, 2009 6:42 pm
Location: Odessa, Ukraine

Post by rootroot1 »

Hi to ALL !!!!!!!!!!!!

This project is great !!

Someone know, whats wrong with dimentions
when screen size is 800*600 everything fine, but if bigger - screen is black :cry: :cry:

What's wrong ??
DavidJE13
Posts: 165
Joined: Tue Jan 09, 2007 7:17 pm

Post by DavidJE13 »

hi rootroot1;
firstly, make sure you always use powers-of-two for the texture sizes (that is, the dimensions given to the nodes). The window size can be non-power-of-two.

second, how big is bigger? 801x600? if the cut-off is above 1024 then it could be a limitation of your video card. 4096 is the most common upper limit that I've seen but it could be that you have an old card. It's also possible that you're running out of VRAM, in which case using fewer stages in the pipeline should fix it (new version will use intelligent texture sharing to reduce this problem, as soon as I get it working!)

if these don't work, posting your graphics card details may help solve the problem.


also, @devsh;
that's an idea I attempted when I first wrote the effect, but at that time I couldn't access the depth buffer (I was using 1.5) so I used vector collision tests which made it VERY slow (this evolved into an option in the current version, but using only a single vector and bounding boxes - much less effective). I think you're right that it would be a better solution now, but one problem I can think of is that there is no support for semi-transparent objects, so in some cases the sun could loose it's flare for no apparent reason. (also I've never tried to get the depth buffer since it apparently became available but I imagine it's not too difficult)

final thought; having the flare effected by white objects isn't necessarily a bad thing, especially if combined with some HDR technique. I kind of wish I could do a GPU-based convolution so that every pixel on the screen could cast it's own lens flare, which would make a very flexible and realistic solution. But that's just wishful thinking :(
rootroot1
Posts: 44
Joined: Wed Nov 25, 2009 6:42 pm
Location: Odessa, Ukraine

Post by rootroot1 »

No, i have a good video card with DX10 and CUDA support
NVIDIA GeForce 9500 GT

.......

Screen resolution doesn't matter now, I solved it ..

A have a few more questions now :

1. DIRECT3D9 and antialiasing - result black screen (With OPENGL gui becomes dirty)
Have any suggestions how to solve it ???? :idea: :idea: :idea:

2. Maybe it was a good idea to port your Interface to CG/ using Nadro's wrapper ( this gives no problems between OpenGL and DirectX)

Thank's for your answers in advance !!!!!!! :arrow:
DavidJE13
Posts: 165
Joined: Tue Jan 09, 2007 7:17 pm

Post by DavidJE13 »

The library as-is doesn't support Direct3D9. I never bothered to figure out why - if you can see what needs fixing please tell me.
(It should just disable itself when used with it. If it doesn't that's a bug)

No idea what would make the gui "dirty", since this never touches it - can you elaborate?

I'd rather not port to CG, because that's limited to DirectX's features. OpenGL has some extra abilities that I've used for some of the shaders. Basically I'd like to keep the flexibility to have each shader as good as it can be in OpenGL and have a more basic version for DirectX. I may add the ability to use CG shaders as well (for custom shaders); I'll see how Nadro's wrapper looks.

Final note - for anti-aliasing, the new version uses no special shaders at all; just the standard material and an identity view matrix. So it should work on every driver. Only problem would be rendering to textures larger than the screen size on some hardware. Some kind of grid rendering (i.e. rendering each quadrant of the screen to its own texture then combining them once aliased) may help there, but that's a project for some other time.
rootroot1
Posts: 44
Joined: Wed Nov 25, 2009 6:42 pm
Location: Odessa, Ukraine

Post by rootroot1 »

with this parameters

Code: Select all

SIrrlichtCreationParameters p;
p.AntiAlias = 2;  //problem is here
p.DriverType = EDT_OPENGL;
p.Bits=32;
p.Fullscreen = true;
p.Vsync = true;
p.WindowSize = dimension2du( 1280, 1024 );
IrrlichtDevice* device = createDeviceEx( p );

.....

Image

and with this

Code: Select all

SIrrlichtCreationParameters p;
p.AntiAlias = 2; //problem is here
p.DriverType = EDT_DIRECT3D;
p.Bits=32;
p.Fullscreen = true;
p.Vsync = true;
p.WindowSize = dimension2du( 1280, 1024 );
IrrlichtDevice* device = createDeviceEx( p );

...

when fullscreen, the screen is black :!: :!:
Image


Do you have any ideas how to fix that ?????? :cry: :cry: :?:
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

RTTs and AA was only fixed in Irrlicht 1.7 IIRC, so I guess you'll have to switch to a newer version.
sp00n
Posts: 114
Joined: Wed Sep 13, 2006 9:39 am

Post by sp00n »

Hi, David!
just wishes: Would be great to see underwater caustic emulation effect made by postprocessing. I said "emulation" because for realistic caustic it needs to calculate many values and could be so hard for the post process. With the DoF and distant blur and some camera "swimming"(not in shader of course) it could look fantastic :)
Good luck
Post Reply