   skeletal animation
  I was looking into changing what little I had, and I'm going to be doing away with my Bone class and just stick with my Joint class.But I reading this and I was looking at the joint class which has matrices. If you have the local rotation and local translation, why keep matrices with the absolute and relative transformations?   
All the trig calls to reconstitute the matrices is seen as worse that the space to save the matrices ???  (maybe less an issue if every bone is in motion and you have to generate a delta matrix every frame anyway...)   ;  http://www.robthebloke.org/models/html/Anim_cycles.htmlthats how i do it....  you can probably ignore the joint orient - it's just a Maya thing you don't need to worry about.   ;Quote:Original post by Anonymous PosterAll the trig calls to reconstitute the matrices is seen as worse that the space to save the matrices ???  (maybe less an issue if every bone is in motion and you have to generate a delta matrix every frame anyway...)Okay, I can see that. What about having the absolute translation matrix? Why store the absolute translation?   ;  if you store matrices, animation blending beceomes very difficult. It's better to keep everything as a quaternion for rotation, and vector3 for translation (and scale if you are using it). only covert to matrices at the very end for rendering.   ;  Can you give me a site where there is a good tut on quaternions for skeletal animation? Because I haven't really used quaternions at all.   ;  Everything you need to know is in the link i posted. GameTutorials used to have some good quaternion demos, but not sure if they will be available since their site has gone wierd (err, corporate?). There were a few good courses at siggraph this year on visualising quaternions if you can get hold of this years proceedings. you basically either store all rotations as quaternions to begin with, then you just use the quaternion to slerp the animation. You always need to convert the quaternion to a matrix. If you want to store anim data as Euler angles, then you'll need an additional step of tranforming that into a quat. Baiscally it's only the SLERP and then a conversion to a matrix that you need to worry about. The matrix & Quaternion FAQ is a good place to find out the equations & functions you need.   ;  While I'm doing the same the difference isn't really that big. What is usually done is calculating the different resulting positions, weighting them and adding them all up. For some reason that is accepted, despite the problem with rotations. At the same time everybody knows that interpolating matrices is a bad idea, even though it's mathematically the same. A simple fix should be renormalizing the final matrix or even just resizing the resulting vector to its original length.But it's not like using matrices would require heaps of extra work compared to quaternions. Just a bit. Memory usage however, especially when storing multiple rotations for many complex skeletons is making them kind of tempting (and allows squeezing more of them into the registers for hardware skinning).Quote:Because I haven't really used quaternions at all.In that case, don't. At least not now. Get it to work in the first place, without caring if you get visually unpleasing results when interpolating larger rotations. Once it works using something you know and are familiar with you can still go and replace the matrices with quats. I did it the other way round within maybe 10min just to allow switching and compare the performance (which I should have known was pointless, as with just a couple bones and a simple mesh the difference was obviously zero).And now I need to get a piece of paper and figure out if storing the negated bind pose relative to the parent would work and let me drop at least one of the three sets of data.   ;  Take a look at CAL3D. It'll save you a lot of trouble.   