Jump to content
  • Advertisement
Sign in to follow this  
AvCol

Are mesh vertices usually defined in relation to bones.

This topic is 2699 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Just a quick question

When you are loading in mesh data, are the mesh vertices usually defined relative to the fully calculated bone position ( vertex - joint ) or are they always defined relative to model space origin (vertex - 0)? or is this one of those it depends things.

I was certain it was the former, but I recently wrote a loader for an ms3d file and even though it uses bones, if I don't do any bone transforms everything is in the right place so it looks like the vertices were defined relative to an origin not the bone they belong to.

Share this post


Link to post
Share on other sites
Advertisement
To answer my own question in case someone comes across it wondering: it depends on the file format you choose to support (if applicable) and the rest is up to your engine. There is no "standard" way of doing things.

MD5 seems to do vertex positions in joint space, and I prefer it this way myself.

Share this post


Link to post
Share on other sites
I think it makes a little more sense to define them relative to the model frame, not to a particular bone frame, because you'll often want a vertex to have nonzero weights associated to more than one bone.

(Also, in robotics, "joint space" refers to the set of possible joint angles, but I know what you mean.)

Share this post


Link to post
Share on other sites

I think it makes a little more sense to define them relative to the model frame, not to a particular bone frame, because you'll often want a vertex to have nonzero weights associated to more than one bone.


That makes a lot of sense. In this situation, this would mean that all skeletons passed in to the shader need to be relative to the bind pose skeleton. i.e bone_going_into_shader = model space( bone ) - model space( bindpose bone ). Do I have this correct?

But the way Md5 does it is that each vertex is just an index to a few weights + a bias. The weights are a position and an index to a bone. So the weight positions get transformed into model space by their respective bones, and then finally the vertex is calculated from those using its bias. This avoids skeleton - skeleton arithmetic, and has always been the way I thought of things.

Share this post


Link to post
Share on other sites

That makes a lot of sense. In this situation, this would mean that all skeletons passed in to the shader need to be relative to the bind pose skeleton. i.e bone_going_into_shader = model space( bone ) - model space( bindpose bone ). Do I have this correct?


Yep, that's what I was thinking. Or, really, treating bones as frames, elements of SE(3), 4x4 matrices,

[bone_going_into_shader] = [model_space(bone)] [model_space(bindpose_bone)][sup]-1[/sup]

That said, what I'd been picturing wasn't quite MD5...

But the way Md5 does it is that each vertex is just an index to a few weights + a bias. The weights are a position and an index to a bone. So the weight positions get transformed into model space by their respective bones, and then finally the vertex is calculated from those using its bias. This avoids skeleton - skeleton arithmetic, and has always been the way I thought of things.
[/quote]

Interesting. I hadn't worked with MD5, so I had to look up the format. The terminology I've used doesn't totally agree with MD5's. For me, a "weight" had been a scalar for each (bone,vertex) pair; it looks like this quantity is called the "bias" in the MD5 file format. An MD5-terminology "weight" is really an "invisible vertex under the hood, in bone space", and then the actual vertices are calculated as convex combinations of these.

The MD5 method is a little more general than what I'd been picturing. What I'd been picturing would be MD5, if all the MD5-terminology weights were just the bone-space coordinates of the vertices in the bindpose.

I.e., MD5 computes vertices like,

v = b1 G1 F1 w1 + ... + bm Gm Fm wm

whereas I'd been thinking,

v = (b1 G1 + ... + bm Gm) r

which are the same only when

Fi wi = r

for all i. Here Fi is the modelspace, bind-pose orientation of a bone, Gi is the bind-pose-to-current-pose transformation for that bone, bi is the MD5-terminology "bias" (my-previous-terminology "weight"), wi is the MD5-terminology "weight,"and r is a vertex of the model in the bind-pose, in modelspace. This makes MD5 a little more general, but it also requires storing more data.

Now that I know the MD5 terminology, I should be more helpful! :-)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!