The refactoring is done—as much as it can be without API changes. There’s a growing backlog of desirable API changes, which means Minie v1.7 (when it appears) may be closely followed by a v2. I plan to preserve as much of the jme3-bullet API as possible, even in v2.
Visualization for (rigid-body) velocities and (rigid/soft-body) gravity vectors is done. Both of those features will surely be in v1.7.
Freeing native objects using finalizers is looking more and more problematic. I hope to include the phantom-reference rewrite in v1.7 .
I’ve investigated the “static-static collisions” issue. It was actually caused by collisions between kinematic bodies. It may be possible to speed up applications that don’t need to detect such collisions. Perhaps add a runtime flag to enable/disable kinematic collisions.
I’m sure you were already aware of this, but for others who may not be: Loading.... Object.finalize() was deprecated in Java 9, and it’s possible that at some point in the future any finalize() uses may simply stop working.
Indeed! And JME’s direct-buffer allocator uses illegal reflective-access operations, which may also break at some point. Both issues seem worthy of their own Forum topics.
Studying the “static-static collision” issue convinced me that the PhysicsRigidBody internals need some redesign, particularly the code that switches between modes (static/dynamic/kinematic) and the code that alters the collision shape. But before I can implement any new design, I’ll need a more thorough test suite. That may take awhile.
While studying the rigid-body native code, I discovered a flag that disables the biggest “gotcha” in Bullet Physics, namely: adding a rigid body to a physics space can alter the body’s gravity. I created accessors for this flag, which will go public in v1.7. The old (jme3-bullet) behavior will remain the default, however.
Numerous features have been added to the DropTest demo app, including new uses for CompoundCollisionShape. Offhand, I know 3 ways to build compound shapes:
fully automatic, using V-HACD
convert each scene-graph mesh to a child shape, using CollisionShapeFactory.createDynamicMeshShape()
construct explicitly, using Java code or an interactive tool like the one @Ali_RS demonstrated in April
I found that, for #3 at least, it would be handy to be able to translate and rotate a CompoundCollisionShape without rebuilding it from scratch. Those capabilities are working in Minie and will be included in v1.7 .
Speaking of compound shapes, Minie’s debug visualizer currently rebuilds their debug geometries on every frame (in order to avoid Issue 1346). If the debug scene contains too many child shapes, debug visualization rapidly fills the heap with garbage, causing severe performance drops. I have a notion to mitigate this issue in v1.7 .
Finally, Bullet has a little-known feature to disable collisions between specified pairs of collision objects. Currently it’s used only to implement setCollisionBetweenLinkedBodies(), but it might also provide a better alternative to collision groups in some applications. Exposing this API to Java is on the wishlist, though probably not for Minie v1.7 .
This was indeed a nasty bug and took me a while to figure out!
It’s nice to see you taking this up. I’m closely following this thread and although I don’t have a deep knowledge in this area, I find it a very interesting read.
Correct me if I’m wrong but, as far as I’ve read android up to nougat (api level 24) uses java7 and later uses java7 plus a subset of java8
I don’t know which is current market status (it’s currently not published in android website) but as my main focus is android platform I would prefer not to publish an app that won’t run in maybe 30% of the current user devices and I would love to replace bullet with minie
I believe Minie could someday support IOS. To make it happen, I’d want to collaborate with someone who has IOS development experience, rather like I collaborated with @ndebruyn to make Android support happen.
Yes, with SubstrateVM you can ahead of time compile java to a native image. But, it’s still new enough that I won’t seriously try anything. It needs time to become stable.
Graal might be the most exciting up and coming thing in the jvm space
I think it might be already possible for someone brave to get everything needed working on Android/iOS today. But personally, I will wait for better Android/iOS tooling to become available.
You can see a lot has happened in the last few months, the progress on Graal is pretty quick so I don’t think it’ll be long
Ignore lists for collision objects are now fully implemented.
Yesterday I accidentally discovered another feature of Bullet Physics: contact tests. A contact test determines what a collision object would collide with if it were added to a collision space.
It’s somewhat like a sweep test, except for stationary collision objects instead of moving convex shapes. It’s somewhat like a ghost object, except it uses the exact collision shape, works without being added to the space, and provides full details about each contact.
Suppose you want to “teleport” a body into physics space, but only if it won’t immediately collide with bodies already there. (Unless both shapes are convex, such bodies tend to interpenetrate and flutter or get stuck.) You could use contact tests to select a destination that’s clear of obstructions, or to postpone the teleport until the preferred destination is clear.
The API is still in flux, but barring major issues, contact tests will appear in Minie v1.7 .
Contact tests are committed to the repo—though due to an issue in Bullet 2.89, they don’t work on soft bodies. (Sweep tests don’t work on soft bodies either, though ray tests do.) I investigated these issues and decided they’re beyond my current C++ coding skills.
Back in November, Erwin Coumans described Bullet’s soft-body code as “an unsupported contribution.” Perhaps it (and the multi-body code) should eventually be moved out of Minie’s standard pre-built library and into an “experimental” build. GImpact shapes and some of the old PhysicsJoint subclasses might land there too!
Anyway, contact tests will be in v1.7 . Even if limited to rigid bodies, characters, and ghosts, I predict they’ll see plenty of use in the future.
I mentioned on 10 May that debug visualization had been enhanced with optional arrows for gravity vectors and rigid-body velocities. Further visualization enhancements were recently committed to the repo:
Pinned soft-body nodes are visualized automatically, by little red markers.
Velocity vectors of soft-body nodes/clusters can be visualized by arrows.
Collision objects that use PlaneCollisionShape can easily be customized with repeating textures.
It’s still possible that v1.7 debug visualization might support local physics and/or PhysicsJoint ranges of motion, though neither of those features is implemented yet.
I’d once hoped v1.7 would include both (1) kinematic collision filtering and (2) memory management using phantom references. But both those features have been “pushed out” to v2.
The example apps continue to improve. DropTest, which began as a functional test for MultiSphere collision shapes, now includes 52 types of “drops”, including compound shapes, jointed bodies, and soft bodies. There’s also a new TargetDemo app, aimed at people who enjoy knocking things down. Its scenarios include: a round tower, a brick wall, a pyramid of tin cans, and classic arrangements of dominoes, billiard balls, and bowling pins.
and I would love to replace bullet with minie
