Box2D Forums

The manual entry on raycasting is a little confusing.

Suppose I want to find the closest point among fixtures meeting some criteria. In my callback, I return fraction if the fixture is acceptable and 1.0f if not. However, this occasionally produces incorrect results.

After reading it more closely and doing some experimentation, my theory is that this is a result of the callback being called out of order, and returning a higher value causes stuff to be unfiltered. So if it was called on a good fixture of distance 10, then a bad fixture of distance 8, and then a good fixture of distance 12, the second call would unfilter the last one and the final result would be 12.

It seems like this is a dangerous pitfall that should be emphasized more clearly in the documentation. It is not immediately obvious that you have to keep track of the cumulative cutoff if you want things to remain filtered.

I agree. Generally most concepts can be understood by taking a look at the demo test and its source code, but with this one I found myself still unclear about what was going on.

I think many people may not realize the flexibility the callback method provides and they are expecting to be restricted to only getting the closest fixture (the standard ray cast), so the fact that the fixtures are reported in an undetermined order should be mentioned. It would also be good to know what this means for the most common practical uses, ie:

To find only the closest intersection:
- return the fraction value from the callback
- use the most recent intersection as the result
To find all intersections along the ray:
- return 1 from the callback
- store the intersections in a list
To simply find if the ray hits anything:
- if you get a callback, something was hit (but it may not be the closest)
- return 0 from the callback for efficiency

(http://www.iforce2d.net/b2dtut/world-querying)

Personally I think most of my confusion would have been taken care of if the on-screen display in the testbed's Ray-cast test was fleshed out a little more, like:

m_debugDraw.DrawString(5, m_textLine, "Current mode: %s",
m_mode == e_closest ? "find the closest fixture along the ray":
m_mode == e_any ? "stop searching after finding any fixture (but maybe not the closest)":
"record intersections with all fixtures along the ray");
m_textLine += 15;
m_debugDraw.DrawString(5, m_textLine, "Note: the larger triangle fixture is filtered out and is always ignored.");
m_textLine += 15;

A common question is how to find an 'exit point', so a pre-emptive mention this can be done by simply reversing the ray might be helpful too.

By the way Storyyeller I think you should be returning -1 for the case where you want to completely ignore a fixture.

It would be nice if there was something that explained the relationship between body positions and
shape positions. I couldn't find anything that stated whether we're working with relative or world coordinates.

Thanks.

This is not about the manual, but the API documents that come with the 2.2.1 distribution.

b2Body::SetAwake() and b2Body::IsAwake() both function as they should but the descriptions have not been changed from referring to what I imagine used to be IsAsleep and SetSleep and so they are backwards.

Page 54.

b2Body* body1 = point->shape1->GetBody();
b2Body* body2 = point->shape2->GetBody();

should be

b2Body *body1 = point->fixtureA->GetBody();
b2Body *body2 = point->fixtureB->GetBody();

manual.pdf, page 55 of 66:

"This class requires you to implement a ShouldCollide function that receives two b2Shape pointers. Your function returns true if the shapes should collide."

Should be:

"This class requires you to implement a ShouldCollide function that receives two b2Fixture pointers. Your function returns true if the fixtures should collide."

The file:

Box2D/Dynamics/b2WorldCallbacks.h

Also mentions shapes instead of fixtures here:



and here: