Animations- BVH and OBJs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Animations- BVH and OBJs

michel-27
Hi,

For making avatars, how does the skeleton (part of BVH) know where to
fit into the mesh (OBJ) ? How to make new avatars ?

Thanks,
-michel
Reply | Threaded
Open this post in threaded view
|

Re: Animations- BVH and OBJs

Howard Stearns-3
On Jan 31, 2008, at 4:58 PM, michel wrote:
> Hi,
>
> For making avatars, how does the skeleton (part of BVH) know where  
> to fit into the mesh (OBJ) ? How to make new avatars ?
>
> Thanks,
> -michel

It doesn't.

There's a whole fascinating world of mapping meshes to bones, that  
I'm just learning about myself.

The Jabberwocky skeletal animation code from U. Minnesota works on a  
TAnimatedMesh object, that is a special kind of mesh with skeleton  
subparts. The TAnimatedMesh is constructed in this code from an  
external modeling program via a unified set of Ogre XML data.

An earlier Hedgehog version of the Minnesota code let you bring in a  
skeleton made from reading a .BVH and combine it with a mesh made  
from reading an .OBJ. But there were issues, and their current code  
doesn't do things that way.

Creating a meaningful mesh/skeleton combination is a real art, and is  
best done using a modeling program designed for that purpose.
* A mesh is a set of vertices, faces on those vertices, and material  
(texture) information.  (All that info is in, e.g., .obj files, or,  
for that matter, .ase, .kmz, .3ds, .wrl, etc.)
* A skeleton is set of joint locations, arranged in a hierarchy. (All  
that info is in, e.g., .bvh files.)
* But a TAnimatedMesh needs to know which vertices get moved when a  
given bone moves, and by how much relative to the influence of other  
bones. These are called bone influences and bone weights. It is  
meaningless to define these by themselves: they only apply to a  
particular COMBINATION of mesh vertices and skeleton bones. An  
Ogre .xml file contain all three sets of information together.  
Creating this combination is called "skinning."

I've tried using cheap modeling programs like Fragmotion, but I was  
not able to teach myself how to get good results.

I've been using 3DS Max (very expensive, alas) as follows, with my  
own variation of the Minnesota code. Your mileage may vary.
* Convert all the stray bits of mesh (hair, shoes, coat, whatever),  
and create a single mesh object, using the "Collapse" utility, if  
necessary.
* Create a "Biped" skeleton, and position it relative to the mesh  
you've got, just like it says in the tutorials.  You will need to  
adjust the structure of the Biped to match the limitations of the  
TAnimatedMesh you're using. (The last time I looked, you needed no  
more than about 25 or so bones. Consult the code.)
* There are two ways to "skin" a mesh in Max: with the "skin" and the  
"physique" mesh modifiers. The tutorials and the commercial content  
I've seen use "physique." However, the Ogre exporter only seems to  
recognize "skin".
* The "skin" modifier has submodifiers for adjusting the envelope of  
influence around each bone. Adjust to taste. Here's where an artist  
helps. (The step is very similar for "physique", but it seems that  
the result from one can't be re-used for the other.)
* There is a free download for an Ogre exporter plugin. Google LEXI  
Ogre exporter. (N.B.: it works on 9, but not earlier. I don't know  
about Max 200N. Also, the installed exporter isn't under File-
 >Export, but rather under "Utilities" panel -> "More..." -> LEXI.)

See also, David Faught's tutorial on creating such content.

For what it's worth, I've been experimenting with ways to apply  
separate BVH skeleton+motion objects to animated mesh objects  
imported separately through Ogre. E.g., dragging a skeleton with one  
motion onto a mesh adds the new motion to the mesh's repertoire. To  
do this, I canonicalize both the skeleton+motion, and the mesh
+skeleton+motions, to a common format.  Alas, so far, I only have  
this working when both skeletons are already in the same "pose",  
although they don't have to be the same size. The hierarchical  
toplogy of each skeleton has to be a subset of the canonical  
skeleton.  In other words, I cannot yet remove bones, remove twists  
(rotations) in between bones, or rebake the animations to fit a  
changed pose. (And I have mixed results in rebaking meshes for  
changed pose.)

-H



Reply | Threaded
Open this post in threaded view
|

Re: Animations- BVH and OBJs

michel-27
Hi,

Many thanks for the detailed explanation and learning for me!

I would like to write some brainstorming output I got from relatives
yesterday: a general opinion seems to be that one of the (few!!) best,
future-oriented "feature" of SL (in comparison to Croquet, Wonderland,
Ogoglio,...) is .. the avatar "system": diverse, rich, flexible,
off-the-shelf, nice-looking, customizable, etc... amazing apparently! Of
course the rest of the SL platform is not always so nice but it is not
the topic in this message ... the key fact is that the SL viewer is open
source now.

Suppose that a company would like to build a front-end which could use
the same avatar system for accessing SL servers and other virtual worlds
platform (all based on BVH/OBJ with some well known differences of
course). For the explained above reason one alternative would be to use
the open source SL client and take out of it the avatar
editing/customization tools and enter it into the new client software.

What do you think guys ?
Is it feasible ?
Does it makes sense ?
Do you see other alternatives to consider ? (at this time I don't know
of any other avatar editor so rich as the SL one, at least for BVH/OBJ).

Thanks again!
-michel

Howard Stearns a écrit :

> On Jan 31, 2008, at 4:58 PM, michel wrote:
>> Hi,
>>
>> For making avatars, how does the skeleton (part of BVH) know where to
>> fit into the mesh (OBJ) ? How to make new avatars ?
>>
>> Thanks,
>> -michel
>
> It doesn't.
>
> There's a whole fascinating world of mapping meshes to bones, that I'm
> just learning about myself.
>
> The Jabberwocky skeletal animation code from U. Minnesota works on a
> TAnimatedMesh object, that is a special kind of mesh with skeleton
> subparts. The TAnimatedMesh is constructed in this code from an
> external modeling program via a unified set of Ogre XML data.
>
> An earlier Hedgehog version of the Minnesota code let you bring in a
> skeleton made from reading a .BVH and combine it with a mesh made from
> reading an .OBJ. But there were issues, and their current code doesn't
> do things that way.
>
> Creating a meaningful mesh/skeleton combination is a real art, and is
> best done using a modeling program designed for that purpose.
> * A mesh is a set of vertices, faces on those vertices, and material
> (texture) information.  (All that info is in, e.g., .obj files, or,
> for that matter, .ase, .kmz, .3ds, .wrl, etc.)
> * A skeleton is set of joint locations, arranged in a hierarchy. (All
> that info is in, e.g., .bvh files.)
> * But a TAnimatedMesh needs to know which vertices get moved when a
> given bone moves, and by how much relative to the influence of other
> bones. These are called bone influences and bone weights. It is
> meaningless to define these by themselves: they only apply to a
> particular COMBINATION of mesh vertices and skeleton bones. An Ogre
> .xml file contain all three sets of information together.  Creating
> this combination is called "skinning."
>
> I've tried using cheap modeling programs like Fragmotion, but I was
> not able to teach myself how to get good results.
>
> I've been using 3DS Max (very expensive, alas) as follows, with my own
> variation of the Minnesota code. Your mileage may vary.
> * Convert all the stray bits of mesh (hair, shoes, coat, whatever),
> and create a single mesh object, using the "Collapse" utility, if
> necessary.
> * Create a "Biped" skeleton, and position it relative to the mesh
> you've got, just like it says in the tutorials.  You will need to
> adjust the structure of the Biped to match the limitations of the
> TAnimatedMesh you're using. (The last time I looked, you needed no
> more than about 25 or so bones. Consult the code.)
> * There are two ways to "skin" a mesh in Max: with the "skin" and the
> "physique" mesh modifiers. The tutorials and the commercial content
> I've seen use "physique." However, the Ogre exporter only seems to
> recognize "skin".
> * The "skin" modifier has submodifiers for adjusting the envelope of
> influence around each bone. Adjust to taste. Here's where an artist
> helps. (The step is very similar for "physique", but it seems that the
> result from one can't be re-used for the other.)
> * There is a free download for an Ogre exporter plugin. Google LEXI
> Ogre exporter. (N.B.: it works on 9, but not earlier. I don't know
> about Max 200N. Also, the installed exporter isn't under File->Export,
> but rather under "Utilities" panel -> "More..." -> LEXI.)
>
> See also, David Faught's tutorial on creating such content.
>
> For what it's worth, I've been experimenting with ways to apply
> separate BVH skeleton+motion objects to animated mesh objects imported
> separately through Ogre. E.g., dragging a skeleton with one motion
> onto a mesh adds the new motion to the mesh's repertoire. To do this,
> I canonicalize both the skeleton+motion, and the
> mesh+skeleton+motions, to a common format.  Alas, so far, I only have
> this working when both skeletons are already in the same "pose",
> although they don't have to be the same size. The hierarchical toplogy
> of each skeleton has to be a subset of the canonical skeleton.  In
> other words, I cannot yet remove bones, remove twists (rotations) in
> between bones, or rebake the animations to fit a changed pose. (And I
> have mixed results in rebaking meshes for changed pose.)
>
> -H
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Animations- BVH and OBJs

Howard Stearns-3
If I understand correctly (and I might not!), one of the limitations  
of the SL approach is that it's all proprietary (independent of  
whether it's open source). That is, the result is only useful in SL.  
It's really not set up to allow you to import something developed in  
a more flexible professional toolchain.  For example, you can import  
textures, but not meshes.
It also doesn't seem to be intended to provide for export to an  
external environment such as Croquet, Wonderland, Ogoglio (or indeed,  
Max, May, Poser, Blender, Daz, ...).

I would encourage you to avoid that trap by making a front end user-
interface that generates a conventional rigged figure that could be  
imported into Croquet (e.g., as Ogre XML), or for that matter, into  
any of the above environments or tools.  I'd love to have such a  
thing, and I image that users of the above would also.

I don't think the generator UI would need to be collaborative or even  
3D, so it's just fine to have it as a separate tool.

Your generator probably wouldn't be reversible (couldn't derive the  
original sliders/options from an existing mesh/skeleton), but you  
could fake it pretty well by storing the original slider/option  
values as metadata in the result (e.g., in another file), so that  
they could be re-used later.

