Re: [osg-users] about the state of the BVH plug-in, when used with CMU MoCap files

[Alex Chen]

Hi all,

I get the same problem with BVH plug in when using CMU dataset.
Below is my minor fix to the code and it seems to work for several motions I 
loaded.

File attached.
Main changes:
typedef std::pair 
> JointNode;

void alterChannel( std::string name, std::pair& p )
{
int& value = p.first;
std::string& str = p.second;

if  ( name=="Xposition" ) value |= 0x01;
else if ( name=="Yposition" ) value |= 0x02;
else if ( name=="Zposition" ) value |= 0x04;
else if ( name=="Zrotation" ) {value |= 0x08; 
str.push_back('Z');}
else if ( name=="Xrotation" ) {value |= 0x10; 
str.push_back('X');}
else if ( name=="Yrotation" ) {value |= 0x20; 
str.push_back('Y');}
}

void setKeyframe( osgDB::Input& fr, int ch, const std::string& order, 
double time,
  osgAnimation::Vec3KeyframeContainer* posKey,
  osgAnimation::QuatKeyframeContainer* rotKey )
{
if ( ch&0x07 && posKey )  // Position keyframe
{
float keyValue[3] = { 0.0f };
if ( ch&0x01 ) fr.readSequence( keyValue[0] );
if ( ch&0x02 ) fr.readSequence( keyValue[1] );
if ( ch&0x04 ) fr.readSequence( keyValue[2] );

osg::Vec3 vec( keyValue[0], keyValue[1], keyValue[2] );
posKey->push_back( osgAnimation::Vec3Keyframe(time, vec) );
}

if ( ch&0x38 && rotKey )  // Rotation keyframe
{
osg::Matrix rotMat;
float keyValue[3] = { 0.0f };
for(int i = 0; i < order.size(); ++i) {
char f = order[i];
if(f == 'X') {
if ( ch&0x10 ) fr.readSequence( 
keyValue[0] );
rotMat = 
osg::Matrix::rotate(osg::DegreesToRadians(keyValue[0]), osg::Vec3(1.0,0.0,0.0)) 
* rotMat;
}
else if(f == 'Y') {
if ( ch&0x20 ) fr.readSequence( 
keyValue[1] );
rotMat = 
osg::Matrix::rotate(osg::DegreesToRadians(keyValue[1]), osg::Vec3(0.0,1.0,0.0)) 
* rotMat;
}
else if(f == 'Z') {
if ( ch&0x08 ) fr.readSequence( 
keyValue[2] );
rotMat = 
osg::Matrix::rotate(osg::DegreesToRadians(keyValue[2]), osg::Vec3(0.0,0.0,1.0)) 
* rotMat;
}
}
osg::Quat quat = rotMat.getRotate();
rotKey->push_back( osgAnimation::QuatKeyframe(time, 
quat) );
}
}

There are a few other places that can be seen by compared files.


Cheers,
Alex

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66969#66969




Attachments: 
http://forum.openscenegraph.org//files/readerwriterbvh_119.cpp


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] about the state of the BVH plug-in, when used with CMU MoCap files

[Jan Ciger]

On Fri, Apr 1, 2016 at 4:45 PM, Christian Buchner
 wrote:
>
>
> I've tried the OSG 3.2 branch and this version exhibited the same problem.
>
> Then I had a closer look at the BVH files supplied by that web site. I am 
> finding that it defines
> rotational parameters always in the order Z, Y,  X.  That is different from 
> the sequence I expect
> from various online sources that use Z, X, Y.
>
> ...
> I will have to do some more online research to understand whether the BVH 
> spec actually allows
> to specify rotation in an arbitrary order and what the definitive answer 
> about the sequence of applying
> the Euler angles is.
>

