Faster to compare distance to all gameobjects of a type, or to use triggers?

[pseudo carbon]

just a question...
in my game I have gameobjects (grind rails) with trigger zones that they use to send data to the player's character controller when relevant. however, the workflow for creating the grind rails involves me placing a bunch of box colliders manually, since I've not found a way to automate/speed up this process (mesh colliders from a procedurally created mesh don't work, since mesh colliders can only be convex, meaning a whole bunch of unwanted space is filled in).

so, I've considered doing away with triggers altogether and simply comparing the distance between each rail in the scene (and then each segment on the rail) to find a suitable grind point, each frame when relevant.
I was just wondering if there would be any performance implications with this approach compared to trigger zones?
keeping in mind there would probably be 50-100 grind rails in a scene max, as a ballpark. (I would also only compare distance with individual grind segments if the rail itself is within a certain distance to the player, to avoid superfluous calculations).

[thin ridge]

Don't think I'm understanding this idea of calculating distance, but if you need to figure out an intersection you're using collider methods like trigger, or physics querying such as overlap sphere

If too many colliders are provided, then you do distance comparison on those, not every single collider in the scene

Well, here's the thing with trigger methods. It's called per object that intersects unlike a shape query where you do get a list of them back, so if there are many of these colliders close together and you need to do additional logic to sort the distance all out then you should query it instead of using triggers.

[thorny sun]

mesh colliders only have to be convex if they're part of a non-kinematic rigidbody

To answer the question, though: checking the distance to each object will eventually become worse than using the physics system

It might take a long time to reach that point

What you're describing sounds pretty reasonable to me.

Consider using a bounding box around the rail, though.

You can wrap a box around all of the rail points and then inflate it by a few meters

[subtle tulip]

Note that checking if two sphere colliders overlap is basically just a distance check, but you get partitioning etc so that it doesn't need to always check every collider. So my hunch is that placing a bunch of static sphere colliders would be out of the box always roughly as fast or faster than manual distance check.

[thorny sun]

Yeah – although I have to wonder if, for this specific use-case, using physics would ever actually be faster

if you had lots of entities all wanting to know if they're near grind-rails, things change

and if the query is more interesting than "am I within X meters?", that also changes the equation

[subtle tulip]

Just to get out of doing actual work – I tried it out with 100 box colliders vs comparing distances to 100 objects. No measurable difference either way.

[thorny sun]

A lot of things just don't matter(tm) if you're only doing them once

checking distances to a few hundred objects once per frame is a-ok

[subtle tulip]

Yeah the distance check was every frame

[thorny sun]

I've actually been in this exact situation more than a few times. I should go profile it some more

But I imagine it's negligible for the number of objects we're looking at here

(as Nitku just showed us :p )

[subtle tulip]

In fact not doing anything also made no difference to the frame rate so

[pseudo carbon]

are you sure? the Is Trigger option in mesh collider is always greyed out unless Convex is also true (adding a rigidbody doesn't seem to affect it, Is Kinematic true or not)

[pseudo carbon]

yeah I was thinking of doing something like that, only doing distance checks if we're vaguely close to the rail to begin with

[thorny sun]

oh, i didn't actually know that! i guess i'd never tried to make a trigger mesh collider before

[pseudo carbon]

my first thought was that I'd lose precision over the exact region by using spheres, but I could write a script to automatically place a bunch of sphere triggers along the spline...

that might be worth a shot then, since sphere colliders are fast, and it would save a lot of level design time

[pseudo carbon]

ahhh fair enough. it's such a pain, my life would be way easier rn if it was allowed lmao

[thorny sun]

that's how I'd do it, if I were using colliders

there's no room for creativity there, so you might as well script it

[thin ridge]

Comparing against every single collider in the scene seems insane though. You should just let the physics system sector out the static colliders, otherwise developing your own partitioning system so you aren't doing countless operation would be the next step.

Unless we're just talking about a handful of colliders, sure then anything goes

By chance doing distance calcs has some advantage, still there's very little reason to not use what's provided

Also think of all the arm processors that will explode with that many sqrt operations in a single frame D: