eoineoineoin / glTF_Physics

Proposal for adding rigid body dynamics extension to glTF
41 stars 1 forks source link

Triggers detecting objects not in the same glTF file (KHR_interactivity) #35

Open aaronfranke opened 2 months ago

aaronfranke commented 2 months ago

The following is copy-pasted from the KHR_physics_rigid_bodies README, but I auto-formatted it:

| Type                 | `event/rigid_body_triggerEntered` | Trigger entered event                                            |
| -------------------- | --------------------------------- | ---------------------------------------------------------------- |
| Output flow sockets  | `out`                             | The flow to be activated when a rigid body node enters a trigger |
| Configuration        | `int nodeIndex`                   | Index of a trigger node                                          |
| Output value sockets | `int colliderNodeIndex`           | Node index of entering collider                                  |
|                      | `int motionNodeIndex`             | Node index of entering motion (default -1)                       |

This makes sense and would work for triggers detecting when bodies within the same glTF file enter them. However, *NodeIndex can only reference indices of glTF nodes, which leads to these missing use cases:

I would like to be able to use KHR_interactivity to build things like a "teleporter" in a glTF. We would create a teleporter using a KHR_physics_rigid_bodies trigger volume, and then somehow we want to script it so that if an object enters this trigger volume, it teleports that object to another location. Assume that the trigger volume and the destination location are already known in the glTF file. How can the interactivity graph allow objects from other glTF scenes to be teleported, or even non-glTF objects provided by the game engine at runtime, including the player object itself? If a player walks into a glTF teleporter, I expect that a KHR_interactivity graph should be able to detect that, and set the position of the player.

I don't know how this can be done with the current setup, because *NodeIndex can only refer to indices of nodes within a glTF file. Probably the only option here would be a runtime-determined ID for each node in the scene (could just be the memory address), which allows for many glTF files to interact with each other. However, this would then mean that in order to use this value, the KHR_interactivity graph would need a script block (graph node) that can access an object using the same runtime-provided IDs, similar to how object model properties can be accessed using JSON pointers.

I would appreciate your thoughts on how we can allow such a thing to exist. I asked about this on the KHR_interactivity PR, but I did not receive a response: https://github.com/KhronosGroup/glTF/pull/2293#discussion_r1669470586

hybridherbst commented 2 months ago

What I thought about in relation to this is that there could be NodeIndex + FileIndex outputs and inputs. For example, a get/ node could theoretically allow passing in another FileIndex, which previously was received by a rigidbody event. FileIndex could then be "-1" or something else to specify "this is the entire scene graph of the surrounding application and the application" or so.

I'm also not a fan of the strictness of the KHR_interactivity spec in regards to not allowing any data to get in or out in the current iteration...