Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice

Distance query optimization

Discussion in 'DOTS Physics' started by snacktime, Mar 31, 2020.

  1. snacktime


    Apr 15, 2013
    Actually I'm open to any type of query setup that would work.

    I had an existing profile to go from where I was using short distance queries for character controllers to detect ground and overlaps. Our design peak is around 400 characters and that many queries per frame was proving to be prohibitively expensive.

    I have another similar use case now where we have navmesh agents controlled by a crowd. We are using recastnavigation directly not Unity's system FYI. But for melee combat I want to assign arbitrary positions for attackers that match what looks/works best for gameplay. To do that well I need to detect nearby agents, which puts me back to looking at physics again to solve this. Using simpler spatial algorithms isn't cheap either, and the the more simple the less accurate which forces non ideal positioning (like using simple grid hashing for instance).

    For the navmesh agents I can do some further optimizations to reduce queries. Like only calculate attacker best position when the target has not moved for a few frames. So select the best position is cheap, but only do the overlap test once target isn't moving.

    In any case I'm looking for any trick possible to optimize distance queries given that I don't need any information on what was hit, just was something hit. Like possibly using specific shapes maybe really small colliders, hopefully the dev's have some insight on approaches to make distance queries cheap for this use case.
  2. MaxAbernethy


    Mar 16, 2019
    The fastest query is CalculateDistance(PointDistanceInput), it just tells you whether or not a sphere is intersecting anything. Capsule queries are also fast, it's the next simplest collider after sphere. The complexity of what's in the world you query is also important so filtering out stuff that's not relevant for your agents helps. Sometimes using a small number of combined static meshes is faster than lots of small ones.

    If some latency is acceptable for your queries, batching them up and processing them in a separate job could hide the cost, plus you get better cache coherency which is great because queries do a lot of random memory access.