GC sanity check

If in a control I do: (and its about all this control does!)

[java] @Override
protected void controlUpdate(float tpf) {
ttl-=tpf;
if (ttl<0)
spatial.getParent().detachChild(spatial);
}[/java]

I’m assuming both the visual (geom/spacial) AND its attached physics control will all be garbage collected

do I need to specifically remove the physics control ?

I’m using the native physics library I note some native wrappers expect you to .dispose() or similar, various objects so their native counterparts can be released is this the case using jME3 ?

tia

yes it would be available for garbage collection. the scenegraph doesnt try to cache your spatials or anything…

Though you’ll need to manually remove the physics control from bulletAppState. Not only would it leave a reference, but it would still be calculated in the physics engine which is likely not your desired effect.

sidebar though: garbage collection during the game is usually something you would be trying to avoid, not something you want to encourage to happen. Instead of trying to toss out the spatial, you might be better served to see if it can be reused.

You must explicitly remove physics controls from the PhysicsSpace

Edit: damn ninjaed

@icamefromspace said: yes it would be available for garbage collection. the scenegraph doesnt try to cache your spatials or anything..

Though you’ll need to manually remove the physics control from bulletAppState. Not only would it leave a reference, but it would still be calculated in the physics engine which is likely not your desired effect.

sidebar though: garbage collection during the game is usually something you would be trying to avoid, not something you want to encourage to happen. Instead of trying to toss out the spatial, you might be better served to see if it can be reused.

If you are not on android or other mobile crap devices, you can safly ignore this mostly, as the desktop vms are way better at garbage collecting. In fact it can even be faster than resuseing, since a object poool ususally needs osme kind of threadsafeness, new however can run completly sychrnonisation less on current vms.

Ah! good catch I had forgotten to remove the phys object from the physics world Doh! :slight_smile:

on the sidebar, defiantly if it were running on mobile, but the old caching allocations is a hangover from the java is slow nonsensical meme…

on the desktop with a large landscape and hundreds of physics objects I’m getting 1000’s of fps the time it takes to create and destroy 1 player shot every 200ms or so… not so much of a problem

…that said I’m thinking of making an abstract caching class to supply previously “disabled” objects, for when I do want to run it on a mobile platform

…that said would the caching take longer than GC…