Written accessor has empty "max" array breaking .gltf syntax

[BigRoy]

Issue

I'm hitting an export that somehow ends up getting accessors written like this:

{"name":"p202/anim/clip/C","bufferView":2,"byteOffset":447888,"componentType":5126,"count":301,"max":[,,],"min":[1.0,1.0,1.0],"type":"VEC3"}

This particular accessor is for joint animation; the joint/bone being named p202.

In particular note the max value being an array with just commas in the list and no values. This is invalid .json formatting on which I believe .gltf is based, as such I'm assuming this is invalid. Especially because GLTF viewers give parsing errors on those lines.

What could be causing this? Any tips on debugging the source issue? I can't find where this could be coming from.

Other notes

I'm exporting with the following flag: -ivt 300 since my particular animation in this case starts on zero scale on all joints and on 300 it's in the neutral pose for the skinning. Removing the flag or setting a different frame doesn't change anything. All joints in my scene only have keys on scale X, Y, Z and rotate Z. (not sure if relevant)

Unfortunately I can't share the source file currently but I was just wondering what could potentially be causing this.

[ziriax]

This happens when floating point numbers become NaN or Infinite, JSON can't represent these.

I should add a debug flag that checks for the presence of such invalid values, and gives meaningful warnings, but that is not that obvious...

[ziriax]

I think I found a possible reason.

To emulate Maya's segment scale compensation, Maya2glTF needs to output "corrector" nodes.

The /C in the name of the channel p202/anim/clip/C indicates that the problem happens in such a corrector node.

I guess that you have parent joint with zero scale, or some other singular transformation matrix. That would result in a divide by zero.

Could you verify this? This can also cause problems in Maya, since Maya will also compute the inverse parent scale transformation matrix when segment scale compensation is enabled on the joints.

[ziriax]

I've made a test scene that reproduces this problem, in my case I added a key at frame 80 on joint2 with zero scale factors. This triggers the problem. See attached file.

If you don't need segment scale compensation, you can turn it off on each joint. Otherwise, I would recommend not using 0 scales. But maybe your scene has a different problem.

ZeroParentScaleTestAnim.zip

[BigRoy]

If you don't need segment scale compensation, you can turn it off on each joint. Otherwise, I would recommend not using 0 scales. But maybe your scene has a different problem.

As stated originally in my case it needs to scale from zero but also it does not need the segment scale compensate behaviour. I'll double check whether it's disabled on all joints.

Nevertheless it would be great if somehow this error could be reported to the user. I can imagine writing invalid .gltf files is not what is to be expected.

Also, thanks for explaining that the C clip is for the correction of segment scale compensate. Definitely not what I need in my case.

Will give it a go later today to see if disabling segment scale compensate on the joints fixes it.

[BigRoy]

I can confirm that disabling Segment Scale Compensate on the joints in my scene fixes the issue. 💪 I had no clue that the exporter currently allowed to "embed" segment scale compensation so I wouldn't have figured this could've been the issue, so thanks for that!

[fire]

Converting Nan to null seems to be what other json encoders do. Null is not 0.

[ziriax]

But null is not a valid value in glTF either I guess? I was baffled why Maya actually works when you enter zero scales combiner with segment scale compensation... So I debugged it, and it seems to clamp 0 to about 1e-13... cheating IMHO the computer graphics industry has been on a wrong track from the very beginning, by allowing singular transformation matrices, or in matrices in general. Instead we only should have used translation, rotation and reflection (so dual quaternions or more generally, geometric aka Clifford algebra). Scaling is a deformation, just like any of the other deformations, like a lattice, etc..., But I digress. Given the fact that glTF uses 32-bit floats instead of 64-bit doubles, I would introduce numerical instabilities when replacing 0 by a very small float, at least that is what my first tests indicate... Tricky...

…

On Thu, 13 Aug 2020, 09:50 K. S. Ernest (iFire) Lee, < ***@***.***> wrote: Converting Nan to null seems to be what other json encoders do. Null is not 0. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#136 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASHK3YS7Z7MMZ3EKRLF4UDSAOLK3ANCNFSM4P46ZHTQ> .