Items 1-3 are included in jolt-jni v0.4.1, which was released on Tuesday.
V0.4.1 also adds temporary support for Linux-on-ARM platforms with 32- and 64-bit CPUs. Long-term support for these platforms will require resolution of a couple Jolt Physics issues, such as issue 1184.
This week’s goal is to round out KK Physics support for collision shapes:
BoxCollisionShape, CapsuleCollisionShape, ConvexHullShape, CylinderCollisionShape, MeshCollisionShape, SimplexCollisionShape, and SphereCollisionShape are in good shape (so to speak).
HeightfieldCollisionShape and CompoundCollisionShape are current priorities.
ConeCollisionShape, GImpactCollisionShape, MultiSphere, and PlaneCollisionShape will probably require custom native code and will therefore be deferred.
KK Physics v0.3.0 was released today. This is a major advance over v0.2.0, and I think it’s ready for some limited testing.
If all you want to do is create rigid bodies and simulate their motion, with or without CCD, v0.3.0 might be useful.
Many important features are not yet implemented:
cone, gImpact, 2-D, plane, and multi-sphere shapes
contact/ray/sweep tests
characters, ghost objects, ragdolls, soft bodies, and vehicles
physics joints and motors
collision listeners and collision groups
cloning and serialization
ignore lists
linear factors and angular factors
modifying the collision margin of a shape after it’s been created
“local physics” for a rigid-body control
The API (what there is of it) closely resembles both Minie and jme3-jbullet. It includes such familiar conveniences as BulletAppState, RigidBodyControl, PhysicsDumper, and debug visualization.
A couple key differences from Minie/jme3-jbullet:
to enable continuous collision detection (CCD), use PhysicsRigidBody.setMotionQuality()
to alter a body’s gravity, use PhysicsRigidBody.setGravityFactor()
As usual, I welcome discussion, feature requests, and constructive feedback.
Hey, I’m a noob here, using IDEA for coding. My friend was all like, ‘Dude, you gotta use KK Physisc for your projects.’ So, I tried tossing in the jar, but it’s all messed up with errors, like in the pic I wish I could show you. Is there some secret sauce to making it work?
I’m curious who your friend is.
There’s no secret sauce.
KK Physics and Minie both implement the com.jme3.bullet package, so they can’t be used together in the same project.
If Paul’s guess is correct, you should remove the Minie jar from your project.
If that doesn’t solve your issue, I’d like to see some your build scripts and maybe some Java code.
Very grateful to both of you! The problem has been solved! Also, because my English is not good, I used AI for translation, there might be some nuances lost in translation, my apologies for that.
I used AI for translation, there might be some nuances lost in translation, my apologies for that.
I appreciate your efforts to communicate in English. Apologies are unnecessary.
I’m very glad someone besides me is experimenting with KK Physics!
All:
For the past 3 weeks, my focus has been expanding jolt-jni to support character controllers and constraints/joints. This required a lot of repetitive coding in both C++ and Java. Both features are implemented rather differently in Jolt Physics than in Bullet; I worry they may not translate well into KK Physics.
With the release of Jolt Physics v5.1.0 on 11 August, ongoing support for Linux-on-ARM looks solid.
V5.1.0 also added plane shapes, which will come in handy.
During the past 4 months I made plenty of progress on the Java bindings for Jolt (jolt-jni). Support was added for characters, soft bodies, vehicles, more collision shapes, more types of constraints, and more details from collision detection. Version 0.9.3 of jolt-jni was released on 13 November.
Meanwhile I haven’t done much with KK Physics, the library to incorporate Jolt Physics into JME. That’s partly because jolt-jni kept me busy and partly because I’m unsure whether emulating the jme3-jbullet API is the right way forward. Once you get beyond simple dynamic rigid bodies, the conceptual differences between Jolt and Bullet are huge! It might make more sense to create a new API that fits better with Jolt; this might be as simple as a single appstate and a scene-graph control.
Around 10 December, I began seeing hard-to-reproduce JVM crashes in jolt-jni continuous integration. After much trial and error, I managed to reproduce the crashes in my development environment and narrowed down the root cause somewhat. The crashes seem related to garbage collection of ragdolls: perhaps heap corruption or an ordering issue. However, I still haven’t pinpointed the cause. Until that issue is solved, I won’t be publishing another release of jolt-jni.
Finally, I should mention that late December and early January are a difficult time for me. If my slump follows the pattern of past winters, I should be more active and productive come mid-January.
Thanks for your efforts.
I think you should take time. Its all up to you. I believe you will make it. This will help to boost JME performance in Physics. Have a good day. Good wishes !! Good Luck !!
Does anyone know a way to control the order in which Java objects are cleaned? Otherwise I might have to (a) fork Jolt Physics or (b) disable cleaning of physics systems in jolt-jni.
I don’t know enough about how this is all wired up but I’m left with questions.
What is a Ragdoll trying to do with a destroyed physics space? Either the ragdoll is still alive and should have had a strong reference to the physics space or the ragdoll is trying to do something during ‘cleanup’ that maybe it doesn’t need to do. Or?
If as the thread says, the physics space isn’t keeping track of the ragdoll… then what about ‘cleaning up’ does the ragdoll need to do with the physics space?
Assuming this really IS needed and not some design issue in the Java layer, I wonder if you can get away with some kind of insulated pointer. So the ragdoll doesn’t have a hard reference to the physics space but an insulated reference that the physics space provides… and can clear when it’s destroyed. The ragdoll would at least know that this indirect insulated pointer is now empty.
Let me know if you need pseudo-code to better describe that if it doesn’t make sense from words.
I think the issue is that both are up for GC at the same time.
…which is normally fine because every object takes care of itself and doesn’t have to do anything with its references. (Thus my questions.) To me, ‘cleaning up’ the rag doll shouldn’t require doing anything with the physics space… and that could be the source of the real trouble.
Each ragdoll is composed of bodies that live in a physics system. C++ finalization of the ragdoll is trying to destroy those bodies:
I think I understand what you’re suggesting. The trick would be to implement this without modifying Jolt Physics. I’ll give some more thought to how this might work.
As Paul surmised, both JVM objects are eligible for GC in my scenario. A field in the ragdoll can’t keep the physics system “alive” (reachable) because the ragdoll itself isn’t reachable, only phantom reachable.
Lying in bed this morning, I got an idea. Perhaps the Java library could create, for each ragdoll, a (strong) reference to its physics system, but stored in a static map instead of in the ragdoll itself. Each map entry could be explicitly removed when its ragdoll gets cleaned, keeping the physics system reachable until all its ragdolls have been cleaned. The mechanism would have to be thread-safe, of course.
I did not ment to set the field in the java object, but in the native handle. I tought that if you pass a strong reference to the the cleaner runnable for example it should keep the physics space alive until all cleaner actions have been executed.
