 |
Problem 2 can't be streamlined. All lights need to be considered, because the resulting illumination is calculated only once per frame. If other AI are performing the same check in the same frame, they'll need the full calculation, because the distance to the marker will be different for each AI, so it can't be used to bail out of the calculation early. |
 |
Can the two checks be decoupled? 1) Check the illumination state (sum lights) and cache a value every n-milliseconds 2) AI just check marker, distance, and cached illumination value. |
|
|
Possibly. Atm, the marker fires a visual stim every N seconds, and AI see the stim. These things are checked, in this order: 1 - the odds that the AI will respond to the stim 2 - whether the AI has a LOS to the stim 3 - whether the stim is in the AI's FOV 4 - whether the stim is lit enough for the AI to see it I'd need to figure out if there's a benefit to always calculating illumination even though it's only used in check 4. AI failing any of checks 1-3 won't need the illumination, so is it worth it to spend the time calculating it when it might not be needed? Don't know (yet). |
|
|
Yes, I see. All the evaluations are consolidated in the AI SR cycle. The exclusion hierarchy is good if it really "excludes", it seems you're implying none of the upper-hierarchy are stopping the lower checks? That should be against design, no? (Maybe it got broken?) Still, it seems like you might overladen the AI if it also has to do the light calculation right at the end of that chain. Maybe make the absence marker "think" and only fire stims when it is above a certain light threshold? Hard to say how the cost benefit works out there or if there would even be a difference. My gut says that making every AI in proximity chew that whole line of evaluation is bad. |
|
|
Not sure what you mean by your 2nd paragraph. Establishing a threshold illumination for a marker to fire requires illumination calcs each firing regardless of whether there are AI around to use the result. If the threshold is passed, and a nearby AI makes it to check 4, the illumination calcs are redone. So we end up doing them twice, even if the first round is aborted when the threshold is passed. The AI aren't overloaded per se; something has to do the calculation during the firing frame. Whether it's done proactively by the marker or reactively by the AI (which asks the marker to do it) doesn't matter. |
|
|
The idea is that only one "thinker" in an area has to do the light calcs for the absence marker. The AI will only do checks 1 through 3 and will inherit a light value from the marker itself. (In addition, interleaved thinking on the marker (or equivalent) can lower the overhead dynamically.) Otherwise every AI in a scene will do that same light check calculation. This scenario is a performance gain for multiple AI but a likely a loss for single AI. |
|
|
"My gut says that making every AI in proximity chew that whole line of evaluation is bad." Each AI has to do them because each check is AI-specific. The only way to avoid having all nearby AI go through the checks is to rely on the first AI telling the others what he found, causing them to skip their own responses to the stim. But AI have to see each other for this to happen, and it's possible for 2 AI to see a marker when they can't see each other. |
|
|
"Otherwise every AI in a scene will do that same light check calculation. This scenario is a performance gain for multiple AI but a likely a loss for single AI." Since a stim fires and all AI w/in range respond in the same frame, the first AI making it through to check 4 will request an illumination value, which gets saved in the marker after it's calculated. When subsequent AI ask for the same value in the same frame, they'll get the cached value. When each AI is given the illumination value, it then uses its personal distance and visual acuity to determine if it can see the marker. |
|
|
Edit. OK that is actually better. So the first AI must go through the whole chain if other AI are near. 1) Are other AI near? Yes 2) Light level in cache yes \ no? 3) Light level calc 4) Probability 5) LOS 6) FOV No 2) Probability 3) LOS 4) FOV 5) Light level |
|
|
I'm not sure the time needed to check for nearby AI is well-spent. And, having found them, there's no way to predict whether they would be responding to the stim, since probability factors and sight lines also come into play, and those are handled individually by each AI. I'm going to leave things as they are. |
|
|
- ignore lights that are off - ignore entities marked “noshadows” when checking if a light source can see the marker - use the size of the missing item, not the default size of the marker rev. 4973: AbsenceMarker.cpp darkModLAS.cpp darkModLAS.h entity.h - remove an unneeded statement |
- Anonymous
