KK Physics and Jolt JNI

User Code & Projects
82

Jolt JNI isn’t quite production-ready. As often happens, I discovered rough spots and gaps while writing tutorials. However, a v0.9.9 has been released, and I estimate v1.0.0 is less than a month away.

KK Physics remains a long way from being production-ready. It’s still a prototype, and I may abandon it entirely. If I do, I’ll probably launch a less-ambitious project to simplify using Jolt JNI with JMonkeyEngine. (JME projects can already use Jolt JNI directly; it’s just a tad inconvenient.)

Up till now, I haven’t had any difficulty getting 3rd-party libraries added to the JMonkeyEngine SDK. However, I’m not directly involved in the SDK, and I can’t predict its releases.

5 Likes
83

SDK uses Minie now and there are no plans to change that. But in your application you can use whatever library you please.

2 Likes
84

Thanks !!
Just make some tutorials so, it will be easy to use for people like me. its ok if you are completely stop working on KK physics.
No problem !!

1 Like
85

The Jolt-JNI tutorial is about 50% done, with pages on rigid and soft bodies, constraints, characters, and vehicles, but nothing yet on collision queries or ragdolls or performance tuning. I plan to continue improving the tutorial, but not very intensely.

I’ve begun pointing links at the tutorial website instead of the GitHub project.

Writing sample apps for the tutorial has boosted my confidence in the library. I’ve frozen the API and released a production version: v1.0.0.

9 Likes
86

Nice. Thanks for your efforts !!

1 Like
87

With Jolt JNI v1.0 in the jar, I’ve been thinking more about integrating Jolt Physics into JMonkeyEngine.

First, I’m having second thoughts about the name “KK Physics”. It’s short, creative, and easy to remember. However, “jme3-jolt” would be more self-explanatory.

More importantly, a lot of code needs to be written to make Jolt JNI convenient for use in “real games” as opposed to sample apps, performance tests, and demos:

  • Integrate physics into game assets at runtime. This implies:
    • standard scene-graph controls to associate spatials with physics objects such as bodies, characters, vehicles, and ragdolls
    • debug visualization. For this, I envision an AppState with access to both the PhysicsSystem and also any ragdolls and bodyless virtual characters.
  • Integrate physics into game assets prior to runtime. This implies:
    • generating shape settings, rag-doll settings, and/or soft-body settings from scene-graph subtrees
    • The physics scene-graph controls should implement both Savable and JmeClonable. This implies the settings objects should also implement those interfaces.

Serialization is tricky to do correctly, that is to say, with portability between platforms and to future software releases. For instance, Bullet implements serialization at the native level, but Minie doesn’t use Bullet serialization except in one case, where it has caused a lot of trouble.

If I can rely on Jolt Physics to serialize settings objects, that will make JME integration a lot easier.

11 Likes
88

I learned that Jolt has 2 serialization systems: one for uncooked data (ObjectStream) and one for cooked.

JoltPhysics/Docs/Architecture.md at master · jrouwe/JoltPhysics · GitHub

I’ve begun experimenting with the ObjectStream system. Serializing a rigid body, at least, seems to be straightforward.

Neither system handles physics characters, so I’ve opened an issue for that:

7 Likes
89

Thank you so much for your work! :partying_face:

3 Likes
92

You understand that this is completely unrelated to anything in this thread, right?

2 Likes
93

oh sorry. I posted it here.