Kwizatz

You probably want to look for morph target animation, which is what all of the sliders control, then interpolate the fixed character morphs with the ones for face expressions if any.

Yes, that's how it used to be, LoadResource which was a protected method, its a good point, I'll think about changing it to something more descriptive.

You may want to consider using polar coordinates or just store the angle of the ray to calculate the line.

If you just sweep the screen borders, the animation will seem to slow down and speed up because of the difference in ratio between width and height.

Well, why not generate the morphs from the bones offline? you add a new character, adjust the armor bones in your favorite 3d modeling package, and then run some script over the existing armor library to generate the morphs for the new guy offline.

 

I guess the way you're thinking it is fine if you don't mind about the extra runtime computations and the state changes when switching from body skeleton to armor skeleton.

Its not the way I'll do it, but I am the guy who tries to do as much as posible offline to squeze the most performance during runtime, I am the type of guy who sets the compiler for speed rather than size , your approach won't bring the computer to its knees, and aside from the limitations I mentioned I can't think of any other that stands out, usually you are in the middle of the implementation when they come out, so you'll never know until you start programming.

IMO, Its not bad per se, but it is limiting.

 

For example, the amount/size of uniforms in a vertex shader is somewhat limited, if you want to do skeletal animation on the GPU, you'll find out that you will be constrained to use between 50 and ~64 bones, a humanoid character can easily take that amount depending on how many fingers it has, nodes for the spine, etc. if you have to add bones for armor the amount of bones goes up, which means either do the animation on the CPU or adjust the skeleton (removing non escencial bones from the body) to fit the uniform limitation.

 

Also, what you'll be doing is pretty much the same as a morph, but using a bone to move several vertices at once instead of one at a time, this could limit how well the clothing would envelope the body, whereas with a morph, you'd have a finer control on how the armor envelops and folds on each character type. I may be wrong, but it would seem to me that about the same amount of work would go into tweaking bone values as it would go toward scaling and stretching the armor for a morph, I don't see where you would be getting something for free (IE: done with one piece of armour, done with all of them kind of thing).

Quote:

Original post by md_lasalle what about the operation of swapping the buffers do you think it would benefit in any way for it to be on its own thread so that you can easily control the rate at which it is being called ? let's say my target is 60 fps, meaning each frame has 16.7 ms to render, and that my last frame took 4 ms to render, I could make the thread sleep for 12.7 ms before swapping the buffer again. what is your opinion on this kind of approach ?

Well, what would you be doing for the time you wait for the thread to wake up? probably lock the rendering thread until the other one calls swap buffers, so its really no use.

Rather than play catch up to a target FPS, you should strive for frame rate independent movement, its not that hard, and there are two articles about it right here and here.