There are some API changes, but they’re all in fairly obscure places. I doubt they’ll impact any applications.
Version 7.0.0 solves a slew of troublesome bugs, mostly related to cloning and (JME) serialization. See the release log for details.
The new version also provides some additional double-precision accessors for collision objects. These might prove useful if you’re simulating physics in a large world—one larger than, say, 20,000 physics-space units in diameter. To make effective use of these accessors, you’d need a version of Minie with double-precision native libraries, such as:
There’s now a 7.2.0 release of Minie, which fixes a few bugs and adds 2 methods for testing and debugging. It’s been a busy month …
The key motivation for v7.2.0 was native-code bugs involving global weak references that could never be deleted. The bugs were discovered on Android JVMs, which reportedly track GWRs in a table limited to 51,200 entries. During tests, the table filled up in about 10 minutes! Special thanks to @tharg2 for reporting the issue and providing the stack trace that pointed me to the root cause.
The new release includes many technical changes “under the hood”. I hope they won’t cause any new issues. For instance, the Windows natives were built using Visual Studio 2022 instead of VS 2019.
The added methods are intended to help debug issues around multi-threaded native libraries and/or BulletAppState.ThreadingType.PARALLEL. Parallel-threaded physics is tricky to get right, and going forward I hope to add runtime checks for threading issues.
(No new progress toward Voronoi fracture, by the way.)
Expect another Minie release once JMonkeyEngine 3.6.0-stable becomes available.
Expect another Minie release once JMonkeyEngine 3.6.0-stable becomes available.
I decided Minie v7.3 can’t wait for JMonkeyEngine v3.6.0-stable. Instead, I’m basing it on v3.6.0-beta3, which looks good so far. I hope this will encourage other software developers to test beta3 in their own projects.
First off, Minie v7.3 fixes a handful of nasty bugs. These are briefly summarized in the release notes. I’ll gladly go deeper into those if you have questions or concerns.
The DacWizard application has been enhanced in several ways:
You can now test ragdolls in poses other than bind pose. This comes in handy if the model’s bind pose is something other than the typical “upright T” pose.
You can now configure the torso’s “main bone” from the application. There’s a whole new screen just for this purpose. This feature comes in handy if the model’s root bone is located near its feet—or anywhere other than its pelvis.
If you generate Java code from the “test” screen, the output file now includes a utility method to configure the ragdoll. Sometimes a utility method is more convenient than a subclass for this purpose.
DynamicAnimControl has acquired a new kinematic submode, named “reset”. The idea is that, as an alternative to blending the model to a canned animation or to bind pose, you can blend it to a pose that has been previously saved by invoking the saveCurrentPose() method.
There’s a new physics control named JointedBodyControl. The control is similar to RigidBodyControl, except it extends AbstractPhysicsControl and it is aware of physics joints. When you remove the control from a space, all its joints are automatically destroyed.
The CollisionSpace class (a superclass of PhysicsSpace) got a new option to force updates to all AABBs. The option is enabled by default. In theory, disabling the option should boost performance of spaces containing many deactivated (“sleeping”) bodies. I haven’t tried to measure the performance gain.
The new release is actually named “7.3.0+for36”. (That’s in case I ever need to publish a similar release targeting JME v3.5.x .) All the usual variants (“+big3”, “+droid”, “+debug”, etcetera) are provided. For example, to use the “big3” variant in a Gradle project:
Just released today: Minie v7.5.0 … to fix one more bug.
The bug occurs while cloning collision objects with ignore lists: for instance, when a 3-D model with DynamicAnimControl is loaded from the JME asset cache. I plan to write a detailed analysis in my devblog.
In hindsight, I believe the regression in v7.8.0 only affects very complicated collision shapes. In my closed-source project, the trigger was a static rigid body with mesh shape containing 225 parts, 6,086 triangles, and 16,259 vertices.
The symptoms were: ray tests missing when they should hit, missing contact response, incomplete debug visualization, and eventual JVM crashes. As you can imagine, I was very concerned.
Apparently Bullet has (undocumented) limits on the complexity of mesh shapes. I should figure out what those limits are, document them, and (if possible) add run-time checks.