You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When targeting a rotation, spherical linear interpolation (slerp) SHOULD be used to interpolate quaternions
I assume this is no hard requirement (not a "MUST") in order to not exclude animation systems that interpolate quaternions via N-LERP (component-wise LERP). N-LERP does not give the same result, but might be close enough while requiring less computation.
However, most SLERP implementations handle cases where the angle between the two quaternions is not the shortest path (so bigger than 180 degrees) gracefully by calculating the shortest-path (see this post). N-LERP will fail miserably in that case and create ugly glitches (e.g. this issue).
The solution is to properly re-calculate (flip) adjacent rotations where this occurs, which can be done either at the export/generation of the glTF or at run-time.
Depending on the preferred solution the specification should
Clarify that exporters are required to make sure adjacent rotations have an angle of 180 degree or lower
Recommend (non-normative) that importers have to take care of calculating/certifying the shortest-path interpolation in their SLERP/N-LERP implementations.
I'd personally prefer if this is required upon export (since the T in glTF stands for transmission and run-time overhead should be kept at a minimum), but I recognize this might be a breaking change for the spec.
Thanks for considering!
P.S.:
Exporters I observed to not make sure rotations are shortest-path (by checking the asset->generator property):
babylon.js glTF exporter for Autodesk Maya 2020.4 v20210811.2 as well as v20210615.1
Khronos glTF Blender I/O v1.6.16
The text was updated successfully, but these errors were encountered:
The specification says the following about
LINEAR
quaternion interpolation:I assume this is no hard requirement (not a "MUST") in order to not exclude animation systems that interpolate quaternions via N-LERP (component-wise LERP). N-LERP does not give the same result, but might be close enough while requiring less computation.
However, most SLERP implementations handle cases where the angle between the two quaternions is not the shortest path (so bigger than 180 degrees) gracefully by calculating the shortest-path (see this post). N-LERP will fail miserably in that case and create ugly glitches (e.g. this issue).
The solution is to properly re-calculate (flip) adjacent rotations where this occurs, which can be done either at the export/generation of the glTF or at run-time.
Depending on the preferred solution the specification should
I'd personally prefer if this is required upon export (since the T in glTF stands for transmission and run-time overhead should be kept at a minimum), but I recognize this might be a breaking change for the spec.
Thanks for considering!
P.S.:
Exporters I observed to not make sure rotations are shortest-path (by checking the
asset
->generator
property):babylon.js glTF exporter for Autodesk Maya 2020.4 v20210811.2
as well asv20210615.1
Khronos glTF Blender I/O v1.6.16
The text was updated successfully, but these errors were encountered: