Jump to content
Sign in to follow this  
  • entries
    162
  • comments
    262
  • views
    167561

Post Processing Overload

Sign in to follow this  
OrangyTang

107 views

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:
		shadowTarget.preRender();
{
GL11.glPushAttrib(GL11.GL_ALL_ATTRIB_BITS);
{
shadowSprites.render();
}
GL11.glPopAttrib();
}
shadowTarget.postRender();

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  


2 Comments


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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!