Aaron Franke

> (in particular, the restrictions on document structure that OMI_physics_body imposes) I have opened a PR to start the discussion to change this: https://github.com/omigroup/gltf-extensions/pull/169 I am still skeptical of the...

> So, the defining characteristic of a "kinematic" body describes one which will pass through static geometry. @eoineoineoin I apologize for the confusion before, I have discussed this with many...

For triggers: I will break it down. > Here's the rationale. For a trigger, they can't make use of a material - it just does not make sense to add...

> "triggerness" is a property of how an object responds to collision; "kinematicness" describes of the motion of the object. They are orthogonal properties. You can have a static or...

> This is wrong. Application or game code can apply forces to dynamic triggers. Joints can apply forces to dynamic triggers. Non-trigger shapes attached to the same dynamic body can...

> No. That's not 2 bodies. Adding an additional body adds six degrees of freedom Those degrees of freedom can just not be set. > Exactly the same way you...

@eoineoineoin Do you have any further objections to the OMI physics standards relating to anything that's impossible to do? To me this is the simplest approach that makes every desired...

@eoineoineoin It's possible that I am misunderstanding something, your specs are unclear and in disagreement with the example files. The [example files](https://github.com/eoineoineoin/glTF_Physics/tree/master/samples) have data like this (inside `"MSFT_physics"`): ```json "name":...

@ryanabx No, only abstract classes are supported with this PR.

I will get to work on 1. For 2, this is trivial because it's just removing `#ifdef DEBUG_ENABLED`. To be clear I don't mind it in release builds, I just...