Sweep question: Odd behavior and passing through colliders #346
-
|
Hi, I've got a bit of a question about how sweeping works, and subsequently a question about how to achieve a given effect. Firstly, are sweeps guaranteed to fire hits in any particular order? I'm currently working to expose a sweep where all you care about is the first hit to our users, but upon instrumentation of our sweep handler to debug what was going on, it appears that sweeps will sometimes query colliders that are further behind them first depending on where other colliders in the scene reside. I was following the example where you set In this picture you can see a sweep with this logic implemented querying a mesh-based collider past what would have been the first hit. This only happens when my character (which has a kinetic body and various other triggers/statics sprinkled in, I've verified these are within sane bounds and not infinitely huge or anything) is floating around the exact area as-pictured:
The problem locations change depending on the angle of the sweep and what else is in the scene, so I'm suspecting it's some funny behavior with the internal optimization structures bepu uses to query things. Secondly, if sweeps can indeed happen in no particular order, how could I ensure that they're ordered by their Given what I'm observing, my hypothesis currently is that sweeps really don't guarantee any particular order and that's why you have to sort out the minimum Apologies for the lack of code snippets, I'm on my phone and also can't legally post it here, but I've gone through and triple-checked the code path leading back to bepu and it all seems to follow very closely with the examples I've seen to achieve the "only the first hit" functionality we're going for. I do believe this behavior is originating from bepu's side at this point. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
Yup, there is indeed no guarantee of order reported by the hit handler. As an implementation detail, the acceleration structure visits nodes based on which node bounding box is hit first by the ray/sweep, but there's no guarantee that hitting an object's bounding box first will imply that the object's actual geometry will be hit first (or at all). The hit handler is meant to be a minimal and direct report, so more complex queries like "a sorted list of impacts up until a maximum T value" would require postprocessing of the collected hits. That's not done by default because, while it is cheap, it's still a nonzero cost and not required by many common use cases. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, thanks for the info in any case. I think we can probably just eat the risk of having it hit meshes (with an option to ignore them) and just inform people of the way it works. This is Resonite by the by, Unity 2019's mono 5.11 really neuters the mesh sweeping which is why I was initially concerned about it. We'll be moving the core engine out of Unity Soon™ anyways so it'll end up being far less of an issue anyhow. Tangentially, would you happen to know of any existing bugs or conditions that would cause sweeps to ignore colliders (particularly mesh-based ones) that should otherwise have been hit? I'm attempting to narrow down why sometimes it seems to not even query a collider at all when others exist down the line of the sweep. We use a slightly older version of 2.4 and I wanna make absolutely sure that it's actually within our implementation rather than something that's known. I realize that without any code it's kinda hard for you to say, but even just a confirmation that this isn't some condition that's known when you set the bingleblop setting to 88mph or whatever would be useful. Thanks for the quick responses. Big fan of this library. ^^ |
Beta Was this translation helpful? Give feedback.
-
|
I may have misunderstood something; if you're using something like the grabber's first-hit-only logic and the final result isn't reliably the first hit, that is unexpected and something is wrong. If the observed behavior is that a mesh is tested during the traversal but ends up being a later impact and ignored, and the issue is that testing the dense mesh is expensive, then that's working as expected. (Improving the performance of a sweep across a very large number of triangles in a mesh would require either a preprocessed internal mesh representation that isn't implemented yet, e.g. SDF-ish approaches, or using a simpler proxy shape for the physics.)
Haven't seen this. Can't rule out something like this existing in 2.3.X, but I don't remember seeing it there either.
🕺 |
Beta Was this translation helpful? Give feedback.
-
|
Okay, it looks like our initial fork of bepu is from a pretty long while ago and diverges very much a lot in the initial commit (which is where I suspect this bug is happening). Not asking you to look into it (unless you really really want to for some reason), just offering that I'm fairly sure it's on our end at this point with how many changes I've discovered. I appreciate the time you took to respond to my questions and I'll mark this discussion as resolved. I have a hunch it's potentially in some of our changes to bounds/overlap/leaf testing changes. |
Beta Was this translation helpful? Give feedback.
Yup, there is indeed no guarantee of order reported by the hit handler. As an implementation detail, the acceleration structure visits nodes based on which node bounding box is hit first by the ray/sweep, but there's no guarantee that hitting an object's bounding box first will imply that the object's actual geometry will be hit first (or at all).
The hit handler is meant to be a minimal and direct report, so more complex queries like "a sorted list of impacts up until a maximum T value" would require postprocessing of the collected hits. That's not done by default because, while it is cheap, it's still a nonzero cost and not required by many common use cases.