I have no idea whether there's enough info in the SL client code so  
that you could build this by ripping out the code from there. For  
example, for all I know, it might send 200 parameters to the (not yet  
open sourced) server and have the final mesh be generated there.

On Feb 1, 2008, at 3:06 PM, michel wrote:

> Hi,
>
> Many thanks for the detailed explanation and learning for me!
>
> I would like to write some brainstorming output I got from  
> relatives yesterday: a general opinion seems to be that one of the  
> (few!!) best, future-oriented "feature" of SL (in comparison to  
> Croquet, Wonderland, Ogoglio,...) is .. the avatar "system":  
> diverse, rich, flexible, off-the-shelf, nice-looking, customizable,  
> etc... amazing apparently! Of course the rest of the SL platform is  
> not always so nice but it is not the topic in this message ... the  
> key fact is that the SL viewer is open source now.
>
> Suppose that a company would like to build a front-end which could  
> use the same avatar system for accessing SL servers and other  
> virtual worlds platform (all based on BVH/OBJ with some well known  
> differences of course). For the explained above reason one  
> alternative would be to use the open source SL client and take out  
> of it the avatar editing/customization tools and enter it into the  
> new client software.
>
> What do you think guys ?
> Is it feasible ?
> Does it makes sense ?
> Do you see other alternatives to consider ? (at this time I don't  
> know of any other avatar editor so rich as the SL one, at least for  
> BVH/OBJ).
>
> Thanks again!
> -michel
>
> Howard Stearns a écrit :
>> On Jan 31, 2008, at 4:58 PM, michel wrote:
>>> Hi,
>>>
>>> For making avatars, how does the skeleton (part of BVH) know  
>>> where to fit into the mesh (OBJ) ? How to make new avatars ?
>>>
>>> Thanks,
>>> -michel
>>
>> It doesn't.
>>
>> There's a whole fascinating world of mapping meshes to bones, that  
>> I'm just learning about myself.
>>
>> The Jabberwocky skeletal animation code from U. Minnesota works on  
>> a TAnimatedMesh object, that is a special kind of mesh with  
>> skeleton subparts. The TAnimatedMesh is constructed in this code  
>> from an external modeling program via a unified set of Ogre XML data.
>>
>> An earlier Hedgehog version of the Minnesota code let you bring in  
>> a skeleton made from reading a .BVH and combine it with a mesh  
>> made from reading an .OBJ. But there were issues, and their  
>> current code doesn't do things that way.
>>
>> Creating a meaningful mesh/skeleton combination is a real art, and  
>> is best done using a modeling program designed for that purpose.
>> * A mesh is a set of vertices, faces on those vertices, and  
>> material (texture) information.  (All that info is in, e.g., .obj  
>> files, or, for that matter, .ase, .kmz, .3ds, .wrl, etc.)
>> * A skeleton is set of joint locations, arranged in a hierarchy.  
>> (All that info is in, e.g., .bvh files.)
>> * But a TAnimatedMesh needs to know which vertices get moved when  
>> a given bone moves, and by how much relative to the influence of  
>> other bones. These are called bone influences and bone weights. It  
>> is meaningless to define these by themselves: they only apply to a  
>> particular COMBINATION of mesh vertices and skeleton bones. An  
>> Ogre .xml file contain all three sets of information together.  
>> Creating this combination is called "skinning."
>>
>> I've tried using cheap modeling programs like Fragmotion, but I  
>> was not able to teach myself how to get good results.
>>
>> I've been using 3DS Max (very expensive, alas) as follows, with my  
>> own variation of the Minnesota code. Your mileage may vary.
>> * Convert all the stray bits of mesh (hair, shoes, coat,  
>> whatever), and create a single mesh object, using the "Collapse"  
>> utility, if necessary.
>> * Create a "Biped" skeleton, and position it relative to the mesh  
>> you've got, just like it says in the tutorials.  You will need to  
>> adjust the structure of the Biped to match the limitations of the  
>> TAnimatedMesh you're using. (The last time I looked, you needed no  
>> more than about 25 or so bones. Consult the code.)
>> * There are two ways to "skin" a mesh in Max: with the "skin" and  
>> the "physique" mesh modifiers. The tutorials and the commercial  
>> content I've seen use "physique." However, the Ogre exporter only  
>> seems to recognize "skin".
>> * The "skin" modifier has submodifiers for adjusting the envelope  
>> of influence around each bone. Adjust to taste. Here's where an  
>> artist helps. (The step is very similar for "physique", but it  
>> seems that the result from one can't be re-used for the other.)
>> * There is a free download for an Ogre exporter plugin. Google  
>> LEXI Ogre exporter. (N.B.: it works on 9, but not earlier. I don't  
>> know about Max 200N. Also, the installed exporter isn't under File-
>> >Export, but rather under "Utilities" panel -> "More..." -> LEXI.)
>>
>> See also, David Faught's tutorial on creating such content.
>>
>> For what it's worth, I've been experimenting with ways to apply  
>> separate BVH skeleton+motion objects to animated mesh objects  
>> imported separately through Ogre. E.g., dragging a skeleton with  
>> one motion onto a mesh adds the new motion to the mesh's  
>> repertoire. To do this, I canonicalize both the skeleton+motion,  
>> and the mesh+skeleton+motions, to a common format.  Alas, so far,  
>> I only have this working when both skeletons are already in the  
>> same "pose", although they don't have to be the same size. The  
>> hierarchical toplogy of each skeleton has to be a subset of the  
>> canonical skeleton.  In other words, I cannot yet remove bones,  
>> remove twists (rotations) in between bones, or rebake the  
>> animations to fit a changed pose. (And I have mixed results in  
>> rebaking meshes for changed pose.)
>>
>> -H
>>
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Ogre file format specifictions (Re: Animations- BVH and OBJs)

Joshua Gargus-2
I've been trying to Google up the specifications for the various Ogre  
file formats, and can't find them anywhere.  Can anyone here help me  
out with a few links?

Thanks,
Josh


On Feb 1, 2008, at 2:10 PM, Howard Stearns wrote:

> If I understand correctly (and I might not!), one of the limitations  
> of the SL approach is that it's all proprietary (independent of  
> whether it's open source). That is, the result is only useful in SL.  
> It's really not set up to allow you to import something developed in  
> a more flexible professional toolchain.  For example, you can import  
> textures, but not meshes.
> It also doesn't seem to be intended to provide for export to an  
> external environment such as Croquet, Wonderland, Ogoglio (or  
> indeed, Max, May, Poser, Blender, Daz, ...).
>
> I would encourage you to avoid that trap by making a front end user-
> interface that generates a conventional rigged figure that could be  
> imported into Croquet (e.g., as Ogre XML), or for that matter, into  
> any of the above environments or tools.  I'd love to have such a  
> thing, and I image that users of the above would also.
>
> I don't think the generator UI would need to be collaborative or  
> even 3D, so it's just fine to have it as a separate tool.
>
> Your generator probably wouldn't be reversible (couldn't derive the  
> original sliders/options from an existing mesh/skeleton), but you  
> could fake it pretty well by storing the original slider/option  
> values as metadata in the result (e.g., in another file), so that  
> they could be re-used later.
>
> I have no idea whether there's enough info in the SL client code so  
> that you could build this by ripping out the code from there. For  
> example, for all I know, it might send 200 parameters to the (not  
> yet open sourced) server and have the final mesh be generated there.
>
> On Feb 1, 2008, at 3:06 PM, michel wrote:
>
>> Hi,
>>
>> Many thanks for the detailed explanation and learning for me!
>>
>> I would like to write some brainstorming output I got from  
>> relatives yesterday: a general opinion seems to be that one of the  
>> (few!!) best, future-oriented "feature" of SL (in comparison to  
>> Croquet, Wonderland, Ogoglio,...) is .. the avatar "system":  
>> diverse, rich, flexible, off-the-shelf, nice-looking, customizable,  
>> etc... amazing apparently! Of course the rest of the SL platform is  
>> not always so nice but it is not the topic in this message ... the  
>> key fact is that the SL viewer is open source now.
>>
>> Suppose that a company would like to build a front-end which could  
>> use the same avatar system for accessing SL servers and other  
>> virtual worlds platform (all based on BVH/OBJ with some well known  
>> differences of course). For the explained above reason one  
>> alternative would be to use the open source SL client and take out  
>> of it the avatar editing/customization tools and enter it into the  
>> new client software.
>>
>> What do you think guys ?
>> Is it feasible ?
>> Does it makes sense ?
>> Do you see other alternatives to consider ? (at this time I don't  
>> know of any other avatar editor so rich as the SL one, at least for  
>> BVH/OBJ).
>>
>> Thanks again!
>> -michel
>>
>> Howard Stearns a écrit :
>>> On Jan 31, 2008, at 4:58 PM, michel wrote:
>>>> Hi,
>>>>
>>>> For making avatars, how does the skeleton (part of BVH) know  
>>>> where to fit into the mesh (OBJ) ? How to make new avatars ?
>>>>
>>>> Thanks,
>>>> -michel
>>>
>>> It doesn't.
>>>
>>> There's a whole fascinating world of mapping meshes to bones, that  
>>> I'm just learning about myself.
>>>
>>> The Jabberwocky skeletal animation code from U. Minnesota works on  
>>> a TAnimatedMesh object, that is a special kind of mesh with  
>>> skeleton subparts. The TAnimatedMesh is constructed in this code  
>>> from an external modeling program via a unified set of Ogre XML  
>>> data.
>>>
>>> An earlier Hedgehog version of the Minnesota code let you bring in  
>>> a skeleton made from reading a .BVH and combine it with a mesh  
>>> made from reading an .OBJ. But there were issues, and their  
>>> current code doesn't do things that way.
>>>
>>> Creating a meaningful mesh/skeleton combination is a real art, and  
>>> is best done using a modeling program designed for that purpose.
>>> * A mesh is a set of vertices, faces on those vertices, and  
>>> material (texture) information.  (All that info is in, e.g., .obj  
>>> files, or, for that matter, .ase, .kmz, .3ds, .wrl, etc.)
>>> * A skeleton is set of joint locations, arranged in a hierarchy.  
>>> (All that info is in, e.g., .bvh files.)
>>> * But a TAnimatedMesh needs to know which vertices get moved when  
>>> a given bone moves, and by how much relative to the influence of  
>>> other bones. These are called bone influences and bone weights. It  
>>> is meaningless to define these by themselves: they only apply to a  
>>> particular COMBINATION of mesh vertices and skeleton bones. An  
>>> Ogre .xml file contain all three sets of information together.  
>>> Creating this combination is called "skinning."
>>>
>>> I've tried using cheap modeling programs like Fragmotion, but I  
>>> was not able to teach myself how to get good results.
>>>
>>> I've been using 3DS Max (very expensive, alas) as follows, with my  
>>> own variation of the Minnesota code. Your mileage may vary.
>>> * Convert all the stray bits of mesh (hair, shoes, coat,  
>>> whatever), and create a single mesh object, using the "Collapse"  
>>> utility, if necessary.
>>> * Create a "Biped" skeleton, and position it relative to the mesh  
>>> you've got, just like it says in the tutorials.  You will need to  
>>> adjust the structure of the Biped to match the limitations of the  
>>> TAnimatedMesh you're using. (The last time I looked, you needed no  
>>> more than about 25 or so bones. Consult the code.)
>>> * There are two ways to "skin" a mesh in Max: with the "skin" and  
>>> the "physique" mesh modifiers. The tutorials and the commercial  
>>> content I've seen use "physique." However, the Ogre exporter only  
>>> seems to recognize "skin".
>>> * The "skin" modifier has submodifiers for adjusting the envelope  
>>> of influence around each bone. Adjust to taste. Here's where an  
>>> artist helps. (The step is very similar for "physique", but it  
>>> seems that the result from one can't be re-used for the other.)
>>> * There is a free download for an Ogre exporter plugin. Google  
>>> LEXI Ogre exporter. (N.B.: it works on 9, but not earlier. I don't  
>>> know about Max 200N. Also, the installed exporter isn't under File-
>>> >Export, but rather under "Utilities" panel -> "More..." -> LEXI.)
>>>
>>> See also, David Faught's tutorial on creating such content.
>>>
>>> For what it's worth, I've been experimenting with ways to apply  
>>> separate BVH skeleton+motion objects to animated mesh objects  
>>> imported separately through Ogre. E.g., dragging a skeleton with  
>>> one motion onto a mesh adds the new motion to the mesh's  
>>> repertoire. To do this, I canonicalize both the skeleton+motion,  
>>> and the mesh+skeleton+motions, to a common format.  Alas, so far,  
>>> I only have this working when both skeletons are already in the  
>>> same "pose", although they don't have to be the same size. The  
>>> hierarchical toplogy of each skeleton has to be a subset of the  
>>> canonical skeleton.  In other words, I cannot yet remove bones,  
>>> remove twists (rotations) in between bones, or rebake the  
>>> animations to fit a changed pose. (And I have mixed results in  
>>> rebaking meshes for changed pose.)
>>>
>>> -H
>>>
>>>
>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Ogre file format specifictions (Re: Animations- BVH and OBJs)

Peter Moore-5
Hi Josh,

Here's the DTDs for the skeleton and mesh formats.

http://ogre.cvs.sourceforge.net/ogre/ogrenew/Tools/XMLConverter/docs/

-Peter


On Mar 7, 2008, at 6:57 PM, Joshua Gargus wrote:

> I've been trying to Google up the specifications for the various  
> Ogre file formats, and can't find them anywhere.  Can anyone here  
> help me out with a few links?
>
> Thanks,
> Josh
>
>
> On Feb 1, 2008, at 2:10 PM, Howard Stearns wrote:
>
>> If I understand correctly (and I might not!), one of the  
>> limitations of the SL approach is that it's all proprietary  
>> (independent of whether it's open source). That is, the result is  
>> only useful in SL. It's really not set up to allow you to import  
>> something developed in a more flexible professional toolchain.  
>> For example, you can import textures, but not meshes.
>> It also doesn't seem to be intended to provide for export to an  
>> external environment such as Croquet, Wonderland, Ogoglio (or  
>> indeed, Max, May, Poser, Blender, Daz, ...).
>>
>> I would encourage you to avoid that trap by making a front end  
>> user-interface that generates a conventional rigged figure that  
>> could be imported into Croquet (e.g., as Ogre XML), or for that  
>> matter, into any of the above environments or tools.  I'd love to  
>> have such a thing, and I image that users of the above would also.
>>
>> I don't think the generator UI would need to be collaborative or  
>> even 3D, so it's just fine to have it as a separate tool.
>>
>> Your generator probably wouldn't be reversible (couldn't derive  
>> the original sliders/options from an existing mesh/skeleton), but  
>> you could fake it pretty well by storing the original slider/
>> option values as metadata in the result (e.g., in another file),  
>> so that they could be re-used later.
>>
>> I have no idea whether there's enough info in the SL client code  
>> so that you could build this by ripping out the code from there.  
>> For example, for all I know, it might send 200 parameters to the  
>> (not yet open sourced) server and have the final mesh be generated  
>> there.
>>
>> On Feb 1, 2008, at 3:06 PM, michel wrote:
>>
>>> Hi,
>>>
>>> Many thanks for the detailed explanation and learning for me!
>>>
>>> I would like to write some brainstorming output I got from  
>>> relatives yesterday: a general opinion seems to be that one of  
>>> the (few!!) best, future-oriented "feature" of SL (in comparison  
>>> to Croquet, Wonderland, Ogoglio,...) is .. the avatar "system":  
>>> diverse, rich, flexible, off-the-shelf, nice-looking,  
>>> customizable, etc... amazing apparently! Of course the rest of  
>>> the SL platform is not always so nice but it is not the topic in  
>>> this message ... the key fact is that the SL viewer is open  
>>> source now.
>>>
>>> Suppose that a company would like to build a front-end which  
>>> could use the same avatar system for accessing SL servers and  
>>> other virtual worlds platform (all based on BVH/OBJ with some  
>>> well known differences of course). For the explained above reason  
>>> one alternative would be to use the open source SL client and  
>>> take out of it the avatar editing/customization tools and enter  
>>> it into the new client software.
>>>
>>> What do you think guys ?
>>> Is it feasible ?
>>> Does it makes sense ?
>>> Do you see other alternatives to consider ? (at this time I don't  
>>> know of any other avatar editor so rich as the SL one, at least  
>>> for BVH/OBJ).
>>>
>>> Thanks again!
>>> -michel
>>>
>>> Howard Stearns a écrit :
>>>> On Jan 31, 2008, at 4:58 PM, michel wrote:
>>>>> Hi,
>>>>>
>>>>> For making avatars, how does the skeleton (part of BVH) know  
>>>>> where to fit into the mesh (OBJ) ? How to make new avatars ?
>>>>>
>>>>> Thanks,
>>>>> -michel
>>>>
>>>> It doesn't.
>>>>
>>>> There's a whole fascinating world of mapping meshes to bones,  
>>>> that I'm just learning about myself.
>>>>
>>>> The Jabberwocky skeletal animation code from U. Minnesota works  
>>>> on a TAnimatedMesh object, that is a special kind of mesh with  
>>>> skeleton subparts. The TAnimatedMesh is constructed in this code  
>>>> from an external modeling program via a unified set of Ogre XML  
>>>> data.
>>>>
>>>> An earlier Hedgehog version of the Minnesota code let you bring  
>>>> in a skeleton made from reading a .BVH and combine it with a  
>>>> mesh made from reading an .OBJ. But there were issues, and their  
>>>> current code doesn't do things that way.
>>>>
>>>> Creating a meaningful mesh/skeleton combination is a real art,  
>>>> and is best done using a modeling program designed for that  
>>>> purpose.
>>>> * A mesh is a set of vertices, faces on those vertices, and  
>>>> material (texture) information.  (All that info is in,  
>>>> e.g., .obj files, or, for that matter, .ase, .kmz, .3ds, .wrl,  
>>>> etc.)
>>>> * A skeleton is set of joint locations, arranged in a hierarchy.  
>>>> (All that info is in, e.g., .bvh files.)
>>>> * But a TAnimatedMesh needs to know which vertices get moved  
>>>> when a given bone moves, and by how much relative to the  
>>>> influence of other bones. These are called bone influences and  
>>>> bone weights. It is meaningless to define these by themselves:  
>>>> they only apply to a particular COMBINATION of mesh vertices and  
>>>> skeleton bones. An Ogre .xml file contain all three sets of  
>>>> information together.  Creating this combination is called  
>>>> "skinning."
>>>>
>>>> I've tried using cheap modeling programs like Fragmotion, but I  
>>>> was not able to teach myself how to get good results.
>>>>
>>>> I've been using 3DS Max (very expensive, alas) as follows, with  
>>>> my own variation of the Minnesota code. Your mileage may vary.
>>>> * Convert all the stray bits of mesh (hair, shoes, coat,  
>>>> whatever), and create a single mesh object, using the "Collapse"  
>>>> utility, if necessary.
>>>> * Create a "Biped" skeleton, and position it relative to the  
>>>> mesh you've got, just like it says in the tutorials.  You will  
>>>> need to adjust the structure of the Biped to match the  
>>>> limitations of the TAnimatedMesh you're using. (The last time I  
>>>> looked, you needed no more than about 25 or so bones. Consult  
>>>> the code.)
>>>> * There are two ways to "skin" a mesh in Max: with the "skin"  
>>>> and the "physique" mesh modifiers. The tutorials and the  
>>>> commercial content I've seen use "physique." However, the Ogre  
>>>> exporter only seems to recognize "skin".
>>>> * The "skin" modifier has submodifiers for adjusting the  
>>>> envelope of influence around each bone. Adjust to taste. Here's  
>>>> where an artist helps. (The step is very similar for "physique",  
>>>> but it seems that the result from one can't be re-used for the  
>>>> other.)
>>>> * There is a free download for an Ogre exporter plugin. Google  
>>>> LEXI Ogre exporter. (N.B.: it works on 9, but not earlier. I  
>>>> don't know about Max 200N. Also, the installed exporter isn't  
>>>> under File->Export, but rather under "Utilities" panel ->  
>>>> "More..." -> LEXI.)
>>>>
>>>> See also, David Faught's tutorial on creating such content.
>>>>
>>>> For what it's worth, I've been experimenting with ways to apply  
>>>> separate BVH skeleton+motion objects to animated mesh objects  
>>>> imported separately through Ogre. E.g., dragging a skeleton with  
>>>> one motion onto a mesh adds the new motion to the mesh's  
>>>> repertoire. To do this, I canonicalize both the skeleton+motion,  
>>>> and the mesh+skeleton+motions, to a common format.  Alas, so  
>>>> far, I only have this working when both skeletons are already in  
>>>> the same "pose", although they don't have to be the same size.  
>>>> The hierarchical toplogy of each skeleton has to be a subset of  
>>>> the canonical skeleton.  In other words, I cannot yet remove  
>>>> bones, remove twists (rotations) in between bones, or rebake the  
>>>> animations to fit a changed pose. (And I have mixed results in  
>>>> rebaking meshes for changed pose.)
>>>>
>>>> -H
>>>>
>>>>
>>>>
>>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Ogre file format specifictions (Re: Animations- BVH and OBJs)

