Fbx animation/skeleton exported in a Z up, right hand coodinate space is yeilding Y results

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a single joint animation moving up and down on Z in 3ds max
2. Export fbx with Z-up Up Axis conversion
3. Process animation and skeleton with fbx2skel and fbx2anim

When played back, the animation moves along the Y axis instead of Z. Maybe 
desired up-axis should be a commandline option?

Version: 0.7.2

Original issue reported on code.google.com by kyle.ro...@gmail.com on 27 Jul 2015 at 5:49

[GoogleCodeExporter]

Thanks for posting this issue and providing the details.

"...the animation moves along the Y axis instead of Z".

Ozz coordinate system being y-up right-handed, it looks correct to me that an 
animation moving along the "up" in any source coordinate system, moves along Y 
once in ozz. At least that's what i'd expect, don't you?

Maybe your coordinate system isn't the same as ozz? In this case Y might not be 
"up", causing you an issue. What coordinate system convention do you use? In 
case it´s not the same, I can see 2 solutions:

1. As you suggested, the output coordinate system could be provided as an 
argument to ozz offline tools. For fbx the change would be in there: 
http://code.google.com/p/ozz-animation/source/browse/src/animation/offline/fbx/f
bx_base.cc. I'd need to double check the implication of adding this feature to 
the rest of the libraries though (especially maths and samples) before 
committing on implementing it. Also I'd need to find a way to properly test 
every source and destination coordinate system combination.
2. You could multiply ozz skeleton root matrix with a matrix that does the 
coordinate system transformation you need to go from ozz to your system. This 
should be done before converting joint transformations to model-space of 
course. It might not be ideal but it should work, as it's the way fbx sdk is 
handling coordinate system transformations internally.

In any case I'll look at option 1 implementation, but it might take some time.

Original comment by guillaum...@gmail.com on 29 Jul 2015 at 6:17

[GoogleCodeExporter]

Ya you're right we are using a different coordinate system, we're z-up 
right-handed +parity-odd (man fbx makes that weird). So you're right this isn't 
really a defect but rather a feature request.

Since posting this issue, I've been working to find a solution. As it turns out 
it was trivial to get fbx2anim/skel to export to our coordinate system. 
Playback, blending and local-model jobs all seem to run and work out just fine. 
(In our limited usecase anyway). You've made it quite easy to get this to work 
as BuildAxisSystemMatrix() is all you need to change. Certainly it'll be a 
bigger job to robustly support all combinations but in the mean time we have an 
sensible option.

As an aside, this is a great little package you've been working on here. So 
many little details done exactly the way they should.

Thanks!

/ Kyle

Original comment by kyle.ro...@gmail.com on 29 Jul 2015 at 7:18

[GoogleCodeExporter]

Good to hear you have it working this way, it's a good sign for the 
implementation of this feature. Please tell me if you have any issue with a 
function from ozz that doesn't behave right with your coordinate system.

And thanks for your feedback, I appreciate and I'm happy to see this work being 
used...

Original comment by guillaum...@gmail.com on 29 Jul 2015 at 8:24

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect