"b2DynamicTree::Query(T* callback, const b2AABB& aabb) const" has 128 element hard limit

[GoogleCodeExporter]

Occasionally I am encountering a hard-limit in the dynamic tree which I
believe happens when a query is made when too many objects exist close
together within the dynamic tree?   Sometimes this happens when something
has gone wrong on my end (or the users end) of things accidentally causing
objects to coexist close to each other.  Getting an assert (and therefore a
crash) in this instance is quite painful to the end-user as well as being
cryptic.

The dynamic tree has a hard limit in both the "Query()" and "RayCast()"
methods of 128 objects in the stack which results (typically) in 1K stack
usage.   If I bump this to 512 (4K) then this gets around most problems.

I am requesting that either we remove this hard limit completely or provide
either a central configuration for this value (b2Settings) or remove the
assert and provide some "overflow" feedback.

Original issue reported on code.google.com by melv....@gmail.com on 20 Nov 2009 at 8:51

[GoogleCodeExporter]

I modified the code so that you will miss collisions if you fill the stack. The 
assertion has been removed.

Usually this limit will only be reached if the user creates all bodies at the 
origin, 
and then moves them later. To avoid this, you might check the body definitions. 
Bodies should be created in place, not at the origin.

Let me know if this change is sufficient. If not, I can grow the stack 
dynamically 
using heap memory once the limit has been exceeded. I'd rather not do this 
because it 
will result in low performance.

Original comment by erinca...@gmail.com on 27 Nov 2009 at 10:33

• Changed state: Fixed

[GoogleCodeExporter]

I guess the main thing is that I don't get a crash.  It would be nice to know 
if this
limit was reached so I could log it, however I'm not sure that'd be easy to do.

It's a real shame there is a proximity bound here in the dynamic-tree 
considering the
extent bound was removed but performance is more important than convenience 
here.

It would be nice to be able to configure the static limit inside the settings 
file
though to make merges easier if this limit is changed.

Thanks for removing those asserts though, a crash on a user-error isn't so hot. 
:)

Original comment by melv....@gmail.com on 30 Nov 2009 at 8:17