Render To Texture Questions

Started by
11 comments, last by MJP 16 years, 4 months ago
Hello all :) I have 2 areas I'm looking to use render to texture with (2d game)... First off, some general questions: Is render to texture fast or slow? Is it limited to newer hardware, or would it work with, say, GeForce 2 level graphics cards? (hardware T&L but no shaders) I was thinking about using it for screen scaling purposes (multi-resolution, etc.). If I just render the whole 2d scene to a texture, and then display that on the screen (ortho view, will scale to any resolution) - is this a good idea? Also, can I render just a single object to texture, or does it have to be a scene? eg. if I just wanted to render a single triangle, or a few triangles, or maybe a sprite to a texture, can this be done easily? Thanks!
Advertisement
Yes, you can render anything you want to a texture, rendering to a texture is no different than normal rendering (except you can't use a texture that you're rendering to, D3D at least will complain if you do). It is slower because it requires the hardware to change the render target, but on modern hardware, unless you are setting dozens of targets per render frame, you shouldn't have an issue.
Quote:Original post by NightCabbage
Is render to texture fast or slow?
Fast. It's the basis of 'post process' effects which are becoming increasingly common in high-end graphics.

Quote:Original post by NightCabbage
Is it limited to newer hardware, or would it work with, say, GeForce 2 level graphics cards? (hardware T&L but no shaders)
Provided the device says it can, then you're good to go. Performance may vary though.

Quote:Original post by NightCabbage
I was thinking about using it for screen scaling purposes (multi-resolution, etc.).

If I just render the whole 2d scene to a texture, and then display that on the screen (ortho view, will scale to any resolution) - is this a good idea?
On face value, no - bad idea. Yes you can improve performance by reducing the raster area and thus limiting fillrate impact, but you're likely to destroy quality by the up-sampling process. Unless I misunderstand your intentions..?0

Quote:Original post by NightCabbage
Also, can I render just a single object to texture, or does it have to be a scene?
A scene is a conceptual thing - it could be 1 object or it could be 1 million objects.

Quote:Original post by NightCabbage
eg. if I just wanted to render a single triangle, or a few triangles, or maybe a sprite to a texture, can this be done easily?
The overhead is in setting up and using RT's, this is independent of how much you actually render. It would unlikely to be efficient unless you render a reasonable amount.


hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

This is sounding like good news - thanks guys :)

Quote:Original post by jollyjeffers
On face value, no - bad idea. Yes you can improve performance by reducing the raster area and thus limiting fillrate impact, but you're likely to destroy quality by the up-sampling process. Unless I misunderstand your intentions..?0


Nope, sounds like you got my intentions right!

But I'll be rendering sprites, so they shouldn't suffer from quality loss, because they'll be up-scaled to a higher resolution anyway.

Does that make more sense?

It just means that I won't have to deal with multiple resolutions in the game code; I can just render to a set screen size (of the render target) say, 1024x678, and then up-scale that RT texture to full-screen (adjusting for aspct, etc. of course)

Bad idea?

I've seen it implemented before - seemed to work ok.

Just wondering if there's any negative of this method?
(or a better way of doing it?)
I think for your purpose of scaling a set resolution to any arbitrary resolution, render targets should work just fine. It should keep things much simpler than if you scaled each sprite individually, and if you ever wanted to you could even implement some sort of fancy (bicubic?) upscaling routine via shaders.

You'll just need to look into the specifics of rendering a full-screen quad, which is necessary for your final pass where you'll magnify or minify your render target and draw it to the back-buffer. This MSDN article goes into more detail of directly mapping texels to screen pixels in Direct3D9.
For simple 2D sprite rendering it may not be so terrible, but I'd still expect some noticeable quality loss unless you implement some super-fancy upsampling algorithm. The stock LINEAR filter is only really capable of a 2x increase/decrease in size.

Have you considered using projection space? That way you can define all movement in resolution independent terms. You can then have a "hi res" and "low res" sprite on disk and switch between them according to the display mode.

hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

I'm still considering using an Ortho projection, because sprite doesn't do rotations, etc. very well :P

So right now my next question is this:

Why is upscaling of a screen full of sprites better than upscaling a RenderTarget with sprites rendered at 100% scale on it?

(wouldn't it have the exact same effect?)
Quote:Original post by NightCabbage
I'm still considering using an Ortho projection, because sprite doesn't do rotations, etc. very well :P
Well if you switch to a 'proper' 2D-in-3D approach then you get all the benefits of 3D rendering (shaders etc..) for free [grin]

Quote:Original post by NightCabbage
Why is upscaling of a screen full of sprites better than upscaling a RenderTarget with sprites rendered at 100% scale on it?

(wouldn't it have the exact same effect?)
Yes, it would. My comments about the linear filter is just that you only have an effective range for a given source image.

hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

I've used the render to texture approach before in 2D games; it works great and allowed me to do all sorts of other really cool effects for free although I had to do some finagling to get it to work on most graphics cards. What I ended up doing was using the FBO approach then if that didn't work to fall back to PBuffers then if that didn't work do it the old fashioned way with copying textures back and forth from system memory. I wrote an article on how I did it on my site at http://willperone.net/Code/coderendertotexture.php

- Will
Cool :)

Also, if I'm doing a render to texture, and need to work with the pixel data - how much of a performance hit will I get from getting the texture data each frame?

eg. if I have to perform collision detection on the render to texture's texture.

or modify it, etc.

Is this a horrible idea?

I'd be literally copying the texture data from the video card every frame, right?

Is there a better way to do collision detection for a render to texture texture?

This topic is closed to new replies.

Advertisement