Minie v4.7

User Code & Projects Minie
1

Version 4.7.1 of the Minie physics library was released today (11 March). If you have projects that use Minie, I recommend updating to the new release.

EDIT: v4.7.1 is no longer recommended due to issue 23. Use v4.8.1 instead.

The release adds new APIs related to rigid-body contacts, based on suggestions made by @qwq.

When Bullet Physics detects a collision between 2 rigid bodies, it generates a contact manifold that approximately describes the intersection of their shapes. Each manifold is composed of up to 4 contact points. Bullet uses contact manifolds and contact points to resolve rigid-body collisions by the end of the current physics step.

The old collision-detection mechanisms [addCollisionListener() and addOngoingCollisionListener()] generate a PhysicsCollisionListener callback for every contact point. However, such callbacks don’t occur immediately (in the the midst of a physics step). Instead, the PhysicsSpace queues up PhysicsCollisionEvents and delivers them to the application during the next BulletAppState.update(). This is convenient because update() occurs on the render thread (which might be distinct from the physics thread), so it’s OK to modify the scene graph in a PhysicsCollisionListener.

The new mechanism [addContactListener()] generates callbacks in the midst of a physics step. It is more efficient (because no event object is created). It also enables applications to modify contact points on the fly, which proves useful for simulating conveyor belts, as in a classic Bullet Physics example:

GIF 2022-2-23 星期三 19-12-58

@qwq has kindly provided a JMonkeyEngine version of the conveyor-belt demo: Minie/ConveyorDemo.java at master ¡ stephengold/Minie ¡ GitHub

A possible downside is that the new callbacks occur on the physics thread. It isn’t always safe to modify the scene graph from such contexts. However, the old mechanisms are still available in case you need them.

The release also adds methods to enumerate (and count) all contact manifolds in a PhysicsSpace. These methods are intended for debugging rigid-body contacts and may also prove useful for collision detection.

The release also fixes a couple minor bugs. (See the release log for details.)

It’s named “4.7.1” because the “4.7.0” release suffered a build failure. I apologize for any confusion or inconvenience caused by the numbering gap.

12 Likes
2

Neat.

Note that with kinematic objects you can set the kinematic object’s velocity which will also simulate conveyor belts. That’s what I used for the conveyor belts in my Jaime 3D platformer example.

2 Likes
3

Kinematic bodies are OK for a platformer game.

Dynamic bodies provide more realism:

  1. They collide with each other and react accordingly.
  2. They’re affected by gravity, so they tumble and/or fall off the belts when appropriate.
  3. They have momentum, so they resist changes of motion (both linear and angular) when entering/exiting a belt.
4

It’s very common for conveyors and moving platforms to be kinematic objects in platformers… but you are right. If the player can bump into and knock over your conveyors belts then kinematic won’t work.

But for the cases where a conveyor belt is otherwise a static object, making it kinematic and giving it a velocity will impart that velocity to any regular rigid body sitting on it. It’s a cool trick that most people don’t know about.

5

I was referring to the objects riding on the belts being dynamic or kinematic, not the belts themselves. In the Bullet and Minie demos, the belts are static bodies.

6

And just so we’re clear.

I’m talking about:
kinematic conveyor belt with a velocity set.
regular rigid bodies on the conveyor belt.
…they will move like they are on a conveyor belt with no other special handling required.

I discovered this trick when trying to get moving kinematic platforms working properly.

1 Like
7

Nice to see the releases, thanks for your work :grinning:

1 Like