In article <3a607978@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> To define "ownership" of each individual vertex is exactly what I had 
> been thinking about. However, several bones should be able to own the 
> same vertex, controlled by weights. That would be a huge amount of 
> data to generate and to store.

I was thinking of having each bone have an ID number. Maybe limit the 
number of bones to 255... So for each vertex, you just have to store a 1 
byte number and a floating point weight value for each bone that affects 
it. (ID 0 would be "no bone") Even the ID/weight pairs would be 
identical among many vertices, so they could share them. (there would be 
many vertices that only belong to one bone)


> That's why I talked about letting strengths control the weights, so 
> calculations can be done on the fly and don't have to be stored. This 
> will probably be slower though than just reading stored data, and 
> identical calculations would have to be done for every frame, which 
> is kind of a waste. Experiments should be done to find the most 
> advantageous method.

Also, how do you decide which bone affects the vertices when the fields 
intersect? I think this method would have problems individually 
controlling things like an arm resting next to a flexing leg.


> Anyway, how would you define a bone? I've thought of it as a line 
> between two points. A field with a user-defined strength and radius 
> would surround this line segment and affect vertex points and normals 
> near it. They would be transformed by a transformation assigned to 
> that bone. But actually it would be better to have *two* 
> transformations assigned to each bone. One for each end. That's 
> because in reality when we twist our limbs (for example our wrist), 
> the twisting actually occurs along the whole limb and not just at the 
> joints. So there should be two transformations assigned to each bone, 
> or maybe one transformation and one twist amount.

I was actually thinking of defining them with 4 points: two "home 
position" points and two "current position" points, and POV would 
compute the transformations. That should make things very easy to 
define. Maybe some kind of orientation vector would also be useful, so 
you could have a twisting from bone to bone, but that could probably be 
emulated with multiple parallel bones.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message