Potential invalid fbx or wrong conversion

[Apidcloud]

Hello!

A user uploaded a fbx over the last weekend and it created all sort of problems (see CesiumGS/gltf-pipeline#608 and google/draco#998), including the hanging of the whole server due to a bus error in draco.

I was able to reproduce it with the generated gltf, but now wondering if the original fbx already had issues. I don't know any fbx validator out there. I'm attaching the originally uploaded fbx here, and also the resulting gltf. Could you perhaps check if it is valid to begin with?

To be clear our pipeline is as follows:

• run fbx through fbx2gltf without draco
• run resulting conversion through gltf-pipeline with draco

Fixing the resulting gltf's accessors, as described in the issues makes the problem go away.

Thanks!

broken fbx and resulting gltf.zip

[fire]

I will look as I can, but will be slow, here are my proposed debug steps.

1. take fbx
2. run fbx through fbx2gltf without draco
3. open in vscode's validator for gltf
4. open in blender
5. analyze

[Apidcloud]

Thanks for the prompt reply. The generated gltf contains some NaN errors in the accessor/4 according to the khronos gltf validator. The gltf still opens in blender before and after the conversion to gltf. How can I analyze it in blender? On 14 Apr 2023, at 20:40, K. S. Ernest (iFire) Lee ***@***.***> wrote:  I will look as I can, but will be slow, here are my proposed debug steps. 1. take fbx 2. run fbx through fbx2gltf without draco 3. open in vscode's validator for gltf 4. open in blender 5. analyze — Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA4MM4SMKMQYFY5TEPXGNP3XBGKZ7ANCNFSM6AAAAAAW6X5MMI>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Apidcloud]

javagl from the linked issues imported the fbx to blender and exported it as obj, generating an obj with:

...
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 399274241452221131862835200.000000 -0.000000
vt 0.000000 0.000000
vt -398781418237547907481862144.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 75599770116763773093019648.000000 -0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 456099141423378226263097344.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
...

Might suggest the FBX already contains garbage data and it's not a problem with the fbx conversion.

[fire]

What do you expect to be the proper result?

[Apidcloud]

If the NaN are being created when converting to gltf (which I don’t think so as per the last post) then special handling would make sense here. If not, then it’s purely a Draco issue (and I don’t know what’s the best way to handle it for now, other than using gltf validator). Either way, I think it should be handled by Draco, as it seems to have specific issues with NaN values. I initially opened the issue here to try to determine if the fbx was already invalid. On 23 Apr 2023, at 06:21, K. S. Ernest (iFire) Lee ***@***.***> wrote:  What do you expect to be the proper result? — Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA4MM4QB2WR7335RFFXFKMDXCSU5FANCNFSM6AAAAAAW6X5MMI>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[fire]

Closing due to "don’t know what’s the best way to handle it for now, other than using gltf validator"