Good feedback. To address this issue, I’ll make sure to use 1.7 when building future releases of Minie.
ClothGrid should work for simulating most cloths that have
- a roughly rectangular shape and
- 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.
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.
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!).
SoftBodyControl working well enough to demonstrate:
Version 0.9.2 was just released. It’s available from GitHub, BinTray, and JitPack:
- built for compatibility with Java 7 (I hope!)
For more details, see the release notes:
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?
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.
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:
and here is the exception:
java.lang.IllegalArgumentException: No horizontal translation of heightfields.
Thanks for the report. I’ll investigate.
Update: it may be an unnecessary exception. Before I remove it, I want to make sure.
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.
If it’s indeed unnecessary here I’d be curious to hear why!
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 …
Neither could I when I looked 2 years ago. (But, the reason I looked into it was because I had problems doing just that…)
Look forward to hearing your findings!
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.
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 !
Thank you so much Stephen. I will check it soon and report any issues I find
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.
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?
Very cool update.
Like I said, I’m unsure. If you’d like to experiment with double precision physics, I can show you how.
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.