Add physics materials and filtering similar to KHR/MSFT physics

[aaronfranke]

Preview: https://github.com/aaronfranke/gltf-extensions/tree/msft-style-mat-filter/extensions/2.0/OMI_physics_body

These changes add physics materials and filtering very similar to Eoin's Microsoft/KHR physics repo here: https://github.com/eoineoineoin/glTF_Physics

I did not include any example files for these. However, this is not so important because the goal here is alignment with the other spec. Also, these are not easy to implement in Godot Engine, since it uses per-body filtering instead of per-shape (which is worse btw), and its physics materials work differently (worse), so it's difficult to support these features there. For both it can still be done, but not so cleanly, and I haven't had time yet to do it.

As part of alignment, this PR also adds a new "gravityFactor" property to motion. This was discussed as desired and added to MSFT physics a long time ago, but I guess we missed that before now.

I also did some minor formatting changes, such as changing * unordered lists to - to match Khronos style, and reordering properties to match the contents of Eoin's repo.

[eoineoineoin]

Aaron brought my attention to this from a PR in KHR_physics_rigid_bodies and I'd like to drop in a comment to say I'm a little disappointed to see this.

While it's great that this specification is converging on KHR_physics_rigid_bodies, this repo now contains large chunks which have been copied verbatim from KHR_physics_rigid_bodies.

I think having two identical-but-different specifications results in unnecessary user confusion, fragmentation, and interoperability problems, which ultimately hurts users and the glTF ecosystem. I'd ask you to please reconsider where energy is best expended.

[antpb]

Hey @eoineoineoin ! I just want to be clear that our efforts here are not in an attempt to be a KHR spec or conflict with one, we are experimenting within the OMI vendor extension and aligning on the needs we have in our implementations. While, it is nice whenever an extension we rally behind works for wider groups and can be ratified at the KHR level, it is not our focus. I don't think its fair to ask that we reconsider working on this. We work within the OMI space to move fast and learn from implementations of our specs.

[yankscally]

OK, so, I'm working on this blender level editor addon, bless. I use OMI extensions for physics for the level geometry.

I am well up to scratch with OMI_physics_body so any new changes are obvious to me, and I read through the collision filters and physics materials here. On a technical level its all sound, and I would be happy using this.

About collision filters and physics materials being in the body extension: I am quite torn, they are good ideas to have them as accessible data, but one or both could be a separate extension. They both have busy systems, and they are both optional in many cases. They both also hold lots of complex data also. These days I'm really against super monolithic extensions like KHR_interactivity.

Modular components seem way more attractive. What if you want collision filters and physics materials without the body for some reason?
I disagree with MSFT decision to have these properties in the body extension anyway. I made a issue over there in that repository.

For the sake of progress, I agree with and approve of this review, but I would like to keep working and perfecting the physics extensions to make them more modular and well-rounded for all applications.