LPGhatguy
commented
4 hours ago Random thoughts perusing their bindings and comparing them to ours.
Overall, their bindings are more exhaustive and complete. I imagine that's been driven mostly by the needs of JoltPhysicsSharp, which is much more mature than any attempt at bindings to Jolt from Rust.
Primitive layout: we match the size/alignment of Jolt's Vec3 type, their bindings don't worry about that.
When there are lots of optional parameters to a function, like NarrowPhaseQuery::CastShape, I made an argument struct and one variant, while their bindings have multiple overloads.
Their conversion functions in the implementation have a unique method name per type. That's a good idea, we get really horrible compiler errors with our to_jpc/to_jph functions. That was a convention I picked up from the Zig zphysics bindings.
We don't bind to any of the convenience implementations of interfaces like ObjectLayerPairFilter. That's partly because I figure we'll implement those in the higher level language, like Rust or C#.
I didn't bind any of the ShapeSettings types and instead reflected them as C structs. I figured it'd be kinda silly to reflect a bunch of getters and setters to data that's pretty boring, and most of the APIs take a Shape pointer anyways. There might be more APIs that I don't know about that need the settings structs.
I wonder if there are any constraints or patterns that make a set of bindings more or less useful to C#. I wonder if there are any decisions I've made coming from the Rust side that I don't realize.
I see that there are Managed variants to some of the built-in interfaces like ObjectLayerFilter. Are there performance trade-offs here? Are some of these specific to C#, or are we going to hit the same problems from Rust if we only have the FFI-versions of these interfaces?
What kind of constraints are there for changes to their bindings? Are there consumers that would be broken by refactors? Are there language bindings using their bindings besides C# (Lua?)
We don't have any stable consumers, so we can radically change a lot of stuff without concern.
amerkoleci
There's another JoltC binding effort by the JoltPhysicsSharp maintainer, @amerkoleci — joltc! It looks like it was pulled out of the C# binding repo not long ago.
I see that @bjornbytes has contributed, someone that I remember from the LÖVE community way back!
We should evaluate whether we can deduplicate our effort and see if there's anything stopping us from using that for jolt-rust instead of writing new bindings from scratch.