Elysian Shadows

Can someone please explain what is ment by "Render to Texture" in graphics, and how I could benefit from using it?

Thanks,
GUE

Means rendering to something other than the default back buffer, like say...a texture for example :] (Some API's and extensions do make the distinction between a "renderable texture" and a "render target"...there IS a difference).

Their uses are far too many to even mention here. Most renderers now are completely deferred in that most all of the lighting and effects are all done in image space, where render to texture is a component and the forward geometry passes don't account for too much. The benefit here is that the calculations can be done in constant time instead of growing in complexity w/ geometry.

Render to texture is when you render the scene (or a portion of it) to a texture rather than the frame buffer. This is used most often with post processing special effects. Have a look at this radial blurring screenshot on a sega Dreamcast (On my iPad now, Ill post later!)

The ps2 actually uses it in a bunch of games to perform post processing effects that it's shitty GPU couldn't do in hardware. Bump mapping, hdr lighting, radial blurring, etc. Shadow of the Colossus has a field day with this stuff...

Is this also used for monitors and stuff?
Like in hl2? Or is this a 'render target'?

Milch wrote:Is this also used for monitors and stuff?
Like in hl2? Or is this a 'render target'?

Yes, that's why in Garry's Mod it's called the RT Camera

Also consider split screen multiplayer. You can have what player 1 sees rendered to a texture, then what player 2 sees rendered to another texture. Then both are slapped onto the back buffer to result in two different views of the same scene.

Bakkon wrote:Also consider split screen multiplayer. You can have what player 1 sees rendered to a texture, then what player 2 sees rendered to another texture. Then both are slapped onto the back buffer to result in two different views of the same scene.

This is normally done with viewports.

Exactly.

The more practical application here is to store data that isn't an "image". Anything like split screens, portals, and things of that nature don't require RTT. Bump mapping as well does not require RTT, as a matter of fact this would be a nasty waste of memory and bandwidth.

More commonly you'd store things such as motion vectors for motion blur. Luminosity sums for HDR. Things not easily represented by an integer format (although you CAN do this ;] ), such as oversaturated light values for HDR. Surface normals for lighting and a whole slew of other things. Swap chains for certain blurs such as gaussian blurs. Edge filters for faked antialiasing.

This is where the true power of RTT lies. You won't normally see it being used for things that could just as easily be done on the backbuffer (rendering to the backbuffer is very fast and is an already allocated resource). It's important that you see an image not so much as "a pretty picture", but as data. RT's serve as arrays of output data from shaders is about what this boils down to. You're leveraging the sheer power of the GPU to perform scalar ops on data and you're storing the data in an array (texture) to be read back at some other time (a shader, or on the CPU) for data that is NOT linear in nature (eg: NOT a color).

Thanks yall, this is a sweet technique that I want to use!

GyroVorbis wrote:The ps2 actually uses it in a bunch of games to perform post processing effects that it's shitty GPU couldn't do in hardware. Bump mapping, hdr lighting, radial blurring, etc. Shadow of the Colossus has a field day with this stuff...

So render to texture seems like an optimization in some cases, cool!

RyanPridgeon wrote:Yes, that's why in Garry's Mod it's called the RT Camera

This makes perfect sense now that I think about it

K-Bal wrote:

Bakkon wrote:Also consider split screen multiplayer. You can have what player 1 sees rendered to a texture, then what player 2 sees rendered to another texture. Then both are slapped onto the back buffer to result in two different views of the same scene.

This is normally done with viewports.

qpHalcy0n wrote:Exactly.

The more practical application here is to store data that isn't an "image". Anything like split screens, portals, and things of that nature don't require RTT. Bump mapping as well does not require RTT, as a matter of fact this would be a nasty waste of memory and bandwidth.

I too agree, I would definitely use viewports for something like this. Thanks for the input