Physics colliders sometimes ignored?

Troubleshooting physics
1

So I’ve come across a really mind boggling problem recently, regarding physics collliders.

I’ve recently refactored the way I add box collliders to my CompoundCollisionShapes from the old gruesome code:

Box b = new Box(v.x,v.y,v.z);
Geometry t = new Geometry("",b);
t.setMaterial(MakeWorld.blankglow);
t.setLocalTranslation(pair.getKey().add(com));
shape.addChildShape(CollisionShapeFactory.createBoxShape(t), t.getLocalTranslation());

To this:

shape.addChildShape(new BoxCollisionShape(pair.value), pair.key.add(com));

According to CollisionShapeFactory.java this should be the exact same thing with less complications and garbage.

However now… some of the colliders may suddently not work all of the time!

Here you can see the side colliders going right through another rigid body:

Yet somehow the center one works fine, despite being created using the exact same code.

And some just allow everything to pass through them, like this tank.

And it’s not consistent either, these may work sometimes other times be completely ignored and I have seen no substantial correlations with anything.

They all show up on normen’s debug state just fine and I haven’t set any collision groups anywhere. I am just stumped.

Is there any other debug option for physics? Should I just jump from something really tall?

2

Welp, I’m getting nowhere trying to debug this. Back to the stupid old code it is. :confused: For anyone coming across this issue later on, I suggest the jumping idea. Probably the most productive.

My bet would be the jvm optimizing something it really really effing shouldn’t and breaking stuff on the way. Not sure how that’s possible and why the longer route would prevent it but ¯\_(ツ)_/¯.

3

I think the key would be looking at what each approach actually produces and then drilling into the differences in that.

4

Hmm well so far I’ve determined that the halfExtents vector the class keeps is identical in both approaches (it wouldn’t show up the same debug shapes otherwise), but I now see that it does inherit a margin float and vector scale. Maybe the scale ends up zero, I’ll have to recheck.

5

I’ve collected all params (object : halfextents : margin : scale):

Working:

com.jme3.bullet.collision.shapes.BoxCollisionShape@6138872d : (2.0, 1.0, 3.0) : 0.0 : (1.0, 1.0, 1.0)

Not working:

com.jme3.bullet.collision.shapes.BoxCollisionShape@7d11f518 : (2.0, 1.0, 3.0) : 0.0 : (1.0, 1.0, 1.0)

Doesn’t seem to be any difference at all. I figure it must be somewhat related with previous references, but it persists even if I clone everything I feed to the constructor.

Spooky

6

I’ve never used bullet so I’m probably asking dumb questions… but does a BoxCollisionShape in this case have a parent? Is the ultimate collision hierarchy the same in both approaches?

7

Should be the same yeah. The compound shape’s subshapes are all “attached” directly to it.

Pretty much as if you had a bunch of geoms under one node.

8

Yes, well, something is certainly different. I don’t know enough to say what… but something is definitely different.

9

Naturally. But see the thing is, it shouldn’t be.

That factory call continues here (in CollisionShapeFactory.java):

public static CollisionShape createBoxShape(Spatial spatial) {
    if (spatial instanceof Geometry) {
        return createSingleBoxShape((Geometry) spatial, spatial);
    } else if (spatial instanceof Node) {
        return createBoxCompoundShape((Node) spatial);
    } else {
        throw new IllegalArgumentException("Supplied spatial must either be Node or Geometry!");
    }
}

It finds the spatial to be a geom so it continues at createSingleBoxShape…

private static BoxCollisionShape createSingleBoxShape(Spatial spatial, Spatial parent) {
    BoxCollisionShape shape = new BoxCollisionShape(
            ((BoundingBox) spatial.getWorldBound()).getExtent(new Vector3f()));
    return shape;
}

Which returns the box shape with the same params that I make it separately. The geometry is detached from the scene graph so the extent is the Box mesh size.

10

From the images you posted, it appears that some of your rigid bodies are going inactive. This might happen if sleeping thresholds are set too high. Try setting them to zero.

11

No, that’s merely because i had to slow down to a halt to take a picture (and I was accelerating into the station in the other) and it doesn’t detect anything to collide with there, thus setting them to sleep. I keep the thresholds at default values.


No change.

Besides if this was the issue, I can’t think of why it would affect only specific colliders. And even it this was the solution it’s a really unusable one because of the performance hits it brings.

1 Like
12

Well you are using a different constructor for BoxCollisionShape, right? I can‘t remember all teh details but I‘d look into that and also look into if you might be using some shared vectors (e.g. from getLocalTranslation). Next thing I‘d check is threading if you construct your objects on a different thread or so.

13

Oops, that was actually a copying error in the OP. I’ve fixed that now. It’s the same constructor of one Vector3f. BoxCollisionShape only has one constructor with parameters.

Yeah I figured that may be the case as well, so I tried making a final cloned vector before passing it to the constructor which made no difference. Besides, I’m inserting these vectors from a hashset into which they were already cloned beforehand so there’s no chance they’ll be modified if everything runs as expected.

Hmm yes I construct the collision shape and assign it to the rigidbody in the rendering thread. Is that not how it’s supposed to be done? I’m currently runing physics in ThreadingType.PARALLEL if that makes any difference. I’ll test with sequential.

Edit: It seems like it worked marginally better with sequential, letting the physics object clip into the collider and then jam it there, but overall not that different.