strategy game infantry rendering?
Hi
just one question how would you render this.
I have got infantry groups of 10 units
and approximately 200 infantry groups per player ->2000 infantry units
*8 players = 16000 infantries
i think skeletal animations would be a little bit overkill
so the only option i see are key framed animations (one mesh per frame)
any idea how i could speed this up a little bit to reduce glvertexpointer calls
sort should be quite expensive as well when you zoom out maybe rendering sprites instead of meshes when you are far away?
You could do it like this:
really far away units are drawn as points.
closer units are drawn as sprites
even closer units are drawn as un-interpolated key framed units.
finally the nearest units are drawn with key frames + interpolation.
or
use skeleton based animation instead of key framed...
I aimed at 2000 units per player at first, but with all particle engines and sound and pathfinding... numbers ended considerably lower, around 200 per player.
But I'm thinking of doing it Battle for middleearth style; i.e a squad of ~five units is born instead of just one... and only the squadleader gets pathfinding done, and the others follow him... but all of them fight individually, sticking close to their leader etc...
this way one could easily get 1000-2000 units done, cuz... is there really a need for total unit control? :)
really far away units are drawn as points.
closer units are drawn as sprites
even closer units are drawn as un-interpolated key framed units.
finally the nearest units are drawn with key frames + interpolation.
or
use skeleton based animation instead of key framed...
I aimed at 2000 units per player at first, but with all particle engines and sound and pathfinding... numbers ended considerably lower, around 200 per player.
But I'm thinking of doing it Battle for middleearth style; i.e a squad of ~five units is born instead of just one... and only the squadleader gets pathfinding done, and the others follow him... but all of them fight individually, sticking close to their leader etc...
this way one could easily get 1000-2000 units done, cuz... is there really a need for total unit control? :)
Quote:Original post by Basiror
Hi
just one question how would you render this.
I have got infantry groups of 10 units
and approximately 200 infantry groups per player ->2000 infantry units
*8 players = 16000 infantries
i think skeletal animations would be a little bit overkill
With that many units some kind of level-of-detail control will probably be in order.
Though skeletal animation might necessarily cost you a few more calculations per mesh, it will use a *lot* less memory than storing one mesh per frame of animation. You'll have to weigh the pros and cons here.
@Rasmadrak: yes that what i call infantry groups
i think i should run a little benchmark on how many units i could sort at runtime without dropping fps underneat 60
@James Trotter:with skeletal animation my concern really lies in the amount of cpu operations you had to spend each x frames
of course you have to stick with simple skeletons and simple meshes
i think i should run a little benchmark on how many units i could sort at runtime without dropping fps underneat 60
@James Trotter:with skeletal animation my concern really lies in the amount of cpu operations you had to spend each x frames
of course you have to stick with simple skeletons and simple meshes
perhaps you might be able to implement something along these lines: http://www.ati.com/developer/shaderx/ShaderX3_DrawingACrowd.pdf
never tried implementing it myself, but it seems interesting and they use skeletal animation.
never tried implementing it myself, but it seems interesting and they use skeletal animation.
Aye, instancing may well be helpful.
You might be able to do something which comes out like a cross between keyframed and skeletal animation by uploading your skeletal keyframe data into vertex shader constants. You'd need to convert them into direct transforms on the CPU (so that you don't have to apply them hierarchically in the shader) but I think you only need to do that once. If you've got 5 bones per model, 5 anims with 6 keyframes per anim, that's 150 entries; that comes out at either 450 constants if you use 4x3 matrices, or 300 if you use quaternion+offset.
The vertex program would be complex, but you'd end up with basically all your animation being done on the GPU - you'd just have to submit basic data about the animation index and the current time/interpolation factor on a per-frame basis.
You might be able to do something which comes out like a cross between keyframed and skeletal animation by uploading your skeletal keyframe data into vertex shader constants. You'd need to convert them into direct transforms on the CPU (so that you don't have to apply them hierarchically in the shader) but I think you only need to do that once. If you've got 5 bones per model, 5 anims with 6 keyframes per anim, that's 150 entries; that comes out at either 450 constants if you use 4x3 matrices, or 300 if you use quaternion+offset.
The vertex program would be complex, but you'd end up with basically all your animation being done on the GPU - you'd just have to submit basic data about the animation index and the current time/interpolation factor on a per-frame basis.
@localhost: this paper from ATI is really a greate example thx
@superpig:how many vs constants can modern graphic cards store i have got a gf6800gt pcie
@superpig:how many vs constants can modern graphic cards store i have got a gf6800gt pcie
Quote:Original post by Basiror
@superpig:how many vs constants can modern graphic cards store i have got a gf6800gt pcie
Depends on the card. You're guaranteed at least 256. Yes, my suggestion is a tad unpractical [grin]
yeah, it would probably be more practical to do the keyframe interpolation on cpu and have the gpu only do the skinning. if you also use quaternion+offset (which would make interpolation easier because you can slerp) you'll only need 7 constants per bone. now let's say you use 9 bones (root, 2 for each leg, 2 for each arm) which should be more than enough. you could do 4 units per drawing call (guaranteed). hm... if you have only a few anims you could sort all units of that type based on which 2 keyframes they are in between. and batch all that are between the same two frames together. then you need to send 18 bones - thats 126 constants - to the shader and each unit then needs an additional offset and orientation and the exact interpolation amount, so 7 more constants per unit, so you could batch up to 18 units in one drawing call... if im not totally wrong. if their polycount is fairly low you should be able to draw an insane amount of units...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement