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

> > Maybe limit the number of bones to 255...
> 
> That would be enough in most cases but eventually people would 
> complain over it like they currently do with the limit for 
> color_maps.

Well, the memory requirements of the ID number would increase by 1 byte 
(I don't think people will complain about ~64K bones any time soon).


> For a high quality mesh wouldn't that be a lot of data indeed?
> (I'm not saying it is, I'm just asking.)

Yes, but much less than a bone ID and weight per vertex. Remember that 
as the number of vertices increases, the number of vertices that can 
share the same information also increases, so the extra storage could be 
a little over 2 extra bytes per vertex on average. Much less than 
per-vertex textures, for example.


> > how do you decide which bone affects the vertices when the
> > fields intersect?
> 
> The fields would have S-curved strengths like blob components. For each
> vector all weights would be adjusted to add up to 1 (or 100%).

That is what I had assumed.


> > I think this method would have problems individually
> > controlling things like an arm resting next to a flexing leg.
> 
> In the "home pose" limbs not affecting each other would have to be 
> separated with a little distance between them. For example the home 
> pose could be designed with the arms going to the sides instead of 
> downwards. It would not always be a perfect solution though.

True, it isn't as bad as I had thought...


> I think the best approach is a combination of both methods (storing 
> weights and calculating weights based on fields). First the fields 
> "roughly" determine all the weights; then the individual weights can 
> be adjusted and fine-tuned by the user or by some tool.
> 
> I've read about a bone tool that used a similar approach. First 
> fields were used to assign all weights, then the user could adjust 
> those weights. Seems sensible.

This would seem to be a modeller feature used to set up the bone 
data...it could be used to set "default" values in POV, but you should 
be able to override those values. It could be something that happens 
"behind the scenes" when that data isn't specified.


> > 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.
> 
> Two points can't define an object's alignment in space. At least three
> points are needed. With four points the twisting can be stored too. That
> would be 4 points for the "home position" and 4 points for the current
> position. However, the points for the current position doesn't have to be
> stored, as they are only relevant for the current frame.

But we aren't defining an object's alignment. And some information could 
be inferred from the vertex's position relative to the bone's initial 
position...I think. Maybe. Anyone who actually knows something about the 
algorithms behind this stuff is welcome to chip in... ;-)


> That seems to be an awkward way of doing it. When posing a figure 
> it's *always* relevant how the limbs are aligned. You can't just 
> specify the locations of the limbs and then hope they're facing in 
> the right direction.
> Go for two points plus two orientation vectors; that's the most sensible
> approach.

I think this would be needed to do joints correctly anyway...when you 
rotate your arm, your elbow doesn't slide like a ball joint, your whole 
upper arm twists around the bone.
However, what should the orientation vectors be? Unit-length vectors 
indicating direction (maybe non-unit length to indicate some weighting 
value?), or a position vector indicating a point next to the bone?

-- 
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