I think this is almost the same as billboarding but a bit different.

Each Visible object would have a texture where it fits (if the object takes 1 pixel on screen the texture is 1 pixel too). The texture contains both the color and depth values.

Each object is rendered to their texture at some point, every X frame, every frame, whatever, both the color and depth.


After you have all these textures, you can render the textures to the screen with depth testing the depth values of the texture, without actually rendering the objects themselves to their respective textures unless they change rotation or distance significantly. The textures would also be positioned right, rotated and possibly even up/downsampled to have the quality stay good even if the object does rotate or move in a bad direction a bit.


Obviously this takes a lot of memory for objects covering the whole screen, so it should only be used if you actually save a lot of performance by using it, lets say a single relatively big complex object or multiple complex smaller ones which dont need to be rendered every frame (That is, if they dont rotate or move much in the z direction)


Actually i was originally thinking this for some sort of software real time raycaster/tracer, since with those this would be great to hide the effects of slow [s]FPS[/s] rendering of the objects on fast moving objects. Now that i think of it, it wouldnt probably be worht the hassle for rasterized graphics (well maybe for some things, like huge spaceships in the distance with tons of lights and such)

Comments?

This is usually called "impostor rendering".
theory: http://www.gamasutra.com/view/feature/2501/dynamic_2d_imposters_a_simple_.php?print=1

here some vid of how it looks:



I think the best known game that massively uses it is Crysis (for trees).

I'm not a huge graphics buff, but I doubt the complexity would be worth it, and I think that you'd end up needing the re-render the textures more often than you think in order to look good. Better solutions would be LOD (rendering models with lower geometric and material complexity at distance) with billboard impostors at great distance. Combine that with occlusion queries and you're probably already fairly optimal without setting up tons and tons of renders -- remember, each object (as you describe it) would essentially be its own render pass, with associated state changes likely, with all the associated overhead. Opting into that kind of overhead for a few pixels over a few frames is very likely a fool's errand.

I assume that Crysis and the video above use impostors in a way similar to what I've described, rather than as you describe the concept.

1. You usually bake several impostor into one big texture, that way you can render a lot of them in just one drawcall
2. you create the impostor in a higher resolution than you use them, that way you have an anti aliasing effect
3. as you use the same texture for a lot of frames (can be several hundred frames), you additionally reduce aliasing (the aliasing you usually get due to motion)
4. creating an impostor is slightly more expensive than rendering the actual directly to the target, so if you reuse it for 2 to 3 frames, you can be pretty sure you get away faster than rendering individual low LODs
5. impostors are usually used for distances objects, but there is a way to scale it nearer with volume impostors: http://www.ericrisser.com/stuff/Rendering3DVolumesUsingPerPixelDisplacementMapping.pdf

in worst case, you can also precalculate a lot of views for your impostors, it was used e.g. in FarCry (and I've used it for a PSP game some years ago and also for a space game to render distant asteroids/planets/stars), it's the simple vanilla version everyone can get working in few days

But I agree, impostors won't give you a big pixel saving, they actually cost pixel processing power, as you render way more area than a low LOD would cover. Isn't a win if you are fillrate limited.

Consider storing the normals ... and then you don't need to re-render due to light movement (bit like holograms)
Per-pixel depth is rarely needed for imposters - for example how many trees do you see intersecting other objects?

The imposter renderer ends up similar to a particle system

Furthermore you can store matching shadow imposters - and render the stored depth + position depth into shadow maps

I use raytraced imposters in my billiards game with no depth information:

Yeah storing depths doesnt make sense in most cases if you are rendering polygon models and use imposters only for far away objects... I was thinking of using this for something like software rendered scenes that use raycasting/tracing and thus are slow. If there wouldnt be many objects you would probably want to use imposters for everything that might move with decent speed on the screen, so thats why i mentioned depth too...

Any videos of it being used for very near objects too?