Joshua Gargus-2
Thanks Peter, that will be useful.

I think that I slipped into a parallel universe at some point.  Am I  
completely mistaken to recall a non-XML ASCII Ogre mesh format?  I was  
nearly certain I'd seen one...

Cheers,
Josh



On Mar 8, 2008, at 8:25 AM, Peter Moore wrote:

> Hi Josh,
>
> Here's the DTDs for the skeleton and mesh formats.
>
> http://ogre.cvs.sourceforge.net/ogre/ogrenew/Tools/XMLConverter/docs/
>
> -Peter
>
>
> On Mar 7, 2008, at 6:57 PM, Joshua Gargus wrote:
>
>> I've been trying to Google up the specifications for the various  
>> Ogre file formats, and can't find them anywhere.  Can anyone here  
>> help me out with a few links?
>>
>> Thanks,
>> Josh
>>
>>
>> On Feb 1, 2008, at 2:10 PM, Howard Stearns wrote:
>>
>>> If I understand correctly (and I might not!), one of the  
>>> limitations of the SL approach is that it's all proprietary  
>>> (independent of whether it's open source). That is, the result is  
>>> only useful in SL. It's really not set up to allow you to import  
>>> something developed in a more flexible professional toolchain.  
>>> For example, you can import textures, but not meshes.
>>> It also doesn't seem to be intended to provide for export to an  
>>> external environment such as Croquet, Wonderland, Ogoglio (or  
>>> indeed, Max, May, Poser, Blender, Daz, ...).
>>>
>>> I would encourage you to avoid that trap by making a front end  
>>> user-interface that generates a conventional rigged figure that  
>>> could be imported into Croquet (e.g., as Ogre XML), or for that  
>>> matter, into any of the above environments or tools.  I'd love to  
>>> have such a thing, and I image that users of the above would also.
>>>
>>> I don't think the generator UI would need to be collaborative or  
>>> even 3D, so it's just fine to have it as a separate tool.
>>>
>>> Your generator probably wouldn't be reversible (couldn't derive  
>>> the original sliders/options from an existing mesh/skeleton), but  
>>> you could fake it pretty well by storing the original slider/
>>> option values as metadata in the result (e.g., in another file),  
>>> so that they could be re-used later.
>>>
>>> I have no idea whether there's enough info in the SL client code  
>>> so that you could build this by ripping out the code from there.  
>>> For example, for all I know, it might send 200 parameters to the  
>>> (not yet open sourced) server and have the final mesh be generated  
>>> there.
>>>
>>> On Feb 1, 2008, at 3:06 PM, michel wrote:
>>>
>>>> Hi,
>>>>
>>>> Many thanks for the detailed explanation and learning for me!
>>>>
>>>> I would like to write some brainstorming output I got from  
>>>> relatives yesterday: a general opinion seems to be that one of  
>>>> the (few!!) best, future-oriented "feature" of SL (in comparison  
>>>> to Croquet, Wonderland, Ogoglio,...) is .. the avatar "system":  
>>>> diverse, rich, flexible, off-the-shelf, nice-looking,  
>>>> customizable, etc... amazing apparently! Of course the rest of  
>>>> the SL platform is not always so nice but it is not the topic in  
>>>> this message ... the key fact is that the SL viewer is open  
>>>> source now.
>>>>
>>>> Suppose that a company would like to build a front-end which  
>>>> could use the same avatar system for accessing SL servers and  
>>>> other virtual worlds platform (all based on BVH/OBJ with some  
>>>> well known differences of course). For the explained above reason  
>>>> one alternative would be to use the open source SL client and  
>>>> take out of it the avatar editing/customization tools and enter  
>>>> it into the new client software.
>>>>
>>>> What do you think guys ?
>>>> Is it feasible ?
>>>> Does it makes sense ?
>>>> Do you see other alternatives to consider ? (at this time I don't  
>>>> know of any other avatar editor so rich as the SL one, at least  
>>>> for BVH/OBJ).
>>>>
>>>> Thanks again!
>>>> -michel
>>>>
>>>> Howard Stearns a écrit :
>>>>> On Jan 31, 2008, at 4:58 PM, michel wrote:
>>>>>> Hi,
>>>>>>
>>>>>> For making avatars, how does the skeleton (part of BVH) know  
>>>>>> where to fit into the mesh (OBJ) ? How to make new avatars ?
>>>>>>
>>>>>> Thanks,
>>>>>> -michel
>>>>>
>>>>> It doesn't.
>>>>>
>>>>> There's a whole fascinating world of mapping meshes to bones,  
>>>>> that I'm just learning about myself.
>>>>>
>>>>> The Jabberwocky skeletal animation code from U. Minnesota works  
>>>>> on a TAnimatedMesh object, that is a special kind of mesh with  
>>>>> skeleton subparts. The TAnimatedMesh is constructed in this code  
>>>>> from an external modeling program via a unified set of Ogre XML  
>>>>> data.
>>>>>
>>>>> An earlier Hedgehog version of the Minnesota code let you bring  
>>>>> in a skeleton made from reading a .BVH and combine it with a  
>>>>> mesh made from reading an .OBJ. But there were issues, and their  
>>>>> current code doesn't do things that way.
>>>>>
>>>>> Creating a meaningful mesh/skeleton combination is a real art,  
>>>>> and is best done using a modeling program designed for that  
>>>>> purpose.
>>>>> * A mesh is a set of vertices, faces on those vertices, and  
>>>>> material (texture) information.  (All that info is in,  
>>>>> e.g., .obj files, or, for that matter, .ase, .kmz, .3ds, .wrl,  
>>>>> etc.)
>>>>> * A skeleton is set of joint locations, arranged in a hierarchy.  
>>>>> (All that info is in, e.g., .bvh files.)
>>>>> * But a TAnimatedMesh needs to know which vertices get moved  
>>>>> when a given bone moves, and by how much relative to the  
>>>>> influence of other bones. These are called bone influences and  
>>>>> bone weights. It is meaningless to define these by themselves:  
>>>>> they only apply to a particular COMBINATION of mesh vertices and  
>>>>> skeleton bones. An Ogre .xml file contain all three sets of  
>>>>> information together.  Creating this combination is called  
>>>>> "skinning."
>>>>>
>>>>> I've tried using cheap modeling programs like Fragmotion, but I  
>>>>> was not able to teach myself how to get good results.
>>>>>
>>>>> I've been using 3DS Max (very expensive, alas) as follows, with  
>>>>> my own variation of the Minnesota code. Your mileage may vary.
>>>>> * Convert all the stray bits of mesh (hair, shoes, coat,  
>>>>> whatever), and create a single mesh object, using the "Collapse"  
>>>>> utility, if necessary.
>>>>> * Create a "Biped" skeleton, and position it relative to the  
>>>>> mesh you've got, just like it says in the tutorials.  You will  
>>>>> need to adjust the structure of the Biped to match the  
>>>>> limitations of the TAnimatedMesh you're using. (The last time I  
>>>>> looked, you needed no more than about 25 or so bones. Consult  
>>>>> the code.)
>>>>> * There are two ways to "skin" a mesh in Max: with the "skin"  
>>>>> and the "physique" mesh modifiers. The tutorials and the  
>>>>> commercial content I've seen use "physique." However, the Ogre  
>>>>> exporter only seems to recognize "skin".
>>>>> * The "skin" modifier has submodifiers for adjusting the  
>>>>> envelope of influence around each bone. Adjust to taste. Here's  
>>>>> where an artist helps. (The step is very similar for "physique",  
>>>>> but it seems that the result from one can't be re-used for the  
>>>>> other.)
>>>>> * There is a free download for an Ogre exporter plugin. Google  
>>>>> LEXI Ogre exporter. (N.B.: it works on 9, but not earlier. I  
>>>>> don't know about Max 200N. Also, the installed exporter isn't  
>>>>> under File->Export, but rather under "Utilities" panel ->  
>>>>> "More..." -> LEXI.)
>>>>>
>>>>> See also, David Faught's tutorial on creating such content.
>>>>>
>>>>> For what it's worth, I've been experimenting with ways to apply  
>>>>> separate BVH skeleton+motion objects to animated mesh objects  
>>>>> imported separately through Ogre. E.g., dragging a skeleton with  
>>>>> one motion onto a mesh adds the new motion to the mesh's  
>>>>> repertoire. To do this, I canonicalize both the skeleton+motion,  
>>>>> and the mesh+skeleton+motions, to a common format.  Alas, so  
>>>>> far, I only have this working when both skeletons are already in  
>>>>> the same "pose", although they don't have to be the same size.  
>>>>> The hierarchical toplogy of each skeleton has to be a subset of  
>>>>> the canonical skeleton.  In other words, I cannot yet remove  
>>>>> bones, remove twists (rotations) in between bones, or rebake the  
>>>>> animations to fit a changed pose. (And I have mixed results in  
>>>>> rebaking meshes for changed pose.)
>>>>>
>>>>> -H
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Ogre file format specifictions (Re: Animations- BVH and OBJs)

