#129823 - LoTekK - Sun May 27, 2007 5:34 pm
I've heard of rtt bandied about in discussions pertaining to doubling the 2000 poly hardware limit, but I'm actually wondering how viable it would be to be able to rtt a 100-tri animated model into a sprite that stands roughly 24wide x 48high (so a 32x64 texture). More importantly, is something like that doable?
Would the operation be fast enough to use in place of animated models, assuming I've got potentially 10 of these 100tri models onscreen? Would it be viable to use something like this as a lodding system, so to speak?
(again, I'm an artist, not a programmer, I'm just trying to figure out some options while building my art assets)
#129828 - tepples - Sun May 27, 2007 8:08 pm
| LoTekK wrote: |
| I've heard of rtt bandied about in discussions pertaining to doubling the 2000 poly hardware limit, but I'm actually wondering how viable it would be to be able to rtt a 100-tri animated model into a sprite that stands roughly 24wide x 48high (so a 32x64 texture). More importantly, is something like that doable? |
Yes, but you need to give up a lot of VRAM that you would otherwise use for textures because you have to use two VRAM banks as frame buffers: one to hold the render target and one to hold the previous frame (so that it can be displayed instead of the render target).
Also remember that the triangle limit counts only triangles facing the camera, not triangles facing away. And using quads where you can saves even more geometry RAM, as a quad takes about 2/3 of the space of the equivalent triangles.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#129832 - Cydrak - Sun May 27, 2007 8:33 pm
If you're doing this over 2D, it would be easier to render the models normally, on the 3D layer (and the rest on BGs). It's not opaque unless you want it to be; you can have BG/OBJ layers in front of and behind it. The 3D BG0 even has per pixel alpha (!) so transparency works.
As for RTT... 3D is completely tied to the screen refresh. You could render 10 or 20 as a "sprite sheet", but it'll always take one frame, 1/60 sec, no matter what size.
This raises obvious questions if your scenes are 3D. ;) I think you'd have to halve your framerate, capture the scene as you're displaying it, then display the capture next frame. But I'm still trying to "get" how this works, myself...
Finally, as tepples said, you can't share sprite/texture and render banks... not even if you split them in half. So you would need two or three. As these are 128K apiece, well--it's up to you.
#129834 - LoTekK - Sun May 27, 2007 9:03 pm
Ahh, thanks for the explanation, that certainly puts things into perspective. For the moment, after putting together a test environment, it looks like as long as my future programmer can get per-poly occlusion culling into the engine, I should be pretty safe as far as polycount, so I thankfully/hopefully won't need to even think about rtt for the sprites.
edit:
Oops, left the post page open a bit long, didn't see your response, Cydrak. When I was musing about the RTT, it was mainly because while doing the math in my head before putting an environment together, my polycount was looking a bit dire, in relation to the hardware limits. Thankfully, as stated, I had overestimated the probable polycount for the enviros, so I'm currently in good shape. Thanks again to both of you for the explanations. :)