I have several physics objects extended from RigidBodyControl implementing PhysicsCollisionListener and PhysicsTickListener. My code is derived from the “BombControl” example.
My physics objects (spheres, to be specific) have been moved to their own collision group with:
setCollisionGroup(PhysicsCollisionObject.COLLISION_GROUP_02);
Their collision properties are verified to be the default such that they should only collide with COLLISION_GROUP_01, aka, everything else in the world but not each other.
Indeed, as expected, these objects will not collide with each other, eg, they do not trigger the collision(PhysicsCollisionEvent event) method from PhysicsCollisionListener.
Excellent!
Now, the problem… they still do collide in a physical sense:
If a fast moving object approaches a slower object from behind in the same or near the same direction, the faster object will bump into the slower object and they travel fused together at the slower speed. If the direction is not perfectly parallel, eventually the faster object will slide around the slower object and will continue at its (faster) original speed.
So, apparently, some part of the physics engine besides the collision from the physics listener is involving itself. Any ideas?
Your answers are much appreciated
Read the javadoc, you have to set the CollideWithGroups too.
Thanks for your quick reply normen, but please read my post. I’ve read the javadoc thoroughly.
I do NOT want these objects to collide with each other at all. Hence, their CollideWithGroups bitmask is set to just collide with group 1 ( getCollideWithGroups==1, the default). And also, if you read my post, you will find that they are correctly not “colliding”: not triggering a PhysicsCollisionEvent, but the physical objects are still affected by a different sort of collision (read the last couple paragraphs).
If I were to addCollideWithGroups(PhysicsCollisionObject.COLLISION_GROUP_02) then of course they collide again “normally” but this is not the behavior I desire.
Hm, try using the PhysicsCollisionGroupListener to avoid the collision. Also, the other object is a normal rigidbody? Is one set to kinematic mode?
Hmm, yeah, I did try PhysicsCollisionGroupListener but that didn’t help; I may not have implemented it correctly. But if I understand correctly, PhysicsCollisionGroupListener should only get the collisions that occur when an objects collision group overlaps the other’s bitmask; so if they are nonoverlapping, like now, it should never get triggered.
Maybe as another point of emphasis, when these objects truly “collide”, they should both be destroyed. My problem is that while they don’t collide, they are also not completely transparent to one another.
Both objects are of the same type, and in my test code, they are both copied from the BombControl class in the examples and the javadoc. They are both in kinematic mode (kinematicSpatial==true, the default) but if I setKinematicSpatial(false) the behavior I am describing is unchanged.
So they have a GhostControl attached too? And some are in kinematic mode?
That’s right
The GhostControls don’t seem to be colliding though; they are used for the explosion effect and are much larger than the parent object
It does seem to be related to both objects being moving kinematic objects…because for example, if I removeCollideWithGroup(PhysicsCollisionObject.COLLISION_GROUP_01), which is the world, they freely pass through walls etc as one would expect.
Err… I thought you read the javadoc :P. Its a bitmask. You can set multiple groups in collision group and collide with group. Of course you have to remove the (Edit) collision group 01.
Edit: can you make a test case for this please
Haha no I thoroughly understand the bitmask. My objects in ( only ) group 2 are meant to collide only with objects in group one. What I was describing was a test case where I modify the bitmask so these group 2 objects collide with nothing which works fine but they still bump into each other.
I’m guessing it’s an issue with the kinematic physics where moving objects aren’t able to be inside one another regardless of collision bitmask. I will type up an example later.
Yes thats why I was asking these questions, because there is kind of a hack in jme’s physics to avoid characters colliding with ghost objects so the kinematic mode could very well have something to do with that.
Yeah that’s what I figured. Note that none of these objects are “characters”, but I think what you mean is that they would need a similar hack applied to function the way I was expecting.
Characters in bullet are kinematic RigidBodies with a GhostObject around it for collision checks.
So do you think if I make my objects RigidBodies and use a GhostObject for collision that would solve my problem? I thought about that before, but my thinking was that if it was the “RigidBody” part that was causing the problem then it wouldn’t really matter if I was using the RigidBodyControl or a separate GhostObject and a RigidBody.
No I think the problem is the kinematic flag. Some flags are parsed using methods that combine them, maybe the problem is there.
When you mentioned the kinematic flag, I did try setting it false on all the objects but that didn’t change the issue
But kinematic objects are handled specially when you add them, did you just not set it at all or did you just set it to false after adding?
Set it to false after the control was added to the spatial.
Yeah, dont set it at all