The Minie physics library

User Code & Projects Minie
41

Good feedback. To address this issue, I’ll make sure to use 1.7 when building future releases of Minie.

1 Like
42

ClothGrid should work for simulating most cloths that have

  1. a roughly rectangular shape and
  2. no holes or tails

such as a flat scarf, a flag, a wrap skirt, or a rectangular cape.

To simulate a Moebius scarf, a triangular pennant, a tube skirt, or a circular cape, you’d probably want a different mesh.

1 Like
43

I’m working on adapting @Dokthar 's SoftBodyControl to Minie. If it works, it’ll probably become the preferred way to add soft-body physics to imported models.

2 Likes
44

I’ve just switched my project’s client from Bullet to Minie. I don’t have a lot of time to play with this now (and time will be short the next few weeks), but once I’ve had a chance to do it justice I’ll give some feedback (so far so good - can’t beat a drop-in replacement with no need to refactor for changed package/class names!).

1 Like
45

I’ve got SoftBodyControl working well enough to demonstrate:

10 Likes
46

Version 0.9.2 was just released. It’s available from GitHub, BinTray, and JitPack:

Features:

  • built for compatibility with Java 7 (I hope!)
  • added SoftBodyControl
  • re-publicized PhysicsSpace.distributeEvents()

For more details, see the release notes:

6 Likes
47

Thanks Stephen. Still cannot work with java 7 because jme3-utilities-heart-2.28.0.jar requires Java 8… can you fix it in next release?

1 Like
48

The new release doesn’t depend on jme3-utilities-heart-2.28.0; it depends on jme3-utilities-heart-2.28.1.

Try jme3-utilities-heart-2.28.1.jar instead.

2 Likes
49

Now it seems OK but I’m getting an exception while trying to load the regular JME sample terrain here is the line which causes the exception:
terrain.addControl(new RigidBodyControl(0));

and here is the exception:
java.lang.IllegalArgumentException: No horizontal translation of heightfields.
at com.jme3.bullet.objects.PhysicsRigidBody.setPhysicsLocation(PhysicsRigidBody.java:1083)
at com.jme3.bullet.control.RigidBodyControl.setSpatial(RigidBodyControl.java:398)
at com.jme3.scene.Spatial.addControl(Spatial.java:769)

1 Like
50

Thanks for the report. I’ll investigate.

Update: it may be an unnecessary exception. Before I remove it, I want to make sure.

1 Like
51

You probably know this and I’m just missing context or whatever, but my understanding is that Native Bullet doesn’t support translation (or rotation) of heightfields. Unless something has changed (or I’m missing information) that makes it seem kinda important as a warning. :frowning:

If it’s indeed unnecessary here I’d be curious to hear why!

1 Like
52

That was my understanding too—at one time. But I can’t find that limitation in the Bullet documentation. Maybe there was a limitation at some time in the past, but not any more.

I still plan to investigate …

1 Like
53

Neither could I when I looked 2 years ago. :slight_smile: (But, the reason I looked into it was because I had problems doing just that…)

Look forward to hearing your findings!

1 Like
54

I believe I’ve got translation, rotation, and scaling all working for HeightfieldCollisionShape, so I should be able to remove the exceptions in the next release.

2 Likes
55

I’ve just published a bug-fix release (v0.9.3) which addresses the “No horizontal translation of heightfields” issue, among other things.

Thanks again for your help, @adi.barda !

3 Likes
56

Thank you so much Stephen. I will check it soon and report any issues I find

1 Like
57

Today I got Minie working with double-precision native libraries. I’m not sure how useful that is, since all physics coordinates get converted back to float when they’re returned to Java.

I also worked out how to automatically build both the “Debug” and “Release” versions of the native libraries—at least for the Gcc toolchain. The “Debug” libraries are huge, but they’ve already proven useful for troubleshooting native code.

As a consequence, the project has expanded from 6 native libraries to 20. For the moment, I’ll hold off on deploying multiple class-JAR versions for each release. However, the potential is there.

3 Likes
58

I’m no expert, but theoretically using double for background simulation should still make the simulation more accurate (will it matter much for our purposes? dunno), and should give a little more world design flexibility (although I still think it’s a good practice to try and keep physics simulations as close to 0,0,0 as possible, separate view from model, etc.).

Bullet native must support optional double precision for some reason, right? :grin:

Very cool update.

1 Like
59

Like I said, I’m unsure. If you’d like to experiment with double precision physics, I can show you how.

1 Like
60

I’m sure I’ll try that out eventually, but probably not for a little while. I’m also curious about how different JBullet’s relative performance is, so maybe that’s a good item to throw in with such a “benchmark” whenever I get around to that.

1 Like