Minie v4.8

User Code & Projects Minie
1

It’s been less than 2 weeks since I released v4.7 of the Minie physics library, and here I am, returning to announce Minie v4.8!

I don’t know of any serious flaws in v4.7. EDIT: see issue 23!! However, since JME now supports native physics for MacOSX_ARM64 platforms, it seems important for Minie to do so also.

Minie v4.8.0 adds native libraries for the new “Apple Silicon” Macs. If your project is built using Gradle or Maven, specify “Minie-4.8.0” and “jme3-desktop-3.5.1-stable” in your buildscripts. However, please note:

  • This assumes your app already works on Intel-based Macs.
  • Upgrading will add about 800 KB to the size of your app.
  • This assumes you’re using LWJGL v3; LWJGL v2 doesn’t support “Apple Silicon” Macs.

Minie v4.8.0 also adds accessors for 2 global error-reduction parameters (ERPs) in the contact-and-constraint solver: one for rigid-body contacts and one for physics joints.

Joint ERP controls joint elasticity, which is when a physics joint fails to keep up with motion of its joined bodies.

For instance, if you join a ball (dynamic body) to a character’s hand (a fast-moving kinematic body) using a fixed joint (zero degrees of freedom), you may notice that the ball’s motion lags behind the hand by several ticks. On every tick, the solver calculates a new ball position, but it only applies 20% of the correction. This is because the joint ERP defaults to 0.2 .

I consider 0.2 a low value for ERP, leading to unnecessary joint elasticity. Perhaps it was chosen to avoid numeric instability when there are conflicting constraints.

To reduce joint elasticity, you might shorten the physics time step using PhysicsSpace.setAccuracy(), but that would consume a lot more CPU. It’s more efficient to set the joint ERP closer to 1 using PhysicsSpace.getSolverInfo().setJointErp().

There’s also a “contact ERP” value that affects position corrections for rigid-body contacts. It might be useful in case of unwanted overlaps between bodies.

External links:

13 Likes
2

Thank you Stephen.
Can you share some details on how you managed to build for macos arm64?

1 Like
3

As you know, Gradle’s cross-compiler support doesn’t admit the possibility of ARM-based Macs. In the end, here’s what I did:

  1. I created an alternative Gradle buildscript that builds native libraries without attempting any cross-compilation. (All my buildscripts use the pre-2018 “cpp” plugin, not the modern “cpp-library” plugin.)
  2. I executed the buildscript on an actual ARM-based Mac.
% ./gradlew clean build -b current.gradle
Build MacOSX_ARM64DebugDp using Tool chain 'clang' (Clang)
Build MacOSX_ARM64DebugSp using Tool chain 'clang' (Clang)
Build MacOSX_ARM64ReleaseDp using Tool chain 'clang' (Clang)
Build MacOSX_ARM64ReleaseSp using Tool chain 'clang' (Clang)

> Task :test
Debug_Libbulletjme version 14.2.0 initializing

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.4.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 51s
15 actionable tasks: 12 executed, 3 up-to-date
% bash/copyNatives.sh 
%
2 Likes
4

There’s a serious bug in v4.8.0 that (I suspect) only affects 64-bit Windows, so I’m working on a new release to fix it. It probably affects v4.7.1 also, but not v4.6.1 or earlier …

The bug report: https://github.com/stephengold/Minie/issues/23

3 Likes
5

OK, I think issue 23 is fixed. Instead of v4.8.0, please use v4.8.1:

repositories {
    mavenCentral()
}
dependencies {
    implementation 'com.github.stephengold:Minie:4.8.1'
}
4 Likes