Crash due to tree travesal depth exceeding 256

[Frooxius]

Hello! It's me again after long time.

I bring you yet another issue stemming from user generated content x3

Recently certain world/items started causing hard crashes. I've narrowed it down due to a tree traversal depth being deeper than 256, causing stack to be stomped over here:

bepuphysics2/BepuPhysics/Trees/Tree_VolumeQuery.cs

Line 41 in ec5082f

Debug.Assert(stackEnd < TraversalStackCapacity - 1, "At the moment, we use a fixed size stack. Until we have explicitly tracked depths, watch out for excessive depth traversals.");

I've added workaround on our end by increasing the traversal depth to 1024, which fixed the issue with the specific content, but this only "delays" the issue, rather than fully solving it.

The code there alludes to explicitly tracked depths - is that something you'd be willing to prioritize at some point?

I'm not sure what the proper handling on our end would be - with user generated content, people can setup colliders in a way that will exceed the limit of 1024 as well (or whatever value we set it to) - we need to be able to handle it more gracefully than making the stack explode.

Would the system see if the depth is excessive and just allocate the list on heap? Meaning it'll be less efficient, but things being slower is better than everything crashing?

Or set some hard limit, above which the bodies will be ignored? Though that feels worse, because it'll cause odd issues, where some colliders randomly don't work.

[RossNordby]

Sorry for slowness! A brief response now:

1. I've seen this kind of thing in the past when something bad is happening to tree insertion. It really shouldn't be possible to trigger this error if the tree builder is working at all reasonably.
2. Allocating on the heap conditionally in response to depth would be a reasonable approach. Would really like to figure out how the tree's getting so messed up, though.

[Frooxius]

@RossNordby No worries, take your time!

1. I can make a repro case for you for this if you'd like to improve the tree handling. It'll take a bit though, I'll try to get back to you as soon as I can with it.
2. I think it'd still be beneficial to do, at least for our use-case. It makes handling of bad trees more graceful - just general slowness, rather than hard crash.

[RossNordby]

A repro would be very nice if you find the time! Another user was encountering something that smelled similar, but struggled to find a reliable repro.

And yes, would definitely also like to actually-fix the overrun!