Animations- BVH and OBJs

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

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

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

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

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

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