View Issue Details

IDProjectCategoryView StatusLast Update
0002853The Dark ModAIpublic16.09.2011 17:09
Reportergrayman Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityalways
Status resolvedResolutionfixed 
Product VersionTDM 1.06 
Target VersionTDM 1.07Fixed in VersionTDM 1.07 
Summary0002853: A fully-lit absence marker might not be seen by a passing AI
DescriptionIn some cases, an absence marker might appear to be fully lit to the player, but the AI can't see it.

Additional InformationThere are at least two problems:

1. The code determines if anything's blocking the light from the marker, considering this a "shadow". If the light's light holder is marked "no_shadows", then it should be ignored when determining shadows.

2. The code checks every nearby light, sums up the illumination, then sees if this is enough for the AI to see it by checking illumination (which is apparently how far away the light can be seen) against the distance to the observing AI. It isn't necessary to check every light. Just check enough lights to satisfy the distance check, then stop. If all lights have been checked, and the distance check still isn't satisfied, then the marker can't be seen.
TagsNo tags attached.

Activities

grayman

grayman

06.09.2011 16:32

viewer   ~0004017

Last edited: 06.09.2011 17:07

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.

nbohr1more

nbohr1more

14.09.2011 22:16

developer   ~0004022

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.
grayman

grayman

14.09.2011 23:36

viewer   ~0004023

Last edited: 15.09.2011 00:09

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).

nbohr1more

nbohr1more

15.09.2011 00:06

developer   ~0004024

Last edited: 15.09.2011 00:14

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.

grayman

grayman

15.09.2011 00:24

viewer   ~0004025

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.
nbohr1more

nbohr1more

15.09.2011 00:32

developer   ~0004026

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.
grayman

grayman

15.09.2011 00:35

viewer   ~0004027

"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.
grayman

grayman

15.09.2011 00:41

viewer   ~0004028

"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.
nbohr1more

nbohr1more

15.09.2011 00:42

developer   ~0004029

Last edited: 15.09.2011 01:42

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

grayman

grayman

16.09.2011 16:53

viewer   ~0004034

Last edited: 16.09.2011 16:54

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.

grayman

grayman

16.09.2011 17:09

viewer   ~0004035

Last edited: 16.09.2011 17:10

- 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

Issue History

Date Modified Username Field Change
06.09.2011 15:59 grayman New Issue
06.09.2011 15:59 grayman Assigned To => grayman
06.09.2011 16:32 grayman Note Added: 0004017
06.09.2011 17:07 grayman Note Edited: 0004017
14.09.2011 16:58 grayman Status new => assigned
14.09.2011 22:16 nbohr1more Note Added: 0004022
14.09.2011 23:36 grayman Note Added: 0004023
15.09.2011 00:06 nbohr1more Note Added: 0004024
15.09.2011 00:09 grayman Note Edited: 0004023
15.09.2011 00:14 nbohr1more Note Edited: 0004024
15.09.2011 00:24 grayman Note Added: 0004025
15.09.2011 00:32 nbohr1more Note Added: 0004026
15.09.2011 00:35 grayman Note Added: 0004027
15.09.2011 00:41 grayman Note Added: 0004028
15.09.2011 00:42 nbohr1more Note Added: 0004029
15.09.2011 00:44 nbohr1more Note Edited: 0004029
15.09.2011 00:50 nbohr1more Note Edited: 0004029
15.09.2011 00:51 nbohr1more Note Edited: 0004029
15.09.2011 01:42 nbohr1more Note Edited: 0004029
16.09.2011 16:53 grayman Note Added: 0004034
16.09.2011 16:54 grayman Note Edited: 0004034
16.09.2011 17:09 grayman Note Added: 0004035
16.09.2011 17:09 grayman Status assigned => resolved
16.09.2011 17:09 grayman Resolution open => fixed
16.09.2011 17:09 grayman Fixed in Version => TDM 1.07
16.09.2011 17:09 grayman Target Version => TDM 1.07
16.09.2011 17:10 grayman Note Edited: 0004035