It contains 6 sub-projects:
- MinieLibrary: the Minie runtime library and its automated tests
- DacWizard: a GUI application to configure a ragdoll
- MinieExamples: demos, examples, tutorials, and non-automated test software
- MinieAssets: generate assets used in MinieExamples
- MinieDump: a command-line utility to dump J3O assets
- Jme3Examples: physics examples from jme3-examples
Complete source code (in Java) is provided under a 3-clause BSD license.
- Why use Minie?
- Overview and design considerations
- How to build Minie from source
- An overview of the demo applications
- External links
jMonkeyEngine comes with 2 Bullet integration libraries.
Why use Minie instead of
- Minie has many more features. (See the feature list below.)
- Minie fixes many bugs found in the jMonkeyEngine libraries.
- Due to its shorter release cycle, future features and bug fixes will probably appear first in Minie.
- Minie uses automated testing to reduce the risk of regressions and new bugs.
- Minie's classes are better encapsulated, with fewer public/protected fields and less aliasing of small objects like vectors. This reduces the risk of accidentally corrupting its internal data structures.
- Minie validates method arguments. This helps detect usage errors that can lead to subtle bugs.
- Minie's source code is more readable and better documented.
Summary of added features:
- Extensions to
- Soft-body simulation based on
btSoftRigidDynamicsWorld, including anchors and soft-body joints
- Multi-body simulation based on
- Convex decomposition of meshes using Khaled Mamou's V-HACD Library, including progress listeners
New6Dofphysics joints based on
- Alternative contact-and-constraint solvers based on
- collision shapes:
MultiSphereshapes based on
Box2dShapeshapes based on
Convex2dShapeshapes based on
EmptyShapeshape based on
- debugging aids:
- dump the contents of a
- visualize physics objects in multiple viewports
- customize debug material per collision object
- visualize the local axes, velocities, bounding boxes, CCD swept spheres, and gravity vectors of collision objects
- visualize the children of compound collision shapes
- optional high-resolution debug meshes for convex shapes
- options to generate debug meshes that include indices, normals (for shading), and/or texture coordinates (for texturing)
- dump the contents of a
- all joints, shapes, collision objects, and multibodies
- enable/disable a
- single-ended physics joints
- ignore lists for collision objects
- application-specific data for collision objects
- access more parameters of rigid bodies, vehicles, characters, joints, collision shapes, contact/constraint solvers, etcetera
- option to apply scaling with a
jme3-jbullet classes that Minie omits:
RagdollUtils: not needed
Other important differences:
PhysicsSpace.removeAll()add/remove collision objects only; they do not add/remove joints.
RagdollCollisionListenerinterface changed and moved from the
com.jme3.bullet.collisionpackage to the
Older releases (v0.1.1 through v0.4.5) can be downloaded from the Jme3-utilities Project.
Newer Maven artifacts (since v3.1.0) are available from MavenCentral.
Old Maven artifacts (v1.4.0 through v3.1.0) are available from JCenter.
Package names begin with
(if Stephen Gold holds the copyright) or
jme3test. (if the jMonkeyEngine Project holds the copyright).
Both the source code and the pre-built libraries are compatible with JDK 7.
The role of physics simulation in games
Most computer games don't require detailed physics simulation.
- Canned animations usually suffice to illustrate characters walking, jumping, and fighting.
- Detecting when a character enters a fixed zone or comes into range of another character is a simple geometric calculation, provided the zone or range has a box or sphere shape.
- For outer-space games, the equations of motion (Newton's 3rd Law) are easily implemented from scratch.
Other games require physics simulation, either because detailed physics is integral to gameplay (as in bowling or auto racing) or else to enhance the verisimilitude of effects such as collapsing buildings and/or people. For such games, a real-time physics library such as Minie should prove useful.
How Minie works
The computational cost of collision detection grows rapidly with the number of collision objects and the complexity of their shapes. To simulate physics in real time, with modest CPUs, it's vital to keep the physics simple:
- Use very simple collision shapes (such as boxes, capsules, and spheres) wherever possible.
- Minimize the number of collision objects by merging static bodies together and simulating only the most relevant moving bodies.
- Minimize the number of nodes in each soft body.
Scaling the world
For a physics simulation, it might seem natural to choose kilograms and meters as the units of mass and distance, respectively. However, this is not a requirement, and for many games, MKS units are not the best choice.
Bullet documentation recommends that dynamic bodies have masses as close as possible to 1.
Also, to improve the performance and reliability of collision detection, Bullet applies a margin to most collision objects. By default, this margin is 0.04 physics-space units (psu). While the margin is configurable, Bullet documentation recommends against doing so. For some collision shapes, margin increases the effective size of the object and distorts its effective shape. For this reason, it's undesirable to have a collision object with any radius smaller than about 0.2 psu.
Dynamic bodies in forced contact tend to jiggle. Jiggling is mostly noticeable for sharp-edged bodies (such as boxes) resting on uneven surfaces, under high gravity. The higher the gravity (in psu per second squared), the shorter the simulation time step (in seconds) needs to be. For efficient and realistic simulation of Earth-like gravity (9.8 m/s) with the default margin (0.04 psu) and time step (0.0167 seconds), the psu should be 0.3 meters or larger. This puts a soft lower limit on the dimensions (in psu) of dynamic bodies.
Since Minie's debug visualization assumes that physics coordinates are equivalent to world coordinates, these recommendations could impact model creation and scene-graph design. Physics units should therefore be chosen with care, preferably early in the development process.
- How to add Minie to an existing project
- An introduction to rigid-body physics
- Choosing collision shapes
- Debugging physics issues
- An introduction to New6Dof
- An introduction to DynamicAnimControl
- Collision detection
- An introduction to soft-body physics
- the Minie Physics Library page at the JmonkeyStore
- The Bullet Physics SDK Manual
- The Physics section of the JME Wiki
YouTube videos about Minie:
- June 2019 teaser #2 (rubber duck) watch (0:16) source code
- June 2019 teaser #1 (jogger in skirt) watch (0:24) source code
- May 2019 teaser #3 (wind-blown flag) watch (0:06) source code
- May 2019 teaser #2 (squishy ball and tablecloth) watch (0:12) source code
- May 2019 teaser #1 (squishy ball) watch (0:13) source code
- April 2019 walkthru of the DacWizard application watch (8:12) source code
- March 2019 short demo (IK for head/eye directions) watch (1:25) source code
- March 2019 teaser (buoyancy) watch (0:10) source code
- February 2019 demo (ropes) watch (4:47) source code
- December 2018 demo (inverse kinematics) watch (6:27) source code
- December 2018 teaser (inverse kinematics) watch (0:51)
- November 2018 demo (single-ended joints) watch (5:50) source code
- November 2018 demo (
MultiSphereshape) watch (0:13) source code
- October 2018 demo (
DynamicAnimControlragdolls) watch (2:49) source code
Most of Minie was originally forked from
a library in the jMonkeyEngine Game Engine.
From January to November 2018, Minie was a sub-project of the Jme3-utilities Project.
Since November 2018, Minie has been a separate project at GitHub.
Like most projects, the Minie Project builds on the work of many who have gone before. I therefore acknowledge the following artists and software developers:
- Normen Hansen (aka "normen") for creating most of the
jme3-bulletlibrary (on which Minie is based) and also for helpful insights
- Rémy Bouquet (aka "nehon") for co-creating
DynamicAnimControlis based) and also for many helpful insights
- Jules (aka "dokthar") for creating the soft-body fork of jMonkeyEngine from which Minie's soft-body support is derived
- Khaled Mamou for creating and licensing the V-HACD Library for decomposing meshes into convex hulls
- Riccardo Balbo (aka "riccardo") for creating and licensing the V-HACD Java Bindings Project
- "ndebruyn" for early testing of Minie on Android platforms
- Pavly Gerges (aka "Pavl_G") for testing Minie on Raspberry Pi
- Adam T. Ryder (aka "tryder") for creating and licensing the jME-TTF rendering system
- Paul Speed, for helpful insights
- "oxplay2", for reporting a
PhysicsRigidBodybug and helping me pin it down
- "duncanj", for pull request #15
- Nathan Vegdahl, for creating the Puppet model
- Tobias Jung, for distributing ProFont
- plus the creators of (and contributors to) the following software:
- the Antora static website generator
- the Blender 3-D animation suite
- the Bullet real-time physics library
- the FindBugs source-code analyzer
- the Firefox and Google Chrome web browsers
- the Git revision-control system and GitK commit viewer
- the Gradle build tool
- the Java compiler, standard doclet, and virtual machine
- jMonkeyEngine and the jME3 Software Development Kit
- the Linux Mint operating system
- LWJGL, the Lightweight Java Game Library
- the MakeHuman Community
- the Markdown document-conversion tool
- the Meld visual merge tool
- Microsoft Windows
- the NetBeans integrated development environment
- the Nifty graphical user-interface library
- Open Broadcaster Software Studio
- the PMD source-code analyzer
- ProFont, the programmers' font
- the WinMerge differencing and merging tool
I'm also grateful to my dear Holly, for keeping me sane.
If I've misattributed anything or left anyone out, please let me know so I can correct the situation: firstname.lastname@example.org