OpenGL ES - Bone Influence Performance
I'm currently using OpenGL ES 1.1 (can't stop to learn 2.0 GLSL at the moment) and I'm using the Matrix Palette Extension to do skeletal animation...
Everything I've tested so far is working marvelously.
You might notice my other post on getting a shoulder to deform a bit better, and I'm finding that I will most likely need to allow at least 3 bones (palettes) to influence each vert to get things looking okay. I was trying to work with just 2, but I'm not sure if that will fly.
I can go up to 4 bones of influence as a max value for the hardware. The question I have now, is of performance as more are used for influence. I already know the issues with memory, as storing more weight values increases the weight array and bone index array sizes quite a bit. I'm ultimately more concerned about whether or not there is a known performance decrease when allowing more bones to influence a verts position in general. I'll would consider using the max of 4 if there isn't a reason besides memory not to.
thanks everyone,
The Toad
If this is ultimately a question for a game-dev or OpenGL forum... I'll be happy to take it there. I started here only because the experience level here is generally much higher than most places.
Everything I've tested so far is working marvelously.
You might notice my other post on getting a shoulder to deform a bit better, and I'm finding that I will most likely need to allow at least 3 bones (palettes) to influence each vert to get things looking okay. I was trying to work with just 2, but I'm not sure if that will fly.
I can go up to 4 bones of influence as a max value for the hardware. The question I have now, is of performance as more are used for influence. I already know the issues with memory, as storing more weight values increases the weight array and bone index array sizes quite a bit. I'm ultimately more concerned about whether or not there is a known performance decrease when allowing more bones to influence a verts position in general. I'll would consider using the max of 4 if there isn't a reason besides memory not to.
thanks everyone,
The Toad
If this is ultimately a question for a game-dev or OpenGL forum... I'll be happy to take it there. I started here only because the experience level here is generally much higher than most places.
Replies
besides memory the arithmetic operations would be a lot more. I'd say 2 weights should be sufficient. More only if its kind of a hero asset up close. As computations are done per-vertex and the same weight count is used for all vertices (even if just a few might use more), try to get away with as little as possible.
I somewhat doubt that the user would see a lot wrong in something as small as a shoulder considering the small screensize and such.
still the only good answers you will ever get is by profiling. btw if you do performance tests, you don't need "good looking" test object, you can use a subdivided capsule apply some biped and automatic weights and let it "wobble" around or whatever. Just to see how much animation, objects.. your engine can take. And with those dummy objects you can vary tri/bone/weight count easily. The main important things to watch for doing this: how many objects you typically have and how they behave (static or animated), how "large" they are on screen and how many textures they use. But once you have a good test-scene that emulates typical camera views and "scene" complexity you can vary parameters rather easily and collect hard data.
Understood, very useful advise I appreciate this a lot. I keep going back and forth between coding and modeling so I'm going to have to, like you say, just take the time to setup a test scenario with enough geometry and textures and see what happens. I'm going with my hunch at the moment and sticking with 3 while I finish up my shoulder and we'll see how it works out. What I'm working on will actually have quite a bit of close up of the main character... but I can probably get away 2 for other animals/creatures as the combat portion won't be quite so zoomed in.