Actually, the order is not defined by the spec
(http://www.character-studio.net/bvh_file_specification.htm). Usually
it is assumed to be YXZ, but that's not always the case, the same as
there is no way to tell which way is "up" for the character :(

The only thing you can use to guess the order is the CHANNELS keyword
in the joint definition in the hierarchy part.

CHANNELS 3 Zrotation Xrotation Yrotation

This one defines the ZXY parsing order.  The problem is that some
software understands this as only the specification in which order are
the data written into the file, but not the order in which to compose
the transforms. So this, along with the z-up/y-up, which way is
forward, etc. must not be hardwired, because every mocap
system/animation software exports these files with different
conventions :(

Regards,

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] about the state of the BVH plug-in, when used with CMU MoCap files

[Christian Buchner]

I've tried the OSG 3.2 branch and this version exhibited the same problem.

Then I had a closer look at the BVH files supplied by that web site. I am
finding that it defines
rotational parameters always in the order Z, Y,  X.  That is different from
the sequence I expect
from various online sources that use Z, X, Y.

in the plugin code, hence I adjust the sequence of keyValues read from the
file to read z, y, x
in this order.

if ( ch&0x08 ) fr.readSequence( keyValue[2] );  // Z
if ( ch&0x20 ) fr.readSequence( keyValue[1] );  // Y
if ( ch&0x10 ) fr.readSequence( keyValue[0] );  // X

But this alone wasn't sufficient to get correct results.

I also had to swap the order in which we generate the rotation matrix to
X*Y*Z.

osg::Matrix rotMat =

osg::Matrix::rotate(osg::DegreesToRadians(keyValue[0]),
osg::Vec3(1.0,0.0,0.0))
   *
osg::Matrix::rotate(osg::DegreesToRadians(keyValue[1]),
osg::Vec3(0.0,1.0,0.0))
   *
osg::Matrix::rotate(osg::DegreesToRadians(keyValue[2]),
osg::Vec3(0.0,0.0,1.0));

This appears to be the opposite order in which the above Euler angles are
specified.

Now the animations play out correctly, as far as I can tell.

I will have to do some more online research to understand whether the BVH
spec actually allows
to specify rotation in an arbitrary order and what the definitive answer
about the sequence of applying
the Euler angles is.

The first change could certainly determined automatically from the input
file, but whether or not the
sequence of matrix multiplications shall always occur in the opposite order
is up for debate.

I might propose a suitable patch to the BVH plug-in later.

Christian



2016-04-01 14:38 GMT+02:00 Christian Buchner :

>
> This is how I call the osganimationviewer to display a skeleton from the
> motion data.
>
> osganimationviewer --drawbone C:\mocap\motionbuilder\01\01_02.bvh -O solids
>
> Just the result is a bit unexpected...
>
> 2016-04-01 14:33 GMT+02:00 Christian Buchner 
> :
>
>> Hi all,
>>
>> I've been trying to get the BVH files from this site to import into the
>> current OSG 3.4 branch
>>
>> https://sites.google.com/a/cgspeed.com/cgspeed/motion-capture/cmu-bvh-conversion
>>
>> These are conversions of the original motion capture data that CMU
>> provides for free in a different format, optimized for the three
>> applications MotionBuilder, DAZ Studio and 3DS MAX.
>>
>> I've tried replaying the animations in osganimationviewer using the
>> --drawbone flag. Usually one needs to zoom out the camera to get the full
>> skeleton into view. The issue that I am having is that I see weird and
>> unexpected rotations of the entire skeleton, as well as specific joints -
>> regardless of the version of the BVH files I download.
>>
>> Has the OpenSceneGraph BVH plug-in ever worked on these mocap files?
>> Could it be that a code regression has recently broken the plug-in?
>>
>> Christian
>>
>>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] about the state of the BVH plug-in, when used with CMU MoCap files

[Christian Buchner]

This is how I call the osganimationviewer to display a skeleton from the
motion data.

osganimationviewer --drawbone C:\mocap\motionbuilder\01\01_02.bvh -O solids

Just the result is a bit unexpected...

2016-04-01 14:33 GMT+02:00 Christian Buchner :

> Hi all,
>
> I've been trying to get the BVH files from this site to import into the
> current OSG 3.4 branch
>
> https://sites.google.com/a/cgspeed.com/cgspeed/motion-capture/cmu-bvh-conversion
>
> These are conversions of the original motion capture data that CMU
> provides for free in a different format, optimized for the three
> applications MotionBuilder, DAZ Studio and 3DS MAX.
>
> I've tried replaying the animations in osganimationviewer using the
> --drawbone flag. Usually one needs to zoom out the camera to get the full
> skeleton into view. The issue that I am having is that I see weird and
> unexpected rotations of the entire skeleton, as well as specific joints -
> regardless of the version of the BVH files I download.
>
> Has the OpenSceneGraph BVH plug-in ever worked on these mocap files? Could
> it be that a code regression has recently broken the plug-in?
>
> Christian
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] about the state of the BVH plug-in, when used with CMU MoCap files

[Christian Buchner]

Hi all,

I've been trying to get the BVH files from this site to import into the
current OSG 3.4 branch
https://sites.google.com/a/cgspeed.com/cgspeed/motion-capture/cmu-bvh-conversion

These are conversions of the original motion capture data that CMU provides
for free in a different format, optimized for the three applications
MotionBuilder, DAZ Studio and 3DS MAX.

I've tried replaying the animations in osganimationviewer using the
--drawbone flag. Usually one needs to zoom out the camera to get the full
skeleton into view. The issue that I am having is that I see weird and
unexpected rotations of the entire skeleton, as well as specific joints -
regardless of the version of the BVH files I download.

Has the OpenSceneGraph BVH plug-in ever worked on these mocap files? Could
it be that a code regression has recently broken the plug-in?

Christian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org