KHR_nodes_disable extension

[UX3D-nopper]

No description provided.

[rsahlin]

I would suggest to use a direct hiearachy approach and mandate that if a node (parent) is disabled then all children are disabled.
Ie, render traversal stops at the first Node that is disabled.
If this is not the intended behavior I suggest to add a disable property to the Mesh.

[rsahlin]

USD has a similar solution for pruning of visible primitives (geometry)
A node will either have the value inherited or invisible.

Where invisible is always invisible and inherited will compute the visibility value for the parent.
In effect this will turn off all children when a node is hidden (by calling MakeInvisible)
The value is also animatable.

https://graphics.pixar.com/usd/docs/api/class_usd_geom_imageable.html#aa0dfa061a65be443436288f7406ba3db

[UX3D-nopper]

Think we should just make it the same behaviour.

[rsahlin]

Hi @UX3D-nopper and thanks for creating the PR

I have a feeling that this is more of a runtime property than transmission property.
As I read the usecase in the proposal - the solution I see is a method in the viewer to disable/enable rendering of mesh(es). Not necesarily an addition to the glTF scenegraph.

I see the data needed to toggle nodes as configuration data and not part of glTF.

The glTF usecase I see for toggling visibility would be to add support for an animation that affects node visibility (disable/enable flag)
That way the model could be queried for animation (state) and use that information to know what parts are visible or removed - by means of configuration logic.

[edzis]

To share context with people outside the 3D Commerce working group, here is what I said in the email thread:

---

I fully support the need to solve visibility that Norbert is tackling. I also agree that nodes seem to be the best target for that. I also believe this can be useful beyond Configurability as a means to hand over assets between artists without needing to show everything.

But I believe that to make this relevant for Configurability this extension needs to have a dynamic nature beyond just specifying the visibility value at authoring time.

I fully support Paul's comment on enabled/disabled. In our configurators using Babylonjs we use setEnabled() instead if isVisible because of the same implementation details that Paul mentioned. Also, that naming would match better with other things besides meshes - cameras, groups, etc.

On top of that I want to make sure this is easy to use in scenarios of multiple Properties affect visibility for sections of the node graph at different levels of depth.

Considering both of these threads I recommend calling this extension KHR_disable_node which is recursive by nature. That would turn off any nested children as soon as a node is disabled.

I believe that makes the mental model simple, intuitively communicating that a child node with disabled not active would still not be visible as soon as one of it's ancestors is disabled.

Also, instead of just specifying the disabled value statically:

"KHR_disable_nodes": {
  "disabled": true
}

... I recommend to add ability to connect that to the same system of tags that would be used for material variants.

We might disable something based on any of the tags being set:

"KHR_disable_node": {
  "whenTag": ["faceguard:none", "faceguard:padLeft", "faceguard:mask"]
}

... or, if we don't want to list all the negative tags, keep something disabled unless a specific tag is set:

"KHR_disable_node": {
  "unlessTag": ["faceguard:padRight"]
}

[mixtur]

I was looking for something like that. #80 seems to be somewhat related

We have a concept of "views" in our app. A view is a camera plus a set of nodes to render.

So my suggestion would be to allow adding some kind of "visibility tag" to nodes and also cameras. This seems similar to what @edzis suggested. Although I am not entirely sure how it must affect subtrees. I think it is a point of controversy, different people may have very different ideas about it. Maybe the behavior there should be either more flexible or more restrictive.

More flexible would be to add an option that defines how the subtree is affected.
More restrictive for example would be only allowing the extension on leaf nodes. Which is almost the same as attaching the extension to meshes instead of nodes.

I personally don't like the "flexible" option, I have seen this in another format and it was very hard to figure what is visible and what is not there. But businesses may require crazy things)

UPD: only allowing it for leaf nodes won't work because a node may have both mesh and children.

[bhouston]

Many engines do not support non-recursive behavior, so it can be a lot of work to implement. I personally would suggest we do not support non-recursive behavior.

[bhouston]

The reason why it is hard to support is that if the engine does not support recursive visibility, you need to add new nodes for the main hierarchy with meshes as child nodes. But this screws up trying to do animations, etc, because now there is additional nodes.

[aaronfranke]

This PR is superseded by KHR_node_visibility, so this PR can be closed.

The key difference is that KHR_nodes_disable allows recursive and non-recursive visibility, while KHR_node_visibility only has a single property for visibility and is always recursive. As discussed above and pointed out by @bhouston, the non-recursive behavior is not desired, so we only want the recursive behavior, which is what KHR_node_visibility does.