Jump to content
  • 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

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!