Add cube and light visibility test models for KHR_node_visibility

[aaronfranke]

This model demonstrates the KHR_node_visibility extension and its interaction with KHR_animation_pointer.

• If your implementation shows either of the red cubes, it is not compliant with KHR_node_visibility.

• If your implementation does not have the blue cube hiding and showing every 0.5 seconds, either the animation is not playing, or it does not support using KHR_animation_pointer to animate the KHR_node_visibility visible property.

Animated screenshot of the test model in action:

---

The other model demonstrates the same but with lights.

• If your implementation shows either of the red spotlights, it is not compliant with KHR_node_visibility.

• If your implementation does not have the blue spotlight hiding and showing every 0.5 seconds, either the animation is not playing, or it does not support using KHR_animation_pointer to animate the KHR_node_visibility visible property.

---

Note: These 6 Godot PRs are required to fully fix this test asset in Godot:

• Tracker: [TRACKER] Fixes for KHR_node_visibility godotengine/godot#111618
• GLTF: Support animating node visibility godotengine/godot#111341
• GLTF: Enforce STEP interpolation for integer and boolean animations godotengine/godot#111615
• GLTF: Move accessor and buffer view Dictionary conversion into those classes godotengine/godot#108320
  • GLTF: Move accessor encoding functions to GLTFAccessor godotengine/godot#108853
    • GLTF: Write integer min/max for integer accessors godotengine/godot#111612
    • GLTF: Determine the component type when encoding object model properties godotengine/godot#111613

[robertdorn83]

hey aaron!
Can you please change the "gltf-Text" to just "glTF" to match gltf sample models names?

[hybridherbst]

@aaronfranke is it intended that the value animation does not use CONSTANT interpolation at the moment?

[hybridherbst]

Looks better now 👍

[UX3D-haertl]

Currently, the animations in the test assets are not valid.
They point to /nodes/3/extensions/KHR_node_visibility/visible and /nodes/5/extensions/KHR_node_visibility/visible but the KHR_node_visibility object does not exist in the nodes.

From the spec:

The JSON Pointer MUST point to a property defined in the asset. A property is considered defined if it is present in the asset explicitly or if it has a default value and its enclosing object is present.

A minor note:
The light intensity could be a bit higher. The lights are hardly visible with the default HDR enabled in sample viewer. (With disabled IBL or a darker HDR this is obviously not an issue)

[hybridherbst]

I believe we discussed in the WG that it is actually not required that nodes have the extension to be animatable with visible, but I'm not sure if I remember correctly or if its written down somewhere. @lexaknyazev could you clarify please if it stays like mentioned in the spec comment above, and having the extension is required for both interactivity and animation_pointer to be able to modify the "visible" value?

[lexaknyazev]

The visible property itself can be omitted because it has a schema-default value but the extension object must be present for the pointer to be resolvable (as mentioned in the Object Model document).

[aaronfranke]

Updated the PR to include the explicit visible property on the animated objects. I also cleaned up the test assets in several other ways, like not saving empty materials, so the JSON looks clean. The only remaining validator note from the VS Code extension is "Cannot validate an extension as it is not supported by the validator: 'KHR_node_visibility'." which will require an update to the validator to fix.

[robertdorn83]

@lexaknyazev would the visibility extension on a node also be required when a interactivity graph can change the visibility? Because with the readonly pointers we can now access the childs and parents of nodes dynamic on "runtime" and a graph has the possibility to access every node of a gltf file . So we can't know for sure on exporting such graph which node will be have changed visibility on runtime. So we would need to add the visibility extension on EACH node on export as soon as we have a pointer/set visibility with dynamic index in the graph.

[lexaknyazev]

@robertdorn83 The interactivity extension does not have any special cases wrt node visibility pointers so they follow the generic Object Model language, which requires all such pointers to be statically resolvable. Therefore, an asset that for some reason wants to be able to toggle every node's visibility would need to have the extension object added to every node.

There are two possible alternatives that may or may not be better:

1. Pretend that all possible pointers are always resolvable for interactivity purposes. This would imply that pointer operations on something like /materials/1/pbrMetallicRoughness/baseColorTexture/extensions/KHR_texture_transform/offset must succeed even if the base color texture does not have a texture transform extension. This could be problematic for engines that do not include texture transform properties in their shaders for textures that do not use transform properties statically. Same could be said about almost any material extension that may require recreating render pipelines to support previously unused properties.
2. Another option could be to add additional language to the interactivity extension saying that visibility pointers are somehow special and if the visibility extension is used, then visibility extension objects are implicitly added to all nodes. This approach does not seem to scale well because similar logic may later apply to selectability/hoverability/etc thus creating a complex compatibility matrix.

[aaronfranke]

I wonder if an alternative requirement that satisfies the first problem would be to require that extensions are added to "extensionsRequired" if the interactivity graph requires it. So for example if KHR_texture_transform is required, this ensures the interactivity graph only loads when a runtime supports KHR_texture_transform.

[lexaknyazev]

So for example if KHR_texture_transform is required, this ensures the interactivity graph only loads when a runtime supports KHR_texture_transform.

Optional extension support is not an issue here because unresolvable pointers would simply activate err flows instead of out so a graph can decide what to do based on that.

The root cause is that an engine may make strong assumptions based on the static asset state and such assumptions may be hard to change mid-execution. For example if an asset does not statically use texture transform properties on a particular texture slot, an engine may be unable to set such properties dynamically without heavy reloads. This becomes even more complicated with material properties that would require switching to multi-pass pipelines, e.g., anything related to transmission.

[robertdorn83]

or maybe we extend the KHR_node_visibility extension that it also can be added to the "scene"? (but without a "visible" property). Maybe also usefull for Hoverability and Selectability ?
So when the scene root has this extension, all nodes in there can be resolved with the visibility pointer.
The solution to add to each node the visibilty extension would inflate the gltf file unnecessary.

[lexaknyazev]

So when the scene root has this extension, all nodes in there can be resolved with the visibility pointer.

That would be an even more special case than doing the same implicitly when interactivity is used.

The solution to add to each node the visibilty extension would inflate the gltf file unnecessary.

What's the practical use case for arbitrarily toggling every node?

[robertdorn83]

the use case? i don't know... it's a designer/authoring possibility with interactivity. :D

[UX3D-haertl]

From an implementation point of view, while I understand that needing the parent object is not as flexible, it solves a lot of issues which otherwise would need to be handled:

1. You could have pointers to non-existing root objects. Some of them e.g. materials can be default initialized.
2. There are objects which change behavior in glTF just by existing, e.g. KHR_materials_unlit
3. Some extensions are not compatible with other extensions
4. There are objects which can not be default initialized, e.g. orthographic and perspective objects in camera, textureInfo
5. Like Alexey said, rendering engine might make assumption about render passes, uniforms and shader selection based on the existence of objects in glTF
6. All these special cases would need to be manually handled in interactivity and animation pointer. With the current spec one can use a generic implementation. Follow the JSON pointer and you can get and set the value. If the parent objects does not exist, the getter and setter logic would need to know which objects in the JSON path they need to create with defaults (and which can not be created) and resolve this for each possibility separately.
7. This operation modifies the glTF structure of the file, and there is currently no way in the Object Model to remove created objects again.

[robertdorn83]

so this file can now be merged? :) or is there some changes planned?

[aaronfranke]

@robertdorn83 It needs an approval from @lexaknyazev but as far as I know I've fixed all of the remaining issues.

[aaronfranke]

Closing as superseded by KhronosGroup/glTF-Sample-Assets#235