Wrong collision with a very tiny bounding box

wrong collision with a very tiny bounding box, how can I prevent it?

I have a very tiny Box and use its bounding box to check for collision in control Update(float tpf) loop.
but sometimes it collide with sky that is so higher than the Box in Y position . and a Spark (Particle Emitter) that is hidden.

I had this issue at one point, and solved it by reworking the collision code in my ‘map’ class so that the sky, particle emitters, and any similar non-collisiom objects are not in the same node as the rest of the world.

I had previously done all my collisions against the root mode, but that becomes much less efficient as the scene grows, so your best bet would be to nest collidable objects in a mode and only collide with that node.

Alternatively, you could flag the particle emitter and the sky with a userData value, and write your collision code to ignore certain user data values when choosing the closest valid contact point. But this won’t offer any increase in performance since the collision check happens before you check the user data filter. But this is still an effective way of sorting different collidbale groups.
I use a combination of the both these ways in my project.

No , my question is why something not collide with box is in collision Results?

I can’t say I know why exactly so I’m just guessing - but my assumption was that the bounding box for a sky box or sky dome is going to be so large that it always intersects with anything near the camera. And I don’t know much about how the bounds are calculated for a particle emitter - but if the bounds are updated every frame based on the location of each particle, then I’d imagine particle emitters could cause inaccurate collisions.

I never saw a realistic need to check collisions with particle emitters or the sky, so I just moved them to their own Node that isn’t used for collisions

1 Like

you know, I use three boxes around a model to detect collision in path finding…

i removed sky box from the Vector3f.zero and solved its problem, but some times one of boxes collide with body of model.

Are you checking this collision against the model’s spatial, or against the bounding volume of that spatial?

If you are checking collisions with a bounding volume against another bounding volume (the model’s world bound’s in this case), then there is a good chance that the bounding boxes are overlapping and returning a valid collision, depending on the bounds of your model. Or the bounding box for the model might be calculated incorrectly to begin with.

A character that is modeled in a t-pose will have a wide bounding box to account for their arms sticking out, but then when your character is running animations and the arms are pulled in by its side, then the default bounding box will not be as accurate of a hit box.

None of them.

i use a green box in front of character model “f-box”. then in update method i check the collision with rootNode.

f_bound = (BoundingBox) source.getChild(“f_box”).getWorldBound();
rootNode.collideWith(f_bound, res);

is it possible to visualize a bounding box by a color?

according to https://wiki.jmonkeyengine.org/jme3/advanced/debugging.html

you should be able to use this method

     WireBox.makeGeometry(boundingBox);

edit: although I’ve never used that method, and I just tested it really quick and couldn’t get it to work. But I think the info you need should be in the debugging tutorial i linked

There’s a bounding box visualizer in the debug library of the jme3-utilities project. It’s a custom control.

import jme3utilities.debug.BoundsVisualizer;
...
BoundsVisualizer boundsVisualizer = new BoundsVisualizer(assetManager);
boundsVisualizer.setSubject(spatial)
rootNode.addControl(boundsVisualizer);
boundsVisualizer.setEnabled(true);

The source is on GitHub:

https://github.com/stephengold/jme3-utilities/blob/master/debug/src/main/java/jme3utilities/debug/BoundsVisualizer.java

or you can download the required JARs from GitHub:

https://github.com/stephengold/jme3-utilities/releases/download/heart-2.5.0/jme3-utilities-heart-2.5.0.jar
https://github.com/stephengold/jme3-utilities/releases/download/x-0.2.4/jme3-utilities-debug-0.8.9.jar

or Gradle it from my BinTray repository:

repositories {
    maven { url 'https://dl.bintray.com/stephengold/jme3utilities' }
}

dependencies {
    compile 'jme3utilities:jme3-utilities-debug:0.8.9'
}
1 Like

Just a hint: to me it appeared that the skybox is rendered as a sphere at 0, 0, 0 with ~10 radius. During rendering the transformation is probably just ignored to make it equidistant.

Btw: There should be a CollisionHint to add to your Emitters so they don’t collide anymore (just to rule that stuff out)

1 Like

yep true, I had the same issue. As a workaround I moved it to a point outside the game world. It is a bit strange that the skybox behaves that way.

1 Like

It’s not all so strange, you need a sphere in the vertex shader, as skyboxes are essentially a sphere (or rather skydomes, sky boxes are out of the 80’s) and the size is probably just randomly chosen.

I only wonder why those are collideable

1 Like