bvh importers and exporters

[FairyTail]

I'm looking at the various bvh importers and exporters, in particular plugins/9_export_bvh. Can anyone tell me if this is currently supported or deprecated?

Also, could anyone explain why some joints generated by the exporter have a __ prefix?

Code: Select all

          JOINT spine01                                   
          {                                               
            OFFSET  0.018187  1.276488  0.448821           
            CHANNELS 3 Zrotation Xrotation Yrotation       
            JOINT __clavicle.L                             
            {                                             
              OFFSET  0.048230  1.179821  0.377792         
              CHANNELS 3 Zrotation Xrotation Yrotation     
              JOINT clavicle.L                             


Thanks.

[duststorm]

The code is actually quite well documented. From the documentation of bvh.py:

"""
Construct a BVH object from a skeleton structure and optionally an
animation track. If no animation track is specified, a dummy animation
of one frame will be added.
If dummyJoints is true (the default) then extra dummy joints will be
introduced when bones are not directly connected, but have their head
position offset from their parent bone tail. This often happens when
multiple bones are attached to one parent bones, for example in the
shoulder, hip and hand areas.
When dummyJoints is set to false, for each bone in the skeleton, exactly
one BVH joint will be created. How this is interpreted depends on the
tool importing the BVH file. Some create only a bone between the parent
and its first child joint, and create empty offsets to the other childs.
Other tools create one bone, with the tail position being the average
of all the child joints. Dummy joints are introduced to prevent
ambiguities between tools. Dummy joints carry the same name as the bone
they parent, with "__" prepended.

NOTE: Make sure that the skeleton has only one root.
"""

Basically the BVH exporter offers a few strategies of mapping bones to joints, which can be specified using the API. The standard exporter GUI does not expose all these options, though, and chooses a sane default.
Yes it is still maintained, there might be a bug in it at the moment with alternative rest poses, though, as I have seen an issue pass about it on the tracker.

[FairyTail]

Yes it is still maintained, there might be a bug in it at the moment with alternative rest poses, though, as I have seen an issue pass about it on the tracker.

Yes, BigBaer and I were chatting about this on IRC yesterday, and I managed to confuse the heck out of myself again. I've been looking at the import code all day, and can't quite figure it out. In:

Code: Select all

def bvh_node_dict2armature(context,             
                           bvh_name,           
                           bvh_nodes,           
                           bvh_frame_time,     
                           rotate_mode='XYZ',   
                           frame_start=1,       
                           IMPORT_LOOP=False,   
                           global_matrix=None, 
                           use_fps_scale=False,
                           ):                   


I change the rotate_mode to always be 'NATIVE':

Code: Select all

    rotate_mode = 'NATIVE'                                                                                       
                                                                                                                 
    if rotate_mode == 'NATIVE':                                                                                 
        for bvh_node in bvh_nodes_list:                                                                         
            bone_name = bvh_node.temp  # may not be the same name as the bvh_node, could have been shortened.   
            pose_bone = pose_bones[bone_name]                                                                   
            pose_bone.rotation_mode = bvh_node.rot_order_str                                                     
            print("rotate_mode %s" % pose_bone.rotation_mode)                                                   


The idea being that it always uses the value of "bvh_node.rot_order_str", since this depends on the rotation order in the file. So I would expect pose_bone.rotation_mode to be 'ZXY' for "CHANNELS 3 Zrotation Xrotation Yrotation", and 'ZYX' for "CHANNELS 3 Zrotation Yrotation Xrotation", but it always prints 'XYZ'. Mind you, it's been years since I tried to do anything in python. Anyway, I like a challenge, so I'll keep on looking.

ETA: Typical, post a comment, and spot a silly error. I was using the wrong test bvh files I think I'll take a break for a few days and let the professionals sort it out.

ETA2: At the risk of embarrassing myself further, here is my test pose, first with a MOTION section left, and MOTION set to zero right:

I then open the original blend

and apply bvh without the motion section and I get, as I would expect, the A-pose

Now, if I re-open the blend and apply the bvh with the motion section, I get


Surely, the MOTION section should be applied to A-pose which I know works?

No need to answer, I'm just trying to get my head around it.

[FairyTail]

So, now I start with my original blend

and apply fly01.bvh with zeroed motion and I get the A-pose:

Now, re-open the original blend and apply fly01.bvh with its original motion, and:

Compare this with fly01.bvh with its original motion applied to a rigged base mesh in the A-pose:


So, it appears that the hierarchy section restores the bvh base pose, but the original pose influences the final hierarchy + motion.

Using the blender bvh importer on fly01.bvh with zeroed motion:

and we get something close to the A-pose.

So, it would appear that the motion section is being applied to something which causes the strange mutations.

ETA: should have tried it with benchmark.bvh with zeroed motion:


But I still think there is something wrong with the initial conditions.

ETA2: Applying benchmark.bvh with zeroed motion to my original blend gives me an A-pose again. I hope I'm not missing something obvious.

[duststorm]

Best create an issue about this on the bugtracker so I don't forget to look at it.

EDIT: Oh wait, I guess this issue is already about it: http://bugtracker.makehumancommunity.org/issues/951