Bipeds & Animation in OpenGL ES 1.0/1.1

Started by
4 comments, last by rbgrn 14 years, 6 months ago
I do mobile game development - http://www.batterypoweredgames.com I'm experienced with OpenGL ES 1.0/bits of 1.1 (VBOs & mipmaps) and am ready to start adding animated characters to my games. Here are the limitations: 1) Method 1 - Rig biped mesh with bones and let hardware transform all the vertices, stretching where necessary, etc.. OpenGL ES 1.1 supports matrix palettes, but not with VBOs, which means performance is too slow on devices, so that means bone-rigged meshes are out. 2) Method 2 - Precompute the different mesh geometries and store each one as a frame. There's just not enough memory store transformed vertices in VBOs for each frame of an animation. So, I already accepted that I won't have modern-looking bipeds, I'll have to go with something that looks a bit more primitive. I can use up to 1000 triangles, so it can be detailed enough, but the joints will look funny, which isn't the end of the world. My idea is to make an object for each part of the biped. The list would be: head, neck, torso, upper lt arm, lower lt arm, etc... Create the animations in a tool like max, export them as animation XML (super easy to read in). The engine would then animate by applying the transforms to each individual part. No geometry ever changes, instead parts are just moved and rotated. This obviously will make joints look bad, because the skin will never stretch or compress like it should, but it'll perform well on a mobile platform. I'm not entirely sure that that is the best way to go. How did people do human-looking characters in old games before bones & skin? Any other ideas? Remember - this is for OpenGL ES 1.0/1.1 on Android (so HTC Dream/Magic/Hero, etc) Thanks!
Advertisement
So no one's got any feedback here? Any info at all would be very helpful and appreciated!!

Thanks!
>> How did people do human-looking characters in old games before bones & skin?
MD2. Each keyframe consisted of all vertex-positions (and optionally normals), precomputed. Lots of RAM. But the G1 has 192MB ^^ . Maybe skinning will have better performance.
1k poly/char IME are a bit too much for the G1, though :P .
Thanks for the answer idinev. I'm only going to have the one character so it can be of a decent poly count. I found that running a scene with 2000 triangles is fine so long as you use VBOs, but this would make it so that I can't use VBOs so there's a trade-off.

I'm exploring all of the options now and am going to do some side by side performance testing to see what works best. I'm hoping for a hardware accelerated option so that I don't end up multiplying every vertex by a bone matrix but that seems to be the way to go right now. Either that or interpolate linearly between meshes which would be less math intensive but still a client-side computation.
Luckily, there's JNI in Android, finally :) . And they've fixed the 16.16 fixed-point BufferInt bug.
It's true. I've been thinking of what I can use the NDK for and vertex computations may be something worthy of it.

By the way, it does have 192MB of RAM but each process is clamped to a measly 16MB. Ouch!

This topic is closed to new replies.

Advertisement