rayTest is fuzzy, reports "Halo" around btBoxShapes (SOLVED)

[paniq]

I successfully integrated Bullet (2.75) a few days ago, but I'm occasionally running into troubles. This is one of them.

I am putting small boxes of about 2x2cm (0.02x0.02 units) in size (1x1cm in half-size!) on a flat ground (Z-)plane, with a rather low gravity going towards the z-plane.

Now, when I cast straight tangential rays through the Z-plane (1 to -1, into the screen) using btDiscreteDynamicsWorld::rayTest, it appears for coordinates apparently lying outside of a placed rigid body, the body is returned instead of the ground plane below it.

Shooting random rays onto the ground plane and illuminating the points of contact, it appears the ray paints a "halo" of about 0.01 units around each box, with rounded corners at the edges. The halo size is independent of the box size. I've tried different sizes, and the halo always remains the same.

This is unexpected behavior. Expected behavior: when casting rays outside of a box, the ground plane is returned, otherwise the box on top of it is being returned.

What am I doing wrong here?

[Erwin Coumans]

Most of Bullet operations involve a collision margin, this could cause the 'halo'.

This collision margin can be set for each collision shape, but it is best not to change the defaults. Note that simulating such small objects is not well supported in Bullet, unless you use a very small internal timestep, for example using dynamicsWorld->stepSimulation(actualDeltaTimeInSeconds, 100, 1./800.);

Thanks,
Erwin

[sparkprime]

Is it possible that the default box collision margin is larger than the box itself, and therefore extends inwards through the origin and out the other side? heh...

You could try changing it form its default (0.04) to 0.005 for example

[paniq]

Most of Bullet operations involve a collision margin, this could cause the 'halo'.

This collision margin can be set for each collision shape, but it is best not to change the defaults. Note that simulating such small objects is not well supported in Bullet, unless you use a very small internal timestep, for example using dynamicsWorld->stepSimulation(actualDeltaTimeInSeconds, 100, 1./800.);

Thank you, that's good to know. Will this also fix the margin?

unfortunately, the objects actually have that size in my simulation, as i'm imitating objects on the actual screen surface (19") to move, using anaglyph rendering to give the illusion of real depth. You can imagine, it is confusing and troublesome to scale up every unit at all points of the simulation in order to make the engine behave as expected.

Is it possible that the default box collision margin is larger than the box itself, and therefore extends inwards through the origin and out the other side? heh...

You could try changing it form its default (0.04) to 0.005 for example

Resizing the boxes didn't give me the impression that this was the case, but what Erwin said could be the reason.

[Erwin Coumans]

Thank you, that's good to know. Will this also fix the margin?

With objects that small you have to make more effort to create a robust simulation. Just try using a smaller margin, and if necessary use the smaller fixed internal timestep, and see if that helps,

Thanks,
Erwin

[paniq]

I tried to use btBoxShape::setMargin, but it had no effect. Scaling up iterations does take a considerable amount of CPU, while looking like crap (everything just falls down too fast).

So I figured, since I dropped the gravity from 9.8 to 0.1 anyway to make it look good, I could as well try to scale up the units. All values now run through a macro that scales them to a sane size (*100, so 1cm is simulated like it's 1m), so now the boundaries are proper, and the collision behavior makes sense.

Scaling up everything mildly clutters the codebase, but allows me to globally adjust scales and weights, while still thinking in macroscopic units.