-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Collision Filtering or migrate to a separate spec #18
Comments
Closing as "not planned" - group agreed that collision filtering is necessary for common use-cases. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've been working with OMI on their physics extension, which does not contain collision filtering. As a potential implementer for Godot Engine, I have concerns about the architecture of this feature.
I do not see how Collision Filtering can be cleanly implemented using features built-into game engines.
Many engines have only at most 32 layers, with several layers possibly reserved by the application or engine functionality.
Some engines do not permit an object to be contained in multiple layers at once.
Some engines do not have the concept of per-object collision masks. For example, in the case of Unity these masks are per-layer project settings so they cannot be trivially changed per scene.
In short, either this part of the spec will be ignored by most implementations, or the spec will mandate significant runtime overhead for every collider with filtering enabled, since it is too complex to implement this spec using the layer features that various physics engines have built-in.
For this reason, I would prefer that Collision Filtering be moved into a separate extension or removed for now.
In the future or if it's deemed necessary, I might also be open to a really simple layer-based approach which takes a small, fixed number of layers to implement. I'd need to see tangible examples of scenes that require the complex filtering, but my guess is a combination of numbered collision layers and joints to attach collision primitives between layers ought to be sufficient if more complex interactions are expected.
Side note: the section about transforming
notColliderWithSystems
tocollideWithSystems
does not specify the behavior when multiple scenes are loaded: "Note, given knowledge of all the systems in a scene"... it's quite common for applications to load multiple glTF scenes at once (this fact is the very reason for the existence of draft specs such as glXF, or glTF support in USD), so there will not be global knowledge within a single file of all possible collision systems.The text was updated successfully, but these errors were encountered: