Awesome
jolt-jni
The Jolt-jni Project provides JVM bindings for Jolt Physics, to facilitate physics simulation in JVM languages such as Java and Kotlin.
Source code (in Java and C++) is provided under an MIT license.
<a name="toc"></a>
Contents of this document
- Translating Jolt Physics applications into Java
- How to add jolt-jni to an existing project
- How to build jolt-jni from source
- Freeing native objects
- External links
<a name="translate"></a>
Translating Jolt Physics applications into Java
There’s close correspondence between the class/method names of Jolt Physics and jolt-jni. For example:
- The
Body
class in jolt-jni will (eventually) provide all the functionality of theBody
class in Jolt Physics. - The
ConstBody
interface will include all theconst
methods of the Jolt PhysicsBody
class, such as itsGetPosition()
method, which in jolt-jni is calledgetPosition()
.
Things become slightly more interesting when C++ templates and public member data are involved. For instance:
- An array of body IDs is
Array<BodyID>
in Jolt Physics; in jolt-jni it’s called aBodyIdVector
. - The
mConvexRadius
member of the Jolt PhysicsBoxShapeSettings
class is accessed usinggetConvexRadius()
andsetConvexRadius()
in jolt-jni.
For a couple well-known Jolt Physics examples, line-for-line translations into Java are provided.
<a name="add"></a>
How to add jolt-jni to an existing project
Jolt-jni comes pre-built as a platform-independent JVM library plus a set of native libraries, all downloadable from Maven Central.
Current jolt-jni releases provide the JVM library under 6 distinct names (artifact IDs). They also provide 24 native libraries, each specific to a particular platform, build type, and build flavor.
Your runtime classpath should include a JVM library plus 1-to-6 native libraries: a native library for each platform on which the code will run.
Build types: use "Debug" native libraries for development and troubleshooting, then switch to "Release" libraries for performance testing and production.
Build flavors: use "Dp" to simulate large worlds (>1000 meters in diameter) otherwise use "Sp".
Gradle-built projects
Add to the project’s "build.gradle" or "build.gradle.kts" file:
repositories {
mavenCentral()
}
dependencies {
// JVM library:
implementation("com.github.stephengold:jolt-jni-Linux64:0.9.3")
// native libraries:
runtimeOnly("com.github.stephengold:jolt-jni-Linux64:0.9.3:DebugSp")
// Native libraries for other platforms could be added.
}
- The "Linux64" platform name may be replaced by "Linux_ARM32hf", "Linux_ARM64", "MacOSX64", "MacOSX_ARM64", or "Windows64".
- The "DebugSp" classifier may be replaced by "DebugDp", "ReleaseSp", or "ReleaseDp".
- For some older versions of Gradle,
it's necessary to replace
implementation
withcompile
.
<a name="build"></a>
How to build jolt-jni from source
Initial build
- Install a Java Development Kit (JDK), if you don't already have one.
- Point the
JAVA_HOME
environment variable to your JDK installation: (In other words, set it to the path of a directory/folder containing a "bin" that contains a Java executable. That path might look something like "C:\Program Files\Eclipse Adoptium\jdk-17.0.3.7-hotspot" or "/usr/lib/jvm/java-17-openjdk-amd64/" or "/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home" .)
- using Bash or Zsh:
export JAVA_HOME="
path to installation"
- using Fish:
set -g JAVA_HOME "
path to installation"
- using Windows Command Prompt:
set JAVA_HOME="
path to installation"
- using PowerShell:
$env:JAVA_HOME = '
path to installation'
- Download and extract the jolt-jni source code from GitHub:
- using Git:
git clone https://github.com/stephengold/jolt-jni.git
cd jolt-jni
git checkout -b latest 0.9.3
- using a web browser:
- browse to the latest release
- follow the "Source code (zip)" link at the bottom of the page
- save the ZIP file
- extract the contents of the saved ZIP file
cd
to the extracted directory/folder
- (optional) Edit the "gradle.properties" file to configure the build.
- Run the Gradle wrapper:
- using Bash or Fish or PowerShell or Zsh:
./gradlew build
- using Windows Command Prompt:
.\gradlew build
After a successful build, artifacts will be found in "build/libs".
Other tasks
You can run the "hello world" example app:
- using Bash or Fish or PowerShell or Zsh:
./gradlew runHelloWorld
- using Windows Command Prompt:
.\gradlew runHelloWorld
You can run various scenes in the "performance test" example app:
- the ConvexVsMesh scene:
- using Bash or Fish or PowerShell or Zsh:
./gradlew runConvexVsMesh
- using Windows Command Prompt:
.\gradlew runConvexVsMesh
- using Bash or Fish or PowerShell or Zsh:
- the Pyramid scene:
- using Bash or Fish or PowerShell or Zsh:
./gradlew runPyramid
- using Windows Command Prompt:
.\gradlew runPyramid
- using Bash or Fish or PowerShell or Zsh:
- the Ragdoll scene:
- using Bash or Fish or PowerShell or Zsh:
./gradlew runRagdoll
- using Windows Command Prompt:
.\gradlew runRagdoll
- using Bash or Fish or PowerShell or Zsh:
You can install the artifacts to your local Maven repository:
- using Bash or Fish or PowerShell or Zsh:
./gradlew install
- using Windows Command Prompt:
.\gradlew install
You can restore the project to a pristine state:
- using Bash or Fish or PowerShell or Zsh:
./gradlew cleanAll
- using Windows Command Prompt:
.\gradlew cleanAll
<a name="free"></a>
Freeing native objects
In long-running applications, it's important to free objects that are no longer in use, lest the app run out of memory.
Here it's important to distinguish between JVM objects and native objects.
A handful jolt-jni classes are implemented entirely in Java, notably:
Color
, Float3
, Plane
, Quat
, RVec3
, UVec4
, Vec3
, and Vec4
.
Apart from these special classes,
every JVM object in jolt-jni is an instance of JoltPhysicsObject
,
which implies it has a corresponding native object assigned to it.
For instance, when a jolt-jni app instantiates a matrix using new Mat44()
,
both a JVM object and a native object are created.
The app can't access the native object directly;
it can only invoke methods exposed by the JVM object.
While JVM objects get reclaimed automatically (in batches, by a garbage collector) after they become unreachable, jolt-jni provides several mechanisms for reclaiming native objects.
In the simple case of a matrix instantiated using matrix = new Mat44()
,
the native object can be freed:
- explicitly using
matrix.close()
, - implicitly by
AutoCloseable
(at the end of thetry
block in which the matrix was instantiated), or - automatically when the corresponding JVM object is reclaimed
(provided a cleaning task has been started
by invoking
JoltPhysicsObject.startCleaner()
).
In native code, convention dictates that when a class allocates memory, it assumes responsibility for freeing it. For this reason, jolt-jni applications cannot free objects created implicitly by Jolt Physics.
For instance, when an app invokes getBodyLockInterface()
on a PhysicsSystem
,
a new JVM object is returned.
However, that JVM object refers to a pre-existing native object
(the one Jolt Physics allocated while initializing the PhysicsSystem
).
Thus, the application need not (and cannot) free the native object
separately from the PhysicsSystem
that contains it.
On such "contained" objects, close()
is a no-op,
because the JVM object doesn't "own" its assigned native object.
Another case where a JoltPhysicsObject
doesn't own its assigned native object
is when the object implements reference counting.
In this case, responsibility for freeing the native object (called the "target")
is shared among other objects (called "references") that refer to it.
Jolt-jni classes that implement reference counting
are exactly those that implement the RefTarget
interface.
They include BaseCharacter
, Constraint
, ConstraintSettings
,
GroupFilter
, PhysicsMaterial
, PhysicsScene
, Ragdoll
, Shape
,
ShapeSettings
, VehicleController
, and all their subclasses.
On RefTarget
objects, close()
is (again) a no-op,
because the JVM object doesn't own its assigned native object.
The simplest way to create a reference is to invoke target.toRef()
.
References are themselves instances of JoltPhysicsObject
, of course.
(And please note that jolt-jni reference counting is completely orthogonal
to Java references, strong, weak, or otherwise.)
The only way to free the assigned native object of a RefTarget
is to decrement its reference count from one to zero.
This implies creating one or more references
and then freeing them all, either explicitly, implicitly, or automatically.
As long as a reference is active, its target cannot be freed.
Nor can a target be freed if no reference to it has been created
(because in that case its reference count is already zero).
Nor can it be freed if reference counting is disabled
by invoking target.setEmbedded()
.
<a name="links"></a>