"Chris Huff" wrote:
> "Rune" wrote:
> 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).

That's what I was thinking of too. :)

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

But isn't that what we're talking about? I mean, sure optimisations could be
done, but we're talking about a bone ID and weight per vertex, as opposed to
field-based weights, right?

> > In the "home pose" limbs not affecting each other would
> > have to be separated with a little distance between them.
>
> True, it isn't as bad as I had thought...

What? When? Why?

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

That's what I meant. You should be able to specify weights for just some of
the vertices, and for the rest of the vertices the fields would be used to
assign "default values".

> > Two points can't define an object's alignment in space.
>
> But we aren't defining an object's alignment.

Yes we are! That's what posing a character is all about!
Ask anybody who has posed a figure if it's enough to specify where the hand
is, or if it is also necessary to specify in which direction the palm is
facing.

> And some information could be inferred from the vertex's
> position relative to the bone's initial position...I think.

NO! These must be completely independent of each other!
If you rotate a whole pose 180 degrees its alignment relative to the home
pose is different, but that shouldn't make any difference! The home pose and
the current pose could be miles apart from each other and it should still
work.

> Maybe. Anyone who actually knows something about the
> algorithms behind this stuff is welcome to chip in... ;-)

I've worked a lot with things like this, although only in POV-script. I feel
I know something about it.

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

As I said earlier. :)

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

> However, what should the orientation vectors be? Unit-length
> vectors indicating direction

That's what I thought.

> (maybe non-unit length to indicate some weighting value?),

No, those two things have little to do with each other, so I think it's not
a good idea.

> or a position vector indicating a point next to the bone?

This is basically the same as the unit-length idea isn't it? I go for unit
lengths.

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