Open GoogleCodeExporter opened 8 years ago
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
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
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
Original issue reported on code.google.com by
kyle.ro...@gmail.com
on 27 Jul 2015 at 5:49