Skip to content
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

Closed
lyuma opened this issue Jul 6, 2023 · 1 comment
Closed

Remove Collision Filtering or migrate to a separate spec #18

lyuma opened this issue Jul 6, 2023 · 1 comment

Comments

@lyuma
Copy link

lyuma commented Jul 6, 2023

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 to collideWithSystems 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.

@eoineoineoin
Copy link
Owner

Closing as "not planned" - group agreed that collision filtering is necessary for common use-cases.

@eoineoineoin eoineoineoin closed this as not planned Won't fix, can't repro, duplicate, stale Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants