search

ColinGilbert / ozz-animation

Automatically exported from code.google.com/p/ozz-animation
zlib License
0 stars 0 forks source link

Sample_Skin not working with FBX Example model #5

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Steps to reproduce error:

1) I got a new cut of the source code (version 0.7.1) and tried using the 
fbx2skel, fbx2anim and sample_skin_fbx2skin executables on the example FBX 
provided with FBX SDK (Humanoid.fbx).

2) I replaced the .ozz files in the sample_skin example with the ones I had 
just created. 

3) Observe the mesh is not displayed how it should. I have attached a 
screenshot of this.

Further information:
The commands I used in conversion are as follows:

fbx2skel.exe --file=humanoid.fbx --skeleton=humanoid_skel.ozz
fbx2anim.exe --file=humanoid.fbx --skeleton=humanoid_skel.ozz 
--animation=humanoid_anim.ozz
sample_skin_fbx2skin.exe --file=humanoid.fbx --skeleton=humanoid_skel.ozz 
--skin=humanoid_mesh.ozz

Original issue reported on code.google.com by ThomasBu...@gmail.com on 28 Dec 2014 at 10:47

Attachments:

GoogleCodeExporter commented 9 years ago 
I managed to reproduce the issue indeed.
In my attached screenshot I display the skeleton and the mesh skinned with the 
bind-pose. Skinning is ok, but the bind-pose looks wrong, should be more like a 
T-pose with no position offset. I'll investigate that.

In the meantime you can try rendering the animated skeleton by calling:

_renderer->DrawPosture(skeleton_, models_, ozz::math::Float4x4::identity());

Thanks for posting.

Original comment by guillaum...@gmail.com on 29 Dec 2014 at 11:05

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by guillaum...@gmail.com on 29 Dec 2014 at 11:06

GoogleCodeExporter commented 9 years ago 
I can now confirm that this is a bind-pose issue.

Skinning sample computes inverse bind-pose matrices (used by the skinning job) 
based on the skeleton bind-pose. Skeleton bind-pose is extracted by fbx2skel 
tool, which uses the first frame of the default take (Fbx animation) as 
bind-pose.

In the case of Humanoid.fbx, the default take is not the expected bind-pose. To 
use current ozz pipeline, you'd need to have another fbx file to use with 
fbx2skel, where the skeleton would be in bind-pose (or T-pose), or modify 
Humanoid.fbx to set the T-pose as the default take. This is a solution many 
pipelines use, but it's not the most robust.

Another option is to extract the bind-pose from the FbxMesh. For each set of 
vertices that are affected by skinning, Fbx stores the "global initial position 
of the link node" in each FbxCluster. This is the transformation of joints used 
during skinning setup, aka the bind-pose. This option works well, as shown in 
the attached screen shot. Its drawback is that the bind-pose of joints that 
aren't transforming any vertex are not available (which would be required to 
build the whole skeleton bind-pose).

The final implementation I'm working on stores inverse bind-pose matrices, 
extracted from FbxMesh clusters, in the ozz::sample::Mesh directly. Skeleton 
bind-pose would remain though, but would be more like a rest-pose. It's a bit 
more memory consuming (1 matrix per joint), but it's 100% robust. Also another 
benefit is that meshes with different bind-poses could be still use the same 
skeleton.

Original comment by guillaum...@gmail.com on 10 Jan 2015 at 11:19

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by guillaum...@gmail.com on 10 Jan 2015 at 11:19

GoogleCodeExporter commented 9 years ago 
Ah, I understand. Unfortunately Animation was the *one* topic not covered on my 
University games programming course - from your post it sounds like you're 
leaning towards the third solution and with my limited knowledge I would be 
inclided to agree it does sound by far the most robust. Especially regarding 
skeleton re-use. I have a feeling I would need to change my existing code to 
work with the changes but it would definitely be worth it. Excited for the 
update. Thanks.

Original comment by ThomasBu...@gmail.com on 11 Jan 2015 at 1:48

GoogleCodeExporter commented 9 years ago 
I don't plan any change in ozz interface, only in Fbx tools implementation 
(greater robustness) and skinning sample (to use mesh inverse bind-pose instead 
of computing them from the skeleton). So I hope and expect the impact should be 
minor on your existing code.

Thanks for posting.

Original comment by guillaum...@gmail.com on 11 Jan 2015 at 2:37

GoogleCodeExporter commented 9 years ago 
Fixed in bindpose branch. Will be pushed in the next release.

Original comment by guillaum...@gmail.com on 25 Jan 2015 at 9:56

GoogleCodeExporter commented 9 years ago

Original comment by guillaum...@gmail.com on 25 Jan 2015 at 9:57

GoogleCodeExporter commented 9 years ago 
Fixed on version 0.7.2.

Original comment by guillaum...@gmail.com on 19 Feb 2015 at 10:05