Debug visualization for ranges of motion and local physics controls didn’t make the v1.7 release. These features are now slated for v2, along with kinematic collision filtering and the phantom-reference-based cleaner.
Minie’s current V-HACD algorithm was copied from the “master” branch of kmammou’s repo. Tonight I learned that his repo also contains a “performance-improvements” branch with several recent commits. I plan to test that branch. If it works well, I may use it in Minie v2.
I’m curious: is anyone other than me using soft-body physics? If you are, please let me know!
For v2, I’m contemplating changing PhysicsSoftBody.Material from an inner class to an outer class. But it’s not a high priority, and I won’t do it if it would break a lot of code.
Not yet but as the dev kit matures I’m probably going to try to create a physics plugin. It’s on my mind, at least, if not in the slightly distant future.
I tested commit id=5204acb (latest “performance-improvements” branch) on 7 concave meshes from the MinieAssets subproject. I compared with id=2731201 from the “master” branch (what Minie v1.7 uses).
Using identical tuning parameters, the 5204acb code completed quicker than current master on 6 out of 7 meshes, by factors of up to 11x. However, the quality of the results was worse, having more hulls in every case and 10x as many in a couple cases.
After I re-tuned the maxConcavity parameter to produce the desired numbers of hulls, the 5204acb code ran even quicker. However, the results were still unsatisfactory, since the resulting collision shapes did not match the input meshes as closely as those generated by the 2731201 code.
My conclusion is that the “performance-improvements” branch is faster in most cases, but its results are less good, even with some slight tuning effort.
Agreed. To my mind, V-HACD isn’t worth doing unless it provides similar quality to manual decomposition.
By the way, I recommend running V-HACD while importing models from glTF. Then you can store the collision shape (as user data) in the same J3O as the geometries. You might still want a background thread for loading, but the load latency should be minimal.
Hi Stephen, could you explain why you would use phantom references instead of weak references? I know the jME built in native object manager (for opengl objects) uses weak references, but I’m not sure why weak references are used there vs phantom either. I’m not familiar with the internals of Minie. Is there a reason you couldn’t use the NativeObjectManager?
I’m using phantom references because I want to detect when the referent ceases to be reachable. I want to avoid clearing the reference until the corresponding native object has been freed. By themselves, weak references don’t provide that capability.
I’m not very familiar with JME’s NativeObjectManager. I thought it was only for OpenGL objects. Was I mistaken?
It does say it is for GL objects, but it seems pretty extensible to any kind of native object to me. ALAudioRenderer also uses it. I don’t really understand it either. I just look and actually there’s some kind of stacked phantom and weak reference per native object… I’m not sure how this works right now.
Maybe a reusable native object handler can be added to that list of potential improvements for jme4 that someone had made…
I’ve come up with a workable scheme for managing Minie’s native objects using phantom references instead of finalize(). Unfortunately, it won’t completely eliminate finalize(). Minie still needs finalize() to avoid JME issue 1351.
The scheme is far more complex than I’d originally envisioned. It adds a metadata object for each native object, requiring a new class and a hashmap. The scheme also exploits reflection and adds a “Physics Cleaner” daemon thread. That’s a lot of moving parts!
I still plan to implement the scheme, but mainly as an experiment. Unless it shows compelling advantages over the current scheme, I might disable it or even rip it out before the v2 release.
Getting rid of finalize() keeps looking more difficult.
Since a PhantomReference can’t provide access to the referent, all the finalizeNative() methods need to be static, and most of them aren’t. Okay, that’s fixable, and maybe worth doing anyway. In fact, 99% of the native methods in Minie ought to have the static modifier added.
My scheme assumed that no Java object corresponds to multiple native objects. But Minie breaks that assumption, notably in MeshCollisionShape, PhysicsCharacter, and PhysicsVehicle. Again, a fixable issue, and maybe worth doing anyway, but more work for a benefit that keeps looking smaller.
As I recall, the general approach is to extend PhantomReference (or WeakReference as I’m still not clear on why that doesn’t work here) and in that object include the things you want to free, like the native pointers. So when the Reference is queued, you don’t have access to the original Java object but you do have access to the stuff that you need to free.
Thanks for your perspective, Paul. Your recollection seems right to me.
In com.jme3.util.NativeObjectManager, the subclass of PhantomReference is named NativeObjectRef. I’m also using the technique in Minie, since the “metadata objects” I mentioned all belong to a single class that extends PhantomReference.
One place I’m trying to be clever is by having a single metadata class shared by all the native types Minie uses. com.jme3.util.NativeObjectManager encodes the native type into the upper 32 bits of the native ID. That strikes me as a risky move. Instead, I record the Class of the referent in a field of the metadata. Hence the need for static native methods, invoked via reflection.
I’ll do some more research into the differences between WeakReference and PhantomReference, to make sure I’m using the right one.
The javadoc says PhantomReference should be used for these type of use-cases and then gives a reason way… and then seems to negate the benefit in the next paragraph. I’ve always had trouble wrapping my brain around that one. “Oh, phantom reference is special because it will get queued before your object is even reclaimed…” “So, then I can access it?” “No, of course not.” …
PhantomReferences are enqueued only when the object is physically removed from memory
The thing that puzzles me is this: if I used WeakReference in place of PhantomReference, could my cleaner thread reliably access the referent? Or is it possible that, soon after dequeuing a WeakReference, its get() method might return null?
If I can’t reliably access the referent, then I don’t see any advantage to using a WeakReference. And if I can, that’d make it easy to replace finalize(), at the cost of an extra GC before the referent gets removed from memory.
Edit: I re-read the 2006 blog post, and I think Nicolas answered my puzzle:
the reference object will be automatically inserted into the reference queue when the object to which it pointed becomes garbage