Performance: Triggers or radius searches?
by Daniel Buckmaster · in Torque Game Engine · 10/26/2009 (8:56 pm) · 5 replies
I'm working up an AI senses model, an wondering whether to get the senses to do periodical radius checks to find nearby objects, or whether to create a Trigger for the senses and have objects register themselves against it.
Advantages of Triggers:
-They're passive, not using performance when nobody's around
-They could be cached and only updated when the AI moved significantly
-Would work for fast-moving objects like Projectiles (with a little modification)
Disadvantages:
-Moving a Trigger over an object will not result in the object being detected
Right now I'm leaning towards radius checks simply for ease of use. I wouldn't be checking every tick for entities, either - a broad-phase search could be performed as infrequently as every few seconds. But it'd still be good to have some way to react to objects that relied on the objects saying 'hey, I'm here!' rather than having to search for them. I'm thinking about projectiles, mainly.
Advantages of Triggers:
-They're passive, not using performance when nobody's around
-They could be cached and only updated when the AI moved significantly
-Would work for fast-moving objects like Projectiles (with a little modification)
Disadvantages:
-Moving a Trigger over an object will not result in the object being detected
Right now I'm leaning towards radius checks simply for ease of use. I wouldn't be checking every tick for entities, either - a broad-phase search could be performed as infrequently as every few seconds. But it'd still be good to have some way to react to objects that relied on the objects saying 'hey, I'm here!' rather than having to search for them. I'm thinking about projectiles, mainly.
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
I also had a thought of attaching an AI Manager to all thinking entities or squads of entities, and having senses search for only those objects - then add all the managers' children to their potential list. Just another way of using typemasks, really.
I think a hybrid approach is needed for projectiles - maybe as well as the regular senses, maintaining a trigger to detect incoming projectiles separately from the entity search. Or something.
10/26/2009 (11:08 pm)
Quote:Checks are done in a grid system within the radius for speed - so it doesn't return the nearest thing first, so the check has to be completed and then the results analyzed - no interupting it.Yep, I guess that's a disadvantage. Also, depending on how typemasks are used, a radius search could be picking up lots of useless objects.
Quote:For players and other AI you might want to create a "master list" in an array of who is in the level, as something to check against.That seems like a good idea. I actually thought of just using the AI typemask that's aleady there, and applying it to all objects I want the AI to be able to detect - but that seems like it would be a coe-side solution, not as controllable via script. Unless I do some trickery with dynamic typemasks, etc. There's aready an AIAvoidThis flag in ShapeBase, IIRC...
Quote:You could also dynamically alter the updates on how far the nearest player is from the AI, thus letting them idle more when the distance is greater.I'm building an 'attention level' into my senses, so as less contacts are around, the AI drifts off and updates less often. I won't be using it based on player proximity though - I want to have AIs acting autonomously and fighting each other, etc.
I also had a thought of attaching an AI Manager to all thinking entities or squads of entities, and having senses search for only those objects - then add all the managers' children to their potential list. Just another way of using typemasks, really.
I think a hybrid approach is needed for projectiles - maybe as well as the regular senses, maintaining a trigger to detect incoming projectiles separately from the entity search. Or something.
#3
10/26/2009 (11:15 pm)
Instead of actively scanning for projectiles, why not let the projectile do the work - when the projectile is launched, get it to message all the AI's with its position and direction - the AI's can then decide if it's worth further attention.
#4
Using a trigger would mean that AIs don't actually have to look for projectiles. If the projectile hit a trigger, it would notify the trigger, which would notify the AI.
But then you have slower projectiles that you can see from further off. You don't want AI to react to bullets flying past a hundred metres off, but you do want them to see the giant glowing energy ball from that distance.
Oh, AI :P.
EDIT: What I really don't like is the fact that a radius search just checks all objects, meaning that on top of a sort of costly loop through all the objects around you, for each one of those objects you've gotta loop through the objects you already have to make sure you're not adding them twice :P.
10/26/2009 (11:56 pm)
Sounds like a workable idea, except there's the issue of projectiles that behave in odd ways - ballistic, bouncing, seeking, etc. Based on simple parameters, some AIs might make the wrong decision about projectiles with complex behaviour.Using a trigger would mean that AIs don't actually have to look for projectiles. If the projectile hit a trigger, it would notify the trigger, which would notify the AI.
But then you have slower projectiles that you can see from further off. You don't want AI to react to bullets flying past a hundred metres off, but you do want them to see the giant glowing energy ball from that distance.
Oh, AI :P.
EDIT: What I really don't like is the fact that a radius search just checks all objects, meaning that on top of a sort of costly loop through all the objects around you, for each one of those objects you've gotta loop through the objects you already have to make sure you're not adding them twice :P.
#5
11/23/2009 (9:21 pm)
As a small update on this, I've decided to go with my so-called hybrid approach. The senses will maintain a trigger object which is loosely aligned to their current position (say within around 10% accuracy). When the senses move outside this 'sweet spot' 10%, the trigger moves position, and a box search is done to find entities in the new trigger area. Sort of like the way collision information is cached by the Player in mWorkingQueryBox. That way we save on doing frequent box searches, especially in the case of stationary AI characters. And projectiles can be better handled. 
Associate Steve Acaster
[YorkshireRifles.com]
Checks are done in a grid system within the radius for speed - so it doesn't return the nearest thing first, so the check has to be completed and then the results analyzed - no interupting it.
For players and other AI you might want to create a "master list" in an array of who is in the level, as something to check against.
You could also dynamically alter the updates on how far the nearest player is from the AI, thus letting them idle more when the distance is greater.
Personally, I've been playing around with ditching radius checks all-together and checking distance of all players/AI in the Master List against the AI's own %range setting, is the enemy targetable? a quick LOS check, and then decide what to do and how long the delay between re-checks should be based on enemy distance. Performance seems excellent - though of course, this method won't detect any incoming projectiles.