"Chris Huff" wrote:
> The vast majority of vertices will belong to a single bone
> and use the same weight,

The weights are relative, so vertices belonging to one bone only means that
the weight of that bone is 100%.

> so the bone-ID/weight pairs can be kept in an array (with
> no duplicates) and accessed with ID numbers, so all you
> have to store per-vertex is a couble data-ID numbers
> (usually one, only more than one ID when multiple bones
> influence the vertex), and separately an array of bones,
> and an array of bone-ID/weight pairs.

I don't understand that method. Since the weight of a bone is relative to
the weights of other bones, it does't make sense to single out individual
bone-ID/weight pairs. Besides, the probability that several vertices share
the same bone-ID/weights is minimal except in the case where a vertex
belongs to just one bone. Perhaps this method could be used:

For vertices that are influenced by more than one bone, store all relevant
bone-ID/weight pairs for that vertex. For vertices that are influenced by
one bone only, just store the bone-ID. The weight is always 100% in those
cases, so it doesn't have to be stored.

Also, some vertices could have no bone information at all. In that case the
field-weights would be used. This would have the advange that much less bone
data would have to be stored, and the disadvantage that the field-based
weights would have to be calculated for every frame. I don't know if that
would be slow?

> I had been thinking there would be problems when the bone
> fields moved and intersected each other, but they wouldn't...

Correct.

> but unit-length vectors seem to make more sense.

I agree.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message