I couldn't resist to point out to this:
Currently, Khronos is in the process of defining a specification for physics engines to be stored in the glTF file format.
The discussion is being followed here: https://github.com/KhronosGroup/glTF/issues/1135
It could be convenient if you could follow up or even contribute. Just to keep track if the resulting specification happens to be compatible (or not) with bepuPhysics
Cheers!
Khronos glTF physics specification
Re: Khronos glTF physics specification
As far as compatibility goes, it looks like there aren't any blocking issues. Some of the fields are a little overspecific as far as bepuphysics is concerned but not in a problematic way. For example, while there is no single conceptual entity in bepuphysics (1 or 2) which is both a ball socket joint and a set of angular limits, a combination of constraints could be constructed that does the same thing.
Collision filtering, damping, and materials are another set of areas where there's a bit of mismatch. v2 doesn't actually prescribe any specific form of collision filtering, damping, or shape-stored material- there are just some callbacks that let the user do whatever they want. And here again, something compatible could be created, so it's not a big issue.
I'm hesitant to make any strong claims about what how the format should look, though. This kind of broad format is a long series of compromises between generality and arbitrariness for the sake of convenience, and I don't have much special insight into the tradeoffs that most users would prefer. I'll keep an eye on it and jump in if I see anything important, but my guess is I won't need to.
Collision filtering, damping, and materials are another set of areas where there's a bit of mismatch. v2 doesn't actually prescribe any specific form of collision filtering, damping, or shape-stored material- there are just some callbacks that let the user do whatever they want. And here again, something compatible could be created, so it's not a big issue.
I'm hesitant to make any strong claims about what how the format should look, though. This kind of broad format is a long series of compromises between generality and arbitrariness for the sake of convenience, and I don't have much special insight into the tradeoffs that most users would prefer. I'll keep an eye on it and jump in if I see anything important, but my guess is I won't need to.