Khronos glTF physics specification

Discuss topics related to BEPUphysics or physics engine development.
Post Reply
Posts: 2
Joined: Mon Aug 22, 2016 10:12 am

Khronos glTF physics specification

Post by vicviper » Fri Dec 01, 2017 9:46 pm

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:

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


Site Admin
Posts: 4928
Joined: Tue Jul 04, 2006 4:45 am

Re: Khronos glTF physics specification

Post by Norbo » Sat Dec 02, 2017 3:18 am

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.

Post Reply