The Minie physics library

Can you please elaborate on this, how come it might break?

1 Like

If an application modifies one of the returned collections, that should work in Minie v1.6.1.

If the returned collection were made unmodifiable, the same code would throw an UnsupportedOperationException.

1 Like

I see, but anyway I think it’s really odd one wants to modify it knowing that it will have no effect. :wink:

You’re quite right that modifications have no effect on the CollisionSpace. But there might be other reasons to modify the returned collection.

Suppose an app developer needs a list of all rigid bodies except for the terrain. They might be tempted to write

    Collection<PhysicsRigidBody> allButTerrain = space.getRigidBodyList();
1 Like

Okay, I see.

One more question, (it might sound noob as I have not dealt with native codes and JNI stuff)

As I see the PhysicsSpace.destroy() method does nothing so just to get sure, will native memory used by PhysicsSpace be freed by GC automatically when I remove the reference to it and collision objects?

1 Like

That’s the intention. Native memory gets freed by the finalizer, not by destroy().

By the way, the destroy() method in jme3-bullet does more harm than good. It simply clears the Java maps:
jmonkeyengine/ at d6b0069407a445ed690e651d5995fb580e2af08b · jMonkeyEngine/jmonkeyengine · GitHub

If the maps aren’t already empty, destroy() puts Java and Bullet out of sync. Java thinks the space is empty, and Bullet knows it isn’t. If the “destroyed” space gets updated, collision listeners may be invoked. If new collision objects get added to the “destroyed” space, they may interact with the old ones…

Rather than replicate such anomalous behavior in Minie, I opted to make destroy() a no-op.

1 Like

I see, thanks for indepth explanation. :slightly_smiling_face:

1 Like

I enjoyed the dialog and got a valuable idea for v2.

However, this topic was already crazy long. For future reference, questions like these deserve a new topic!


Sure, I will do so.

1 Like

Centos 8 has been out for over a year now. Do you still need Minie to support Centos 7?

I’m thinking the Linux performance might be improved if the native libraries were compiled using a more modern GCC, but that would break Minie on Centos 7 Linux.


We have some Centos 7 computers still here, but mainly Debian will be used currently, and was able to compile Minie there.

1 Like