Peter Moore-5
Nope, you're still here. ;-) There is a binary version, but I haven't  
seen a spec for that. Let me know if you find it. There is a tool to  
convert from binary to XML (and possible vice versa) here:

http://www.ogre3d.org/index.php?Itemid=133

On Mar 8, 2008, at 5:02 PM, Joshua Gargus wrote:

> Thanks Peter, that will be useful.
>
> I think that I slipped into a parallel universe at some point.  Am  
> I completely mistaken to recall a non-XML ASCII Ogre mesh format?  
> I was nearly certain I'd seen one...
>
> Cheers,
> Josh
>
>
>
> On Mar 8, 2008, at 8:25 AM, Peter Moore wrote:
>
>> Hi Josh,
>>
>> Here's the DTDs for the skeleton and mesh formats.
>>
>> http://ogre.cvs.sourceforge.net/ogre/ogrenew/Tools/XMLConverter/docs/
>>
>> -Peter
>>
>>
>> On Mar 7, 2008, at 6:57 PM, Joshua Gargus wrote:
>>
>>> I've been trying to Google up the specifications for the various  
>>> Ogre file formats, and can't find them anywhere.  Can anyone here  
>>> help me out with a few links?
>>>
>>> Thanks,
>>> Josh
>>>
>>>
>>> On Feb 1, 2008, at 2:10 PM, Howard Stearns wrote:
>>>
>>>> If I understand correctly (and I might not!), one of the  
>>>> limitations of the SL approach is that it's all proprietary  
>>>> (independent of whether it's open source). That is, the result  
>>>> is only useful in SL. It's really not set up to allow you to  
>>>> import something developed in a more flexible professional  
>>>> toolchain.  For example, you can import textures, but not meshes.
>>>> It also doesn't seem to be intended to provide for export to an  
>>>> external environment such as Croquet, Wonderland, Ogoglio (or  
>>>> indeed, Max, May, Poser, Blender, Daz, ...).
>>>>
>>>> I would encourage you to avoid that trap by making a front end  
>>>> user-interface that generates a conventional rigged figure that  
>>>> could be imported into Croquet (e.g., as Ogre XML), or for that  
>>>> matter, into any of the above environments or tools.  I'd love  
>>>> to have such a thing, and I image that users of the above would  
>>>> also.
>>>>
>>>> I don't think the generator UI would need to be collaborative or  
>>>> even 3D, so it's just fine to have it as a separate tool.
>>>>
>>>> Your generator probably wouldn't be reversible (couldn't derive  
>>>> the original sliders/options from an existing mesh/skeleton),  
>>>> but you could fake it pretty well by storing the original slider/
>>>> option values as metadata in the result (e.g., in another file),  
>>>> so that they could be re-used later.
>>>>
>>>> I have no idea whether there's enough info in the SL client code  
>>>> so that you could build this by ripping out the code from there.  
>>>> For example, for all I know, it might send 200 parameters to the  
>>>> (not yet open sourced) server and have the final mesh be  
>>>> generated there.
>>>>
>>>> On Feb 1, 2008, at 3:06 PM, michel wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Many thanks for the detailed explanation and learning for me!
>>>>>
>>>>> I would like to write some brainstorming output I got from  
>>>>> relatives yesterday: a general opinion seems to be that one of  
>>>>> the (few!!) best, future-oriented "feature" of SL (in  
>>>>> comparison to Croquet, Wonderland, Ogoglio,...) is .. the  
>>>>> avatar "system": diverse, rich, flexible, off-the-shelf, nice-
>>>>> looking, customizable, etc... amazing apparently! Of course the  
>>>>> rest of the SL platform is not always so nice but it is not the  
>>>>> topic in this message ... the key fact is that the SL viewer is  
>>>>> open source now.
>>>>>
>>>>> Suppose that a company would like to build a front-end which  
>>>>> could use the same avatar system for accessing SL servers and  
>>>>> other virtual worlds platform (all based on BVH/OBJ with some  
>>>>> well known differences of course). For the explained above  
>>>>> reason one alternative would be to use the open source SL  
>>>>> client and take out of it the avatar editing/customization  
>>>>> tools and enter it into the new client software.
>>>>>
>>>>> What do you think guys ?
>>>>> Is it feasible ?
>>>>> Does it makes sense ?
>>>>> Do you see other alternatives to consider ? (at this time I  
>>>>> don't know of any other avatar editor so rich as the SL one, at  
>>>>> least for BVH/OBJ).
>>>>>
>>>>> Thanks again!
>>>>> -michel
>>>>>
>>>>> Howard Stearns a écrit :
>>>>>> On Jan 31, 2008, at 4:58 PM, michel wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> For making avatars, how does the skeleton (part of BVH) know  
>>>>>>> where to fit into the mesh (OBJ) ? How to make new avatars ?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -michel
>>>>>>
>>>>>> It doesn't.
>>>>>>
>>>>>> There's a whole fascinating world of mapping meshes to bones,  
>>>>>> that I'm just learning about myself.
>>>>>>
>>>>>> The Jabberwocky skeletal animation code from U. Minnesota  
>>>>>> works on a TAnimatedMesh object, that is a special kind of  
>>>>>> mesh with skeleton subparts. The TAnimatedMesh is constructed  
>>>>>> in this code from an external modeling program via a unified  
>>>>>> set of Ogre XML data.
>>>>>>
>>>>>> An earlier Hedgehog version of the Minnesota code let you  
>>>>>> bring in a skeleton made from reading a .BVH and combine it  
>>>>>> with a mesh made from reading an .OBJ. But there were issues,  
>>>>>> and their current code doesn't do things that way.
>>>>>>
>>>>>> Creating a meaningful mesh/skeleton combination is a real art,  
>>>>>> and is best done using a modeling program designed for that  
>>>>>> purpose.
>>>>>> * A mesh is a set of vertices, faces on those vertices, and  
>>>>>> material (texture) information.  (All that info is in,  
>>>>>> e.g., .obj files, or, for that matter, .ase, .kmz, .3ds, .wrl,  
>>>>>> etc.)
>>>>>> * A skeleton is set of joint locations, arranged in a  
>>>>>> hierarchy. (All that info is in, e.g., .bvh files.)
>>>>>> * But a TAnimatedMesh needs to know which vertices get moved  
>>>>>> when a given bone moves, and by how much relative to the  
>>>>>> influence of other bones. These are called bone influences and  
>>>>>> bone weights. It is meaningless to define these by themselves:  
>>>>>> they only apply to a particular COMBINATION of mesh vertices  
>>>>>> and skeleton bones. An Ogre .xml file contain all three sets  
>>>>>> of information together.  Creating this combination is called  
>>>>>> "skinning."
>>>>>>
>>>>>> I've tried using cheap modeling programs like Fragmotion, but  
>>>>>> I was not able to teach myself how to get good results.
>>>>>>
>>>>>> I've been using 3DS Max (very expensive, alas) as follows,  
>>>>>> with my own variation of the Minnesota code. Your mileage may  
>>>>>> vary.
>>>>>> * Convert all the stray bits of mesh (hair, shoes, coat,  
>>>>>> whatever), and create a single mesh object, using the  
>>>>>> "Collapse" utility, if necessary.
>>>>>> * Create a "Biped" skeleton, and position it relative to the  
>>>>>> mesh you've got, just like it says in the tutorials.  You will  
>>>>>> need to adjust the structure of the Biped to match the  
>>>>>> limitations of the TAnimatedMesh you're using. (The last time  
>>>>>> I looked, you needed no more than about 25 or so bones.  
>>>>>> Consult the code.)
>>>>>> * There are two ways to "skin" a mesh in Max: with the "skin"  
>>>>>> and the "physique" mesh modifiers. The tutorials and the  
>>>>>> commercial content I've seen use "physique." However, the Ogre  
>>>>>> exporter only seems to recognize "skin".
>>>>>> * The "skin" modifier has submodifiers for adjusting the  
>>>>>> envelope of influence around each bone. Adjust to taste.  
>>>>>> Here's where an artist helps. (The step is very similar for  
>>>>>> "physique", but it seems that the result from one can't be re-
>>>>>> used for the other.)
>>>>>> * There is a free download for an Ogre exporter plugin. Google  
>>>>>> LEXI Ogre exporter. (N.B.: it works on 9, but not earlier. I  
>>>>>> don't know about Max 200N. Also, the installed exporter isn't  
>>>>>> under File->Export, but rather under "Utilities" panel ->  
>>>>>> "More..." -> LEXI.)
>>>>>>
>>>>>> See also, David Faught's tutorial on creating such content.
>>>>>>
>>>>>> For what it's worth, I've been experimenting with ways to  
>>>>>> apply separate BVH skeleton+motion objects to animated mesh  
>>>>>> objects imported separately through Ogre. E.g., dragging a  
>>>>>> skeleton with one motion onto a mesh adds the new motion to  
>>>>>> the mesh's repertoire. To do this, I canonicalize both the  
>>>>>> skeleton+motion, and the mesh+skeleton+motions, to a common  
>>>>>> format.  Alas, so far, I only have this working when both  
>>>>>> skeletons are already in the same "pose", although they don't  
>>>>>> have to be the same size. The hierarchical toplogy of each  
>>>>>> skeleton has to be a subset of the canonical skeleton.  In  
>>>>>> other words, I cannot yet remove bones, remove twists  
>>>>>> (rotations) in between bones, or rebake the animations to fit  
>>>>>> a changed pose. (And I have mixed results in rebaking meshes  
>>>>>> for changed pose.)
>>>>>>
>>>>>> -H
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>