• Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Post Processing Overload

Sign in to follow this  


Recently I've had a tendancy to do all sorts of render-to-texture tricks and post-processing effects in an attempt to move further away from having everything composed of sprites and to give things a softer, more organic feel.

However I have a tendancy to start from scratch and do it all with raw GL calls each time, which has a tendancy to be time-consuming and error prone to write. I also usually cop out and just render to the framebuffer and copy it to a texture because pbuffers are such a pain to get working.

So it's time to give this whole area an overhaul. Using the various utility classes that currently give me a kind-of helpful but still tedious way of doing things I've extracted and grown a few nice classes to make it all much easier to work with. Heres how it looks now to set things up:

rttControl = new RenderToTextureController();

shadowTarget = rttControl.createTextureTarget(new RenderSize(512, 512), new OrthoCamera(w, h));
shadowTarget.setClearOperation( new ClearColour(0.4f, 0.4f, 0.4f) );

glowShapesTarget = rttControl.createTextureTarget(new RenderSize(400, 300), new OrthoCamera(w, h));
glowShapesTarget.setClearOperation( new ClearColour(0, 0, 0) );

glowBlurTarget = rttControl.createTextureTarget(new RenderSize(400, 300), new OrthoCamera(400, 300));
glowBlurTarget.setClearOperation( new ClearColour(0, 0, 0) );

finalTarget = rttControl.createFramebufferTarget(new RenderSize(w, h), new OrthoCamera(w, h));

Basically theres a master 'control' object which oversees the whole process, and makes sure that only one render target is active at any one time. It acts like a factory for creating contexts so that when I add FBO and non-POT support you won't have to care, it'll just give you back RenderTargets of the correct subclass for the current hardware. The RenderSize is the actual output/texture size, and if it's non-POT it'll currently pad out the texture but the interface still works exactly the same. You also setup a camera and clear colour, which will be automatically setup before you render to a target. If there was scrolling I'd hang on to a reference to a camera so I could slide it around, but I don't need that here. Not setting a clear colour means it doesn't get cleared, simple.

Usage looks dead simple:

Just a setup and a tear down and viewport, camera and clear colour get done for you, and if it's a texture target then it'll update the texture when you're finised too. Creating a 'framebuffer target' means theres no backing texture (ie. it's your actual render to screen target).

And the resulting eye candy:

This is a pretty simple effect - first the sun sprite is drawn full colour on a black background. Then the tails sprite is drawn fully black to mask out the area he's hiding. This goes into the first texture target. Then this mask texture is has a radial blur performed into a second texture target. Finally a framebuffer target has the sun and tails drawn normally, and the blurred texture drawn additively over the top to get the nice glow.

Awesome. [grin]
Sign in to follow this  


Recommended Comments

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement