Hello,
When I remove a spatial from a scene, the spatial disappears an screen
but it's still "there" for the collision manager, right?
The only way I found to avoid invisible objects which still can collide
is the following:
(The spatial in question is named "block" here…)
scene.detachChild (block);
block.setIsCollidable (false);
Sorry, normally pushing a thread is not my style to do…
But I wonder that nobody has any ideas about that?
Just my simple question: How do you remove a spatial completely (including collision detection)
out of the scene, detachChild() doesn't seem to be enough?
Maybe I totally messed up my code here and detachChild() would be enough, but not here
in my code because I did something completely wrong?
Out of town, atm. Won't be able to get to a computer for a week in about 1 hour. This is a simple request and easy enough to do, I'll look into it when I get back (hope you can wait that long). The Spatial just needs to call remove on itself in the CollisionTreeManager. (There will probably need to be some helper methods written, but nothing bad).
Ohhhh, slowly!! It's NOT urgent!! :-o
It's just a simple question, and I was wondering that nobody answered…
(which is untypical for this forum…) 
The jME forums are starting to become so active that sometimes posts get missed. (Granted… a certain percentage of the activity is useless banter about amphibians.) Pinging your topic after a couple days of no answer is ok I think.
the frog sees all…watch it Bard. 
I also discovered that detaching the child had no affect (except to prevent it rendering) - and the physical boundary still remained.
I found that the following code completely removed the physical attributes of a given node:
box = (DynamicPhysicsNode) boxes.get(i);
box.removeFromParent();
box.setActive(false);
Thanks, I will check that!
…but is this behaviour intended?
Im not sure, your best bet is to ask Irrisor (I think hes the physics expert).
Just for confirmation.
You need a spatial to remove itself from the CollisionTreeManager when removing the Spatial from the scene graph?
This is not related to jme-physics?
It gets a bit confusing because jme-physics makes use of ODE (and in turn OPCODE) for collisions.
I'll still work on handling removal from CollisionTreeManager, but I ask because if you are using jme-physics, that may not help you.
mojomonk said:
Just for confirmation.
You need a spatial to remove itself from the CollisionTreeManager when removing the Spatial from the scene graph?
This is not related to jme-physics?
It gets a bit confusing because jme-physics makes use of ODE (and in turn OPCODE) for collisions.
I'll still work on handling removal from CollisionTreeManager, but I ask because if you are using jme-physics, that may not help you.
I've added removal methods to CollisionTreeManager in CVS. See if that solves your problem (call remove after detaching from the parent). I'm sill a bit confused as to how your collision tests are ever reaching the point of testing against the tree if the spatial's are gone.
mojomonk said:
I've added removal methods to CollisionTreeManager in CVS. See if that solves your problem (call remove after detaching from the parent). I'm sill a bit confused as to how your collision tests are ever reaching the point of testing against the tree if the spatial's are gone.
Sooo, it took awhile, but now I'm here again…
Well I don't see where I could use this new "remove" method… I don't have an instance of the
CollisionTreeManager in my code… I just check collision in the following way:
INFO: "results" is an instance of "CollisionResults", and some german text may be within this code… but nothing
really important there…
As you can see, I use "calculateCollisions(…)" and "hasCollision(…)" of the the Spatial and the TriMesh class.
private void processCollisions ()
{
// Collision check
results.clear ();
ball.calculateCollisions (scene, results);
// First, we have a time period where we don't check collisions,
// if there has been just a collision,
// so we won't get a ball which gets "stucked" within walls.
if ((ball.lastCollisionTime + 0.1f) < timer.getTimeInSeconds ())
{
if(ball.hasCollision (player, false))
{
soundplayer.play (ball_player_sound);
// ball.direction.z = ball.direction.z * -1;
newPosBall = ball.getNextPosition (tpf);
// Check, if we reached a new act_level
updateLevelStatus ();
// Calculate deflection
calculateBallDeflection ();
ball.lastCollisionTime = timer.getTimeInSeconds ();
score += SCORE_RALLY;
}
else
{
if (newPosBall.z > Playground.front_border || newPosBall.z < Playground.back_border)
{
dbprint ("Ball misses player, player DEAD!"); // DEBUG
player.state = Player.States.DEAD;
player.lastDeathTime = timer.getTimeInSeconds ();
player.lifes--;
if (player.lifes < 0)
{
dbprint ("Werde jetzt den Spielstatus
CollisionTreeManager is a singleton, so just use CollisionTreeManager.getInstance() to obtain the reference to the instance. Then call remove(Spatial) on that.
Ahhh, okay. 
I will check this!! Thanks!
Hmm, no change…
if (ball.hasCollision (block, false))
{
soundplayer.play (ball_backwall_sound);
ball.direction.z = -ball.direction.z;
newPosBall = ball.getNextPosition (tpf);
ball.lastCollisionTime = timer.getTimeInSeconds ();
// TODO: Hmm, is this really the right method to get rid
// of the collisions? (detachChild isn't enough..)
scene.detachChild (block);
// block.setIsCollidable (false); // <-- Shouldn't need this anymroe..
// But this doesn't work!
CollisionTreeManager.getInstance ().removeCollisionTree (block);
}
Something else is happening, if you are detaching the node and removing the spatial from the collision tree, there should not be anything to collide against. I'll need a test case to go any further with this, all tests I've ran here work just fine. Can you put together a test case for me?
mojomonk said:
Something else is happening, if you are detaching the node and removing the spatial from the collision tree, there should not be anything to collide against. I'll need a test case to go any further with this, all tests I've ran here work just fine. Can you put together a test case for me?
Okay, I whacked together some demo code…
Note that this stuff is ugly… I condensed some stuff from my "breakout - clone - game" in ONE class so
I can post it here… And yes, the colors of the walls are very odd,
their real semi-transparent look got lost in this demo code…
But it shows the behaviour. Look into
"processCollisions()", in the last for loop there is a line
// Hmm, we seem to need this…
block.setIsCollidable(false);
If you comment this line out, you will get invisible blocks reflecting the players
ball (after hitting them first, of course).
The class should compile and run with fairly easy settings of your IDE, needs the "usual stuff"
at compile time (JME) and the lwjgl.jar at run time… of course the usual -Djava.library.path
parameter for the run-command has to be set.
(Code still too long for a post here… so you'll have to download it here:)
http://www.esnips.com/doc/8c467f0f-a6f1-4d9c-ad14-4f782e1e8a14/CollisionTest