   bindpose skeleton
  Hi. So I'm given a bindpose skeleton whose joints' data consists of a position vector, a rotation quaternion, and parent and child indices. something like:struct joint{   int child, parent;   vec4 rotation;   vec3 position;};Why would a bindpose skeleton need a rotation quaternion if the bindpose skeleton (by definition) is pretty much a static pose? I'm assuming the rotation quaternion animate/move the joints around, but why (especially for a bindpose skeleton)?   
  Well even the static pose has an orientation. If I have a little static armature of a man:o-------   |   | |---| |   | |   |You need the static pose to know that the static position of the leg is up/down while the static pose of the arms is left/right.Does that make sense?   ;  I'm assuming by up/down and left/right, you mean vertical and horizontal, respectively.2 questions:1) in your example, why not just use a vector instead of a quaternion?2) is the orientation with respect to its (the joint's) parent or is it to its child?   ;  Yes I meant horizontal/vertical.Quote:1) in your example, why not just use a vector instead of a quaternion?Typically matrices or quaternions are used for storing rotations. You could probably work up some kind of situation where you could use a vector instead of a rotation, but its just not what's commonly done. I'm surprised that it contains a quaternion and a position, I would think you could store both rotation and position into the quaternion, but I guess its just not how your skeleton stores information. Quote:2) is the orientation with respect to its (the joint's) parent or is it to its child?I would guess it would either be in relation to the armature space or parent space, a bone should not need to have any knowledge of its children (unless you're doing Inverse Kinematics). I couldn't tell you how your particular implementation handles it.;Quote:Original post by karwostsYes I meant horizontal/vertical.Quote:1) in your example, why not just use a vector instead of a quaternion?Typically matrices or quaternions are used for storing rotations. You could probably work up some kind of situation where you could use a vector instead of a rotation, but its just not what's commonly done. I'm surprised that it contains a quaternion and a position, I would think you could store both rotation and position into the quaternion, but I guess its just not how your skeleton stores information. Quote:2) is the orientation with respect to its (the joint's) parent or is it to its child?I would guess it would either be in relation to the armature space or parent space, a bone should not need to have any knowledge of its children (unless you're doing Inverse Kinematics). I couldn't tell you how your particular implementation handles it.Afaik, quaternions can only store rotations. They´re just 4 values, i´d be surprised if you could pack 3-dimensional rotation and position into a 4-dimensional object. Reasons to use quaternions instead of matrices or vectors include avoiding gimbal lock and simplifying&smoothing rotation interpolation, so they´re almost a must if your doing skeletal animation. There is a lot of literature on matrix vs. quaternion, though.So your bone struct makes perfect sense. You should check out if the data is given in local space (respect to the parent) or object space as karwosts said.   ;Quote:Afaik, quaternions can only store rotations. They´re just 4 values, i´d be surprised if you could pack 3-dimensional rotation and position into a 4-dimensional object.You might be right, for some reason I always thought quaternion and 4d matrix was interchangable so I assumed it could store translation, but I've never used them and could be wrong.Quote:Reasons to use quaternions instead of matrices or vectors include avoiding gimbal lockI'm pretty sure this is common misconception, gimbal lock is from using Euler angles, and nothing to do with quaternions. You can still gimbal lock with quaternions if you use Euler angles, just as you can avoid it with matrices by not using Euler angles. Is useful for interpolation though.;  The position of the joint is in object space (not relative to the parent joint).However, I'm still kind of confused.Why is rotation data needed for static joints (bindpose) - the skeleton isn't  even going to be animating.Also, I'm having trouble visualizing how the quaternion is used (i.e. what is being rotated about what and how.) I never really understood quaternions. the only thing I know is that you can convert it to a matrix, it involves imaginary numbers, and that the quaternion is just a scalar and a vector)   ;  Basically you want to know the position and rotation of a static bone so that you can animate it. Lets say you just have an armature like this:root bone  bone 2o-----o------o------   bone 1 In your animation data, you might say, I feel like rotating bone 1 by 45 degrees (to end up with something like this):root bone   o-----o   \ bone 1   \  \ o \ bone 2  \    \  Then to find your bone2 final position/orientation, its going to be something like this:bone2_animated = Bone0toBone1StaticTranslationRotation * Bone1AnimationRotation * Bone1toBone2StaticTranslationRotation I know this stuff can be pretty confusing, so just keep trying to find and read as much as you can and pieces of it will start to click for you. Essentially you combine animation rotations with the static position rotations to come up with the final animated skeleton.   ;  The bind pose is a static pose, the pose used to skin the mesh. A pose is defined by its joints. Each joint it's a reference frame. Usually a joint reference frame is defined with respect to its parent joint space but bind pose (as the static pose used to compute vertex position) is defined in model space. That means that each joint reference frame goes from joint space to model space. So that joint reference frame is used to compute vertex position WRT joint space. So an skinned vertex position could be computed as: v' = Inverse(bind_pose_joint_i) * v (In case that more than one joint affecting a vertex a weighted average is used).Then if we have an animated pose we could compute the vertex position as: v' = animated_joint_i * Inverse(bind_pose_joint_i) * v;Normally a matrix is used to define the joint orientation in the bind pose but a quaternion could be used by convenience. So if your skin code works with quaternions then you need less memory/registers to store a pose.   ;  Thank you, karwosts and alagtriste. Those examples helped a lot.   