Proper way of clearing PhysicsSpace

Troubleshooting physics
1

Hello monkeys :slight_smile:

We are developing a labyrinth like game with certain “surreal” and “paradox” elements, which is the reason for the necessity of steadily (depending on the players movement speed up to more than a few times per second) “rebuilding” the level segement, that the player is currently located in.
To clear the scene graph a simple rootNode.detachAllChildren() does the job pretty well, but we are looking for a pendant of this function for the bulletAppState or the PhysicsSpace object, which we did not find so far.

As a workaround, we wrote our own “clearPhysicsSpace” function, which consists of the following:
[java]
app.getStateManager().detach(bulletAppState);
this.bulletAppState = new BulletAppState();
app.getStateManager().attach(bulletAppState);

bulletAppState.getPhysicsSpace().enableDebug(app.getAssetManager());
bulletAppState.getPhysicsSpace().add(controlPlayer);
[/java]

The actual “updateLevelElements” function which rebuilts the segement of the level, that is supposed to be visible, is called from within the collision function, so it may, as already stated above, happen quite often.

The problem is, that the updateLevelElements function is, for some reason, only called for a limited amount of iterations, ignoring any player movement after being called approximately 20 times or so, while the collision of the player with the objects itself is still working, as can be deduced from the fact, that one cannot “walk through walls”.

We assume, that it has something to do, with us regularly deleting and recreateing the whole bulletAppState, which is why I ask you for hints on how to “properly clear the PhysicsSpace”.

Other hints on what the cause of this mysterious behaviour may be and how to fix it, are also welcome of course :slight_smile:

Thank you for your attention :wink:

2

You can recreate a physics space just fine, simply removing all objects should work equally well though. Everything you physicsSpace.add has to be physicsSpace.remove()'d obviously :slight_smile:

3

Is it realy neccesary to completely change the whole scene ?
Meaning if you use rootnode.detachAllChildren() you probably rebuild the whole scene from scratch every time and add it back.
I don’t know much about what you are trying to achieve, but to me that sounds like very much unnecesary work if there are only details changing in the scene.
Have you thought about just detaching those elements that change and attaching back the changed part ? That way you can then remove those elements from physics space and add the new ones too.

4

Just wrap a class around your physicspace, and store all added objects in an list, then clear(){ for all in list physicspace remove}

That way you can safe the recreation of the physicspace.

.

5

Wow! Thank you for all the helpful repilies!

ryukajiya, I am afraid, it is necessary, because we have paradox situations where laws of room and space are being broken… for example: you walk your way through a corridor and when you turn around, a whole different place is behind you. But we designed this to be perfectly deterministic:

The left exit of A may always lead to B, but the right exit of B leads to C, which is a physical paradox.
But when you manage to visit B another time and leave to the right, you will once again happen to find yourself facing C.

For this purpose we developed our own data structure for saving the composition of the labyrinth’s elements, but we also have to properly determine, which parts of the labyrinth shall be shown and where they must be attached, which is why we need to rebuilt pretty much the whole scenegraph when the player enters a certain region or turns around. We are aware, that certain optimizations can be made here, but still it would happen quite often during normal gameplay.

Thanks norman and Empire Phoenix for pointing out the obvious, of just using physicsSpace.remove() and maintaining a list of all objects currently added!
I wonder how we have not come up with that idea before :smiley:

I am looking forward to implement it tomorrow and will not leave you without feedback on your proposed changes :wink:

Thank you again everyone and have a good day/night (whatever your timezone is :P)

6

Thanks to you, we’re making progress over here :slight_smile:
I was forced to implement a bundle of optimizations, because otherwise it would tear the performance down too badly.
We are still seeing some problems concerning the positioning of the RigidBodyControls, but that seems to be a bug, too specific to the code of ours, to ask for help at this point.

Thank you so far everyone :wink:

1 Like