#OverlapSphere Physics Query Testing

1 messages · Page 1 of 1 (latest)

keen linden
#

Some physics query tests, primarily using OverlapSphereNonAlloc to detect colliders.
https://docs.unity3d.com/ScriptReference/Physics.OverlapSphereNonAlloc.html

Some Info:
• Program and testing all done in Unity's editor environment using a basic URP templated build and scene.

• Each graph is an accumulation of data throughout 100 tests where each sequence has a larger collider capacity to check against; upwards to 10k colliders at the end of the testing cycle.

• I've reduced as much overhead in the scene as possible, and for each test I yield between instantiations of colliders to prevent any hiccups upon executing a query. I'm also running these tests on a decently built (eh, good enough) computer using a Window's OS.

• I've selectively picked the least chaotic tests results to share as larger sample sizes do produce some hiccups which made these sample plotting graphs less compact than I liked.

Some findings throughout my time evaluating this data:
• Querying OverlapSphere doesn't have that bad of a cost, but there's no doubt that more colliders in the vicinity equates to more time it takes to fully evaluate.

• The cost of finding object colliders seems to be somewhat linear (at least with my sample size) but hiccups become somewhat more noticeable with larger amount of colliders.

• Layer masks and filtering colliders does help runtime performance by filtering out unwanted colliders... but, there is still some noticeable cost relative to filtering out those colliders.

• Square magnitude vs distance check comparisons; they seem very comparable so might as well just get the info you need. I think there's some discussion about ARM processors having trouble with sqr operations, but that's something my mate probably knows more about.
~

#

@full kraken

#

Some tests that I am interested in is the one with a single overlapshere with distance calculations versus doing some extra overlapshere queries to filter out objects in specific ranges.

#

Seems for my use case at the moment that doing extra queries is probably ok-ish... but there's still some possibility that doing range calculations could be warranted as the initial cost of overlap does seem to exceed a few distance operations. And, as I've commented above, there is a cost to OverlapSphere even if you were to filter out colliders, so having more of them could be problematic in a more dense scenario.