BVH export: unable to choose coordinate frame #36341

New Issue

inactive account · 2013-08-01T15:01:35+02:00

inactive account commented

2013-08-01 15:01:35 +02:00

Project: Blender Extensions
Tracker: Py Scripts Release
Blender: 2.66
Script name: io_anim_bvh
Wiki page: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/MotionCapture_BVH
Author(s): Campbell Barton
Category: Import Export
Status: Open

%%%The BVH importer allows the conversion from the BVH coordinate frame to Blender's coordinate frame. For example, Blender uses Z=up, whereas a lot of BVH files use Y=up. However, the BVH exporter does not have such a coordinate frame transformation option, and BVH files are always written in Blender's coordinate frame.

The current state of things means that you cannot load a BVH, edit it in Blender, then save it again, while keeping the coordinate frame of the BVH intact (except for the rare case that BVH and Blender share coordinate systems). Please extend the BVH exporter with a coordinate transformation choice, so that this workflow becomes possible.
%%%

**Project**: Blender Extensions **Tracker**: Py Scripts Release **Blender**: 2.66 **Script name**: io_anim_bvh **Wiki page**: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/MotionCapture_BVH **Author(s)**: Campbell Barton **Category**: Import Export **Status**: Open %%%The BVH importer allows the conversion from the BVH coordinate frame to Blender's coordinate frame. For example, Blender uses Z=up, whereas a lot of BVH files use Y=up. However, the BVH exporter does not have such a coordinate frame transformation option, and BVH files are always written in Blender's coordinate frame. The current state of things means that you cannot load a BVH, edit it in Blender, then save it again, while keeping the coordinate frame of the BVH intact (except for the rare case that BVH and Blender share coordinate systems). Please extend the BVH exporter with a coordinate transformation choice, so that this workflow becomes possible. %%%

inactive account commented

2013-08-01 15:01:35 +02:00

Changed status to: 'Open'

Kalpit Thakkar commented

2014-02-17 13:03:01 +01:00

Added subscriber: @dracarys

Leon Eckardt self-assigned this 2015-05-12 11:45:32 +02:00

Leon Eckardt commented

2015-05-12 11:48:14 +02:00

This comment was removed by @Leon95

*This comment was removed by @Leon95*

Leon Eckardt removed their assignment 2015-05-12 11:50:10 +02:00

Campbell Barton was assigned by Leon Eckardt

2015-05-12 11:50:10 +02:00

Leon Eckardt commented

2015-05-12 11:50:10 +02:00

Added subscriber: @Leon95

Leon Eckardt commented

2015-05-12 11:50:36 +02:00

Removed subscriber: @Leon95

Campbell Barton was unassigned by Leon Eckardt

2015-05-12 11:53:48 +02:00

Leon Eckardt self-assigned this 2015-05-12 11:53:48 +02:00

Leon Eckardt commented

2015-05-12 11:53:48 +02:00

Added subscriber: @ideasman42

Leon Eckardt removed their assignment 2015-05-12 12:00:20 +02:00

Campbell Barton was assigned by Leon Eckardt

2015-05-12 12:00:20 +02:00

Leon Eckardt commented

2015-05-12 12:00:20 +02:00

Added subscriber: @Leon95

Leon Eckardt commented

2015-05-12 12:00:20 +02:00

whops wrong task, but is a propsed feature. @ideasman42 is this possible?

Campbell Barton removed their assignment 2015-05-12 12:10:34 +02:00

inactive account was assigned by Campbell Barton

2015-05-12 12:10:34 +02:00

Leon Eckardt commented

2015-05-12 17:48:26 +02:00

Removed subscriber: @Leon95

Jonas H commented

2015-05-21 20:40:44 +02:00

Added subscriber: @duststorm

Jonas H commented

2015-05-21 20:40:44 +02:00

Perhaps it would be good enough to assume that standard BVH files use a Y-up coordinate system.

As mentioned here: http://research.cs.wisc.edu/graphics/Courses/cs-838-1999/Jeff/BVH.html
"the world space is defined as a right handed coordinate system with the Y axis as the world up vector."

Other literature: http://www.dcs.shef.ac.uk/intranet/research/public/resmes/CS0111.pdf
mentions the fact that " problems with the BVH files include the lack of calibration units, such as the scale that the joint offsets are measured in, and the details about the environment, such as orientation -- i.e. which direction points upwards", none the less appears to assume that generally Y-up axis is used. (also all the example data in the paper demonstrates this)

If we look at various sources of mocap data available on the internet, all of them appear to agree on using a Y-up axis system for BVH files.

For example BVH data generated from a Vicon Blade mocap system:
CMU mocap: http://mocap.cs.cmu.edu/
and the MB conversion of those: https://sites.google.com/a/cgspeed.com/cgspeed/motion-capture/cmu-bvh-conversion
ACCAD mocap: http://accad.osu.edu/researchmain/research/motion_lab/system_data.html

BVHacker, a very popular tool for viewing and editing BVH files assumes Y-up.
Also MotionBuilder, one of the most popular tools for authoring mocap data uses a Y-up system.

The default setting for the BVH importer is Y-up, probably for this reason. I think it would be very logical to let the BVH exporter use that same Y-up default as well.

Currently we have the situation that BVH export uses Z-up, and the default setting for the importer is (correctly) Y-up, making a round-trip of exporting a BVH file from blender and importing it again with the default settings fail: the coordinate system is rotated.

I think this is causing more confusion among users than it is useful (orientation corrections can always be done manually in blender). It might not be such a bad idea to remove the up axis option from the importer entirely, and assume Y-up for everything -- both importer and exporter.

Perhaps it would be good enough to assume that standard BVH files use a Y-up coordinate system. As mentioned here: http://research.cs.wisc.edu/graphics/Courses/cs-838-1999/Jeff/BVH.html "the world space is defined as a right handed coordinate system with the Y axis as the world up vector." Other literature: http://www.dcs.shef.ac.uk/intranet/research/public/resmes/CS0111.pdf mentions the fact that " problems with the BVH files include the lack of calibration units, such as the scale that the joint offsets are measured in, and the details about the environment, such as orientation -- i.e. which direction points upwards", none the less appears to assume that generally Y-up axis is used. (also all the example data in the paper demonstrates this) If we look at various sources of mocap data available on the internet, all of them appear to agree on using a Y-up axis system for BVH files. For example BVH data generated from a Vicon Blade mocap system: CMU mocap: http://mocap.cs.cmu.edu/ and the MB conversion of those: https://sites.google.com/a/cgspeed.com/cgspeed/motion-capture/cmu-bvh-conversion ACCAD mocap: http://accad.osu.edu/researchmain/research/motion_lab/system_data.html BVHacker, a very popular tool for viewing and editing BVH files assumes Y-up. Also MotionBuilder, one of the most popular tools for authoring mocap data uses a Y-up system. The default setting for the BVH importer is Y-up, probably for this reason. I think it would be very logical to let the BVH exporter use that same Y-up default as well. Currently we have the situation that BVH export uses Z-up, and the default setting for the importer is (correctly) Y-up, making a round-trip of exporting a BVH file from blender and importing it again with the default settings fail: the coordinate system is rotated. I think this is causing more confusion among users than it is useful (orientation corrections can always be done manually in blender). It might not be such a bad idea to remove the up axis option from the importer entirely, and assume Y-up for everything -- both importer and exporter.

Sign in to join this conversation.