There are a few issues in the specification repository that point out corner cases and ambiguities, and that are supposed to be resolved with an upcoming 2.0.x release of the specification. The following are a few test models that are supposed to serve as test cases here.
This revolves around animations that affect morph targets, and which restrictions these animations should or should not imply. For details, refer to the issue. The following is a test asset that was already posted in an issue comment. It is the SimpleMorph asset, containing a simple morphed and animated mesh primitive, but modified so that the mesh is attached to a node that contains a matrix:
SimpleMorphWithMatrix.gltf.txt
This works in three.js and Babylon.js.
Additional test cases are TBD.
The following is essentially also the SimpleMorph, but with two mesh primitives, once without the morph targets, and once with the morph targets:
PartiallyMorphedPrimitives.gltf.txt
This seems to work in three.js and Babylon.js. (The validator reports an error, but that is tracked independently).
Aside: There seems to be a strange flicker in Babylon.js, where the primitive goes into its unmorphed state for 1 frame, but that also appears in the SimpleMorph, and is therefore probably unrelated:
This is the most tricky one. The behavior for cameras when non-uniform, negative, or zero scales are involved is not entirely clear. And there are many possible configurations that may have to be tested. I tried to cover some of them in the following asset:
CameraTransformsTest.gltf.txt
The asset contains a unit cube and a camera pointing at that cube. The node that the camera is attached to is:
- node0: Move camera to view the cube
- node1: Animated scale (details below)
- node2: Rotation about 45 degrees around the z-axis
The scale property of node1 is animated. Each animation starts at (1,1,1), goes to the 'special value', remains there for 1 second, and goes back to (1,1,1).
Constant: The default animation that is played by most viewers, without a 'special value' (i.e. a constant (1,1,1) scale)WithZero: The 'special value' is (0,0,0)WithNegative: The 'special value' is (-1,-1,-1)NonUniform: The 'special value' is (1,2,1)NonUniformNegative: The 'special value' is (1,-2,1)
Both three.js and Babylon.js don't "properly" display all of them. For example, both viewers don't animate the one that goes to (0,0,0) - the cube simply disappears for a moment. The NonUniform one seems to work, with the caveat that the viewers differ in their treatment of the camera on a much lower level: three.js takes the aspect ratio from the window, whereas Babylon.js uses the aspect ratio from the camera. (Related to KhronosGroup/glTF#2217 and already mentioned in KhronosGroup/glTF#1822 ). The NonUniformNegative looks pretty fancy in both of them. Looks like some relativistic effect of crossing the event horizon of a black hole or something. But in any case, the "right" behavior still has to be defined here.
There are a few issues in the specification repository that point out corner cases and ambiguities, and that are supposed to be resolved with an upcoming 2.0.x release of the specification. The following are a few test models that are supposed to serve as test cases here.
About Clarify restrictions for nodes with a defined matrix:
This revolves around animations that affect morph targets, and which restrictions these animations should or should not imply. For details, refer to the issue. The following is a test asset that was already posted in an issue comment. It is the
SimpleMorphasset, containing a simple morphed and animated mesh primitive, but modified so that the mesh is attached to a node that contains amatrix:SimpleMorphWithMatrix.gltf.txt
This works in three.js and Babylon.js.
Additional test cases are TBD.
About Clarify mixing morphed and non-morphed primitives:
The following is essentially also the
SimpleMorph, but with two mesh primitives, once without the morph targets, and once with the morph targets:PartiallyMorphedPrimitives.gltf.txt
This seems to work in three.js and Babylon.js. (The validator reports an error, but that is tracked independently).
Aside: There seems to be a strange flicker in Babylon.js, where the primitive goes into its unmorphed state for 1 frame, but that also appears in the
SimpleMorph, and is therefore probably unrelated:About TRS decomposition with negative scale makes camera matrix non-unique:
This is the most tricky one. The behavior for cameras when non-uniform, negative, or zero scales are involved is not entirely clear. And there are many possible configurations that may have to be tested. I tried to cover some of them in the following asset:
CameraTransformsTest.gltf.txt
The asset contains a unit cube and a camera pointing at that cube. The node that the camera is attached to is:
The
scaleproperty ofnode1is animated. Each animation starts at (1,1,1), goes to the 'special value', remains there for 1 second, and goes back to (1,1,1).Constant: The default animation that is played by most viewers, without a 'special value' (i.e. a constant (1,1,1) scale)WithZero: The 'special value' is (0,0,0)WithNegative: The 'special value' is (-1,-1,-1)NonUniform: The 'special value' is (1,2,1)NonUniformNegative: The 'special value' is (1,-2,1)Both three.js and Babylon.js don't "properly" display all of them. For example, both viewers don't animate the one that goes to (0,0,0) - the cube simply disappears for a moment. The
NonUniformone seems to work, with the caveat that the viewers differ in their treatment of the camera on a much lower level: three.js takes the aspect ratio from the window, whereas Babylon.js uses the aspect ratio from the camera. (Related to KhronosGroup/glTF#2217 and already mentioned in KhronosGroup/glTF#1822 ). TheNonUniformNegativelooks pretty fancy in both of them. Looks like some relativistic effect of crossing the event horizon of a black hole or something. But in any case, the "right" behavior still has to be defined here.