A simple, robust and extendible postprocessing class
hmm, having some trouble with water - I'm trying to get the world coordinates of each point from just the x,y screen coord and z-depth. I think it should be possible but it isn't quite working
I've updated the download to include my attempts so far (as well as a couple of improvements to the rest that I've forgotten). If you use the EXAMPLE_SANDBOX you can see that the height of the water varies with the camera (I did take the camera position into account, not sure what's causing the bug). No waves, sun or surf yet, but has water depth colouring and faded edges.
edit: forgot to mention; this is very limited in size, because I can only fake an 8-bit zbuffer. If I could get a 16 or 32-bit buffer this wouldn't be limited in size.
I'm done with this for now, going back to my other project (which was the reason I started this). anybody else is welcome to make improvements.
I've updated the download to include my attempts so far (as well as a couple of improvements to the rest that I've forgotten). If you use the EXAMPLE_SANDBOX you can see that the height of the water varies with the camera (I did take the camera position into account, not sure what's causing the bug). No waves, sun or surf yet, but has water depth colouring and faded edges.
edit: forgot to mention; this is very limited in size, because I can only fake an 8-bit zbuffer. If I could get a 16 or 32-bit buffer this wouldn't be limited in size.
I'm done with this for now, going back to my other project (which was the reason I started this). anybody else is welcome to make improvements.
I've never used irrPhysX. possibly it has a special way of drawing the scene.
If you need to have anything other than this;
between beginScene and endScene, you'll need to replace the smgr->drawAll( ); line in CRendererPostProc.cpp (everything except beginScene, endScene and guienv->drawAll will need to go there)
if that doesn't work, irrPhysX probably needs to do some special stuff with post processing itself, which I'll have to look into.
If you need to have anything other than this;
Code: Select all
driver->beginScene( );
smgr->drawAll( );
guienv->drawAll( );
driver->endScene( );
if that doesn't work, irrPhysX probably needs to do some special stuff with post processing itself, which I'll have to look into.
You render irrPhysx the same way you render a scene without it. I replaced the smgr->drawAll(); with line in CRenderPostProc.cpp. Strange, it is not doing it today. The only thing that i noticed today is, if you are using motion blur and lens flare and have the lens flare near the cloth and look at the cloth, it disappears. Not really sure if that's a bug though.
multum in parvo
Well I really have no idea then! I might be using irrPhysx in my own project soon, in which case I'll be able to look into this further, but for now I can't see anything in either set of code that would cause the error.
Since you say it's intermittent, my mind goes to the simulate and fetchResults calls; maybe fetchResults isn't waiting for the results to be available, and it's only by chance if they are? unlikely but it's all I can find. and I can't see anything that would change from using my code with it, other than the amount of hardware memory and processing time used.
Since you say it's intermittent, my mind goes to the simulate and fetchResults calls; maybe fetchResults isn't waiting for the results to be available, and it's only by chance if they are? unlikely but it's all I can find. and I can't see anything that would change from using my code with it, other than the amount of hardware memory and processing time used.
well the old monitor effect isn't really supported. it's just me messing about. Might be able to fix it if you can tell me if it's showing the whole scene compacted, only the top-right quadrant (cropped), or the bottom left quadrant panned to the top right. What you describe implies I made a mistake with some texture size/copy function somewhere, which is worth tracking down.
in other news,
*another update*
Despite saying I was done with this for now, I fixed the water effect (still a very basic implementation, and not yet flexible), and changed the z-buffer to use a non-linear scale, which makes it able to cover the full scene. It's not perfect - I'd like to update to a 16-bit z-buffer to get rid of the jagged edges but for now that would require a third render, which I don't like. The jagged edges aren't too bad considering, but they're not really suitable for final releases.
The new z buffer means the other depth-related effects are better too (not confined to first 200 units any more), but you will need to change the parameters you use with them - they now work in scene coordinates. Multiply any depths you set by 20 to get the old results. The default values have been changed to match this.
in other news,
*another update*
Despite saying I was done with this for now, I fixed the water effect (still a very basic implementation, and not yet flexible), and changed the z-buffer to use a non-linear scale, which makes it able to cover the full scene. It's not perfect - I'd like to update to a 16-bit z-buffer to get rid of the jagged edges but for now that would require a third render, which I don't like. The jagged edges aren't too bad considering, but they're not really suitable for final releases.
The new z buffer means the other depth-related effects are better too (not confined to first 200 units any more), but you will need to change the parameters you use with them - they now work in scene coordinates. Multiply any depths you set by 20 to get the old results. The default values have been changed to match this.