Heart dependency - any plans?

Recently i noticed that Heart lib is dependency for jme3-core. (we currently have 3.5.2 if im not wrong)

Is this possible for us to “inject” it into jme3-core if its needed?

I belive since Minie is “default” way for physics now, it could be good to manage it somehow.

Wait, since when is jme-core dependent on Heart?

or maybe i read it incorrectly and Heart need jme3-core? (but as i know Minie had possibility to run out-of-jme, so i think i read it properly)

i started using Intellij IDE since you suggested, and its great, but im not familiar how to read it.

1 Like

I’ve never used the dependency graph before, I’ll have to play with that today.

A Gradle build scan would tell us for sure.

1 Like

Open the command line with JME checked out.
Run gradlew dependencies

It will list all of the dependencies. Easy to read. If heart is in there then JME depends on it somehow. If not then it doesn’t.

1 Like

Heart lib is dependency for jme3-core.

It’s the other way around: Heart depends on jme3-core.

To make sure, I checked the jme3-core POM

1 Like

ok, so its like my second post.

isnt this problem for a “out of jme” Minie where i remember one guy were using? (it was Minecraft plugin if i remember correctly?). But well, its his problem then ;p he can use older version

The name of the “out of jme” Minie library is Libbulletjme.

Libbulletjme doesn’t depend on any other libraries—not Heart nor jme3-core. It incorporates copies/excerpts from the Heart/SimMath/jme3-core source code (classes like Quatd, Validate, and Vector3f), enough to build/test the core methods of Minie. That’s how it’s been since February 2020, which is when Yanis started using it in his Minecraft mod.

Though Libbulletjme has always been open-source, I didn’t originally plan on anyone but me using it. The name was clunky, the documentation was minimal, and I did nothing to promote it. Despite that, it’s my 2nd-most popular repo at GitHub, with 42 stars.

Back in April, I decided to invest more effort in Libbulletjme. Soon it will have its own website, with tutorials, javadoc, and so on. In the short term, this is distracting me from JME. But in the process I am discovering bugs and gaining new skills (particularly around GLFW and OpenGL) that may benefit JME in the future.


thanks for explain!

Im just curious, wouldn’t it be easier for You to have just one-physics lib instead of 2?

i mean for example have Libbulletjme as stand-alone physics lib, and Minie as “integration/extension api of libbulletjme” for JME?

i mean, what is the reason that there need to be 2 libs? is there so much different there? its not just Minie dupplicated code right?

1 Like

It takes little effort to keep Minie and Libbulletjme in sync. I periodically use a visual diff tool to compare the Java sourcecode. There are many diff chunks, but almost all are one-way. As far as Java sourcecode goes, Libbulletjme is very nearly a subset of Minie. (The build scripts are very different, however!)

When I converted Libbulletjme into a Java library, I took a copy of the Minie library soucecode, deleted all the debug dump/visualization code, the appstates, the scene-graph controls, the cloning/serialization code, and some stray references to Mesh and Spatial. Most of the effort went into selecting a minimal subset of com.jme3.math to enable it to compile.

EDIT: The math classes are a reason why code duplication between the 2 projects is necessary. Minie must depend on jme3-core for its math classes, while Libbulletjme can only use copies. Most of the other diffs could perhaps be solved using inheritance.

1 Like

again thanks for detailed explain :slight_smile:

1 Like