Does anyone understand the Dynamic Ambient Light

[Sotha]

Does anyone understand Dynamic Ambient Lights. Please comment only if you are *sure* you know how it goes. If you only *THINK* you know, commenting will not help as I need to know exactly how this thing works.

 

http://wiki.thedarkm...c_ambient_light

 

Few questions:

ambient_dynamic_light

 

A factor with which each light in the current zone is multiplied before being added to the ambient_light. Default is "0.01 0.01 0.01". Use for instance "0.04 0.01 0.01" for a reddish tinted ambient light. If you want to turn this feature off (but you really shouldn't, instead set ambient_light_falloff = 2 and use a sensible default), then use "0 0 0" as spawnarg.

 

Does this mean if my location has 10 lights, the dynamic part of the ambient_dynamic_light will be 10 x "0.01 0.01 0.01" = "0.1 0.1 0.1" ? This is on top of the ordinary ambient_light. In this case if I had an ambient_light of "0.05 0.05 0.05" the end result would be "0.15 0.15 0.15."

 

Does it count only lit lights or are all lights counted regardless are they on of off?

 

ambient_light_falloff

Default: 0 (Best looking is 1, and it has exactly the same performance than 0! So you really should use a value of 1.)

Here is an overview over how the dynamic ambient light inside a zone works. To make it more clear, only a 2D cut is shown through the room, albeit the feature works in 3D:

 

So basically does this mean that the dynamic part scales based on player distance on any light present. So when the player goes closer to a torch, the shadows get more lit because the dynamic part scaling increases? The closer the player is to any light in the zone the brighter the ambient light gets (as allowed by ambient_dynamic_light_cap).

 

The example pictures talk about "rooms." Does it really mean "zone?" (as in location system zone, separeted by location_separators and having a unique info_location?)

 

All these have big ramifications. For the dynamic light system to work like it should, every single room must be encapsulated into a separate location. If a bigger location is a separate location (like "1st floor", "2nd floor", etc) all the lights are counted on the WHOLE FLOOR causeing the ambient_dynamic_light being capped at all times. Is this correct?

 

Please, someone clarify. Because the dynamic lights are enabled by default everyone are affected by this and if they aren't following strict location encapsulation, their maps dynamic portion is maxed at all times. Or maybe I just don't undertand how it works.

 

It is not feasable to use the location system to separate every single room into its own location zone.

[Obsttorte]

ambient_dynamic_light

 

A factor with which each light in the current zone is multiplied before being added to the ambient_light. Default is "0.01 0.01 0.01". Use for instance "0.04 0.01 0.01" for a reddish tinted ambient light. If you want to turn this feature off (but you really shouldn't, instead set ambient_light_falloff = 2 and use a sensible default), then use "0 0 0" as spawnarg.

You have the basic ambient light set in "ambient_light". Then, for every lightsource the ambient light around that specific source is increased by the specific factor.

 

But this does not extend over the ambient_dynamic light_cap.

 

Example:

 

If the falloff is zero as per default (not a good choice with lots of light sources) and you have ten light sources, there will be an extra light of "0.1 0.1 0.1". If your ambient light is "0.05 0.05 0.05", this makes "0.15 0.15 0.15". But this value is than capped by the ambient_dynamic_light_cap. The default value is "0.1 0.1 0.1". So your ambient light in this area would be "0.1 0.1 0.1".

So when the player goes closer to a torch, the shadows get more lit because the dynamic part scaling increases?

No. This means the distance from a specific point to the light source.

The example pictures talk about "rooms." Does it really mean "zone?"

Yes.

For the dynamic light system to work like it should, every single room must be encapsulated into a separate location. If a bigger location is a separate location (like "1st floor", "2nd floor", etc) all the lights are counted on the WHOLE FLOOR causeing the ambient_dynamic_light being capped at all times. Is this correct?

Yes and no. If you keep the falloff at zero, this will happen. But not if you set the falloff to 1 for example. Then the ambient will dimish in distance to light sources.

 

Note that I've never tested it, but it seems pretty clear to me from the wiki entry. (So somewhere in between know and guess ).

[Baddcog]

Can't tell you specifics but that dynamic ambient light IS all about zones. So yes by rooms he means zones. *Tels did all this if i remember correctly.

 

Pretty sure that the added multiplier is per light . I doubt Tels would have set it up so it stacked to .15. The cutoff is .01. He's pretty meticulous about his work and testing it. And I've never noticed really bright ambient set ups in any maps.

[Sotha]

If the falloff is zero as per default (not a good choice with lots of light sources) and you have ten light sources, there will be an extra light of "0.1 0.1 0.1". If your ambient light is "0.05 0.05 0.05", this makes "0.15 0.15 0.15". But this value is than capped by the ambient_dynamic_light_cap. The default value is "0.1 0.1 0.1". So your ambient light in this area would be "0.1 0.1 0.1".

 

I understood it does not cap the AMBIENT_LIGHT, but it caps the DYNAMIC PART of the AMBIENT_LIGHT.

 

No. This means the distance from a specific point to the light source.

 

Nope. I tested it. When the falloff is "1" the closer the player is to a torch, the more bright the shadows get. Strange looking. Test it.

 

So even this indicates that the wiki article is ambiguous as we resulted in completely different knowledge for the topic by reading the same source.

 

Confused.

[grayman]

Lights that contribute to the dynamic portion of the ambient light are in the same area as the player, where "area" is defined by the renderer.

 

This will NOT equate to the zones set up by the map author via location separators and location entities. The renderer doesn't know about those.

 

I can't tell you exactly what a "renderer area" is w/o further testing, which I can't do atm. I do know it's not the player's PVS.

 

For the purposes of the OP question, the best assumption is that it's those lights that fall on surfaces the player can see.

[grayman]

ambient_dynamic_cap only applies to the dynamic portion of the ambient.

[Tels]

As the person who created this system, I might know a few things about it

 

First some definitions:

 

* an area in render terms is the space bounded by visportals. If you have no visportals in your map, then the entire map is one aera. If you have one, it is two areas. If you have two visportals, you have three areas and so on.

 

Normally, but it is also possible to have a "loop" and only one visportal, which would not divide the map. It is like if you cut a cake from the center to the rim, then you end up with still one large, ring shaped cake piece, despice it being "cut". Only if you cut the cake all the way through you end up with two pieces of cake.

 

* a location consists of one or more areas, where the location boundaries must be marked with info_locationseperator entities. If you have none of these in your map, the entire map is one big location.

 

Like with the visportals, it is possible to have "invalid" location seperators, because they might not properly terminate a location if there is f.i. only one seperator but two ways (visportals) from one location to the next.

 

* the ambient light definition is always per location, because the info for the ambient light (and music etc.) is take from the location info entity (or falls back to the default value of the world_ambient light entity).

 

* The PVS (player visible space) consists of all areas that are visible (or could be visible) from the current camera pos (player eye). It is disjunct from locations, it can cover a whole location, or only parts of it, or parts of multiple locations. But it alwas covers whole areas, portions in an area that are not visible (because they are behind a wall) are culled during rendering. This is why visportaling is so important for performance. If the renderer can prove that an entire area is not visible, than it can completely skip it, instead of sending it all to the GPU which discards things then during rendering them. This also means lights outside the PVS are not rendered or taken into account at all.

 

The PVS changes with the player view, if you turn around, any visportal behind you is "closed", thus the areas behind you are immidiately removed from the PVS. Turn around again and they are included again.

 

 

---------------

Some more prefacing words: The ambient light we have in TDM is a crude hack. There is only one ambient light (unless the mapper adds local, fixed ambient lights, which most never do, because they are cumbersome, manual, error prone and after all, fixed.).

 

You can compare one fixed ambient light to having a store where all items have the same price (ambient) except a few selected (the lights). No matter where you set it, it will always be wrong, either too low, or too high. What it is good for, tho, is enforcing a minium price (so you don't end up selling everything for 0 €, in terms of TDM: have pitch-black shadows).

 

Having an ambient per-location is already better, it's like having one price per shelf, so the price is more likely coming closer to the correct price (although it will still be not 100% correct in almost all cases).

 

Now the dynamic ambient light portion is supposed to be small, and subtle, but still there to reflect changes in the lights surrounding the player. So if there are many lit torches, the ambient light should be a bit brighter (to simulate light bouncing of the walls), if the torches are extinguished, the ambient light should get darker.

 

 

This dynamic portion of the ambient light (and even the switching of the ambient light per-locaiton) cannot fix the fundamental limitation of having only one ambient light, tho. Even tho the light might more accurarely reflect the situation around the player, it will still be wrong for everything else. Basically, it is as if th shelf you are standing at has prices that are mostly correct, but if you look down the aisle, everything has the same price. If you walk over to another shelf,the prices all suddenly change to reflect the prices at the current shelf, but looking back you see that the first shelf now suddenly has the new prices, too.

 

This cannot be fixed without having either multiple dynamic ambient lights automatically calcualted and rendered (which is not part of the engine we have),or even better a full radiosity simulation, which correctly calculates light bounces from walls, through 3D fog etc.

---------------

 

Now, having said this, the dynamic portion of the ambient light is (unfortunately) set to the method that does not care about distance (and this is because Sotha objected to the "use the distance" method, a decision which I never was happy with, btw).

 

In al three cases (no distance falloff, linear distance falloff (which is not accurate but looks best) and quadratic distance falloff), the dynamic ambient light portion is calculated by computing a fake energy for all lights in the current PVS. current area. (Edit: Current area, because using the PVS has issues when no distance fall-off is used, as then distant lights visible will influence the result too much).

 

This has a few implications:

 

* changing the view point might change the PVS, hence the dynamic portion of the ambient light (that is why it should be kept small!)

* with distance falloff, moving around might change the dynamic ambient light, even when the PVS does not change (this is actually desired, althought due to the limitation of only a single ambient light for everything, this might look strange, because it will also change the ambient light look of distance parts.) Without the distance scaling, the dynamic portion only changes when lights flicker, go out or on.

* lights very close to the player can influence the result too strongly, this is a bug. (Actually, the bug was already tracked for the player lantern, this lantern is very close to the player, so it changes the ambient light overly strong). http://bugs.thedarkm...iew.php?id=2901

 

The fix for #2901 is probably very simple: enforce a minimum distance for lights taken into account.

 

Using the PVS has the nice benefit that a closed door will automatically close the visportal, take the areas out of the PVS and thus take these lights out of the dynamic part of the ambient light. Which is actually correct, if you close the door to the brightly lit hall from a dark cellar, you expect the cellar to get darker. (Edit: This is why I think now that a combination of PVS + distance fall off is best)

 

Using a different set of lights is almost impossible, tho. If we use "locations", then the dynamic light would change because you crossed a location, even tho the connection between locations could be a one-mile big gap (and thus light flow through it). Changing it to "the room" (what the wiki talks about) is impossible, because the engine has no defintion of "room", all it knows are areas and their sets (either a fixed set like a location, or a dynamic set like the PVS). (I used the term "room" in the wiki losely, because ideally it would simulate the light in the current room only. Probably should add some clarification to it). And if you would use it only for say "the current area", then visportaling the map would suddenly influence the ambient light even more as it does now, which is not correct, because open visportals do not block light.

 

That is why the dynamic portion of the ambient light should be with a distance based falloff - it corrects for the fact that even distant (and I say very distant lights!) could influence the dynamic ambient light, which is simply wrong. Under the given circumstances (only one ambient light) it is the best we can do.

 

(Note: Mappers can still override all this and create pitchblack shadows if they want. It is just not really accurate and should only be used for special effects).

 

I'll post a picture with some more explanations in a few minutes, plus a patch for #2901, need a coffee first. Hope that clears things up!

[Tels]

Addendum: I was wrong, the code actually only considers lights in the curent area, not the entire PVS. Oops. So that means the dynamic light will not change when you turn, it will only change if you cross a visportal. The minimum distance for #2901 should still be added, tho.

 

The code is in game/Entity.cpp around line 12020.

[Obsttorte]

Thanks for the clarification.

[Obsttorte]

I would change this

if ( !ent || !ent->IsType( idLight::Type ) ) {
  continue;
 }

to something like this

if ( !ent || !ent->IsType( idLight::Type ) || (ent->GetLightOrigin()-origin).Length() < minDistance) {
  continue;
 }

where minDistance is the minimum distance needed for the light to be taken into consideration. origin is the origin of the players eye.

[Tels]

I would change this

if ( !ent || !ent->IsType( idLight::Type ) ) {
  continue;
 }

to something like this

if ( !ent || !ent->IsType( idLight::Type ) || (ent->GetLightOrigin()-origin).Length() < minDistance) {
  continue;
 }

where minDistance is the minimum distance needed for the light to be taken into consideration. origin is the origin of the players eye.

 

Er, no, that would simple not take the light into account, which means if you move around a bunch of lights, some of the lights will be taken account, some not, and the light would vary a lot even when you move only 1cm.

 

I'm currently looking at limiting the distance to a minimum value of 160 units (dist3 =.. if dist3 < 160 then dist3 = 160). That way the light won't get brighter if the light is too close, but it will still be consistent.

 

Compiling takes still 18 minutes, whatever happene to the change Serpentine wanted to the build system? Shouldn't that one have been done months ago? *sigh*

[Obsttorte]

Ah. It seems that I've misunderstood you.

 

Nevermind.

[Tels]

Some more clarification about the "take all lights in PVS" vs. "take all lights in current area".

 

The PVS has advantages (it takes f.i. into account lights in the next room (behin a door visportal), but also drawbacks (like it changes with the player view and can be potentially large).

 

The "distance falloff" dimishes the drawbacks of the PVS, but since the default is "no distance falloff", I changed it back to "current area". This one has other disadvantages (the light changes if you lean through a visportal because as soon as your origin crosses the portal, you are considered in a different area!).

 

The more I think about it, the more it should probably be:

 

* no distance fall off - use only current area, to limit the effect that distant lights have at the current position (think: "long street with many bright lights at the end"). It still can be a large area, but for performance reasons mappers usually divide the map into small areas, anyway.

* distance fall off used - use the current PVS, since the distant lights won't contribute much, but the PVS also includes lights in the next room, and is less suspectible against rooms sep. with visportals for performance (think: large room divided into two parts for performance by visportal - this portal shouldn't exclude half the lights in the room depending in which half of the room you are).

 

That would be the best of both worlds, and do the best we can do under the circumstances.

 

To be it even more correct it would also need to take into account the "near" areas (think "the other side of the room behind you, which is not in the PVS because you look in the other direction"), but this is more complicated to compute then "is in PVS". For the latter we have already a function, for "is in the area that should be considered for the dynamic light" we would first need to come up with a definition, keep it computed and so on.

[Obsttorte]

I don't want to nitpick if this is the right word, but regarding the pvs approach I must say that this is very suboptimal.

 

Imagine you are standing in a room with lots of light on the one side and no light on the other. In real life, if you were looking at the lights, your eyes would get used to the brightness and this would cause the unlit areas in your view to become even darker. On the other side, if you were looking at the dark side, your eyes would get used to the darkness and you could see much better in the shadows (thus meaning they become brighter).

 

It seems to me that the current pvs approach does exactly the opposite. If you have lots of light in your view, everything gets brighter, while on the opposite in dark areas everything gets darker.

 

Just my two cents.

[Sotha]

Thanks, Tels! Lots of info to absorb.

 

Mappers will need to understand how it works in the simplest default level. That means no falloff, just standard dynamic behavior.

 

Is the stuff below correct?

 

1) Location system sets the "ambient_light" in a info_location_separator separated location. "Ambient_light" for that location is defined by the info_location entity.

2) A "dynamic portion" is automatically determined by adding all the lights in the visportal-separated area the player is in. The value of "dynamic portion" is the number of all lights in this area multiplied by "ambient_light_dynamic". If this sum is higher than "ambient_dynamic_light_cap", the cap maximum is set as the "dynamic portion".

3) The "dynamic portion" is added to "ambient_light."

 

So LOCATION sets the basic ambient_light level. The number of lights in the VISPORTAL SEPARATED AREA sets the bonus dynamic light level that is added to the ambient.

 

Examples:

For clarity I will use short hand notation of "0.05", which really is "0.05, 0.05, 0.05" for light colors. In these examples "ambient_light_cap" and "ambient_light_dynamic" are defaults, 0.1 and 0.01, respectively.

 

Example 1.

The player is in location of ambient 0.05. The player is also in a VisPortal area where there are three torches, all of them are lit. Thus "dynamic portion" will be 3 x 0.01 = 0.03. The ambient light the player sees is 0.05+0.03=0.08.

 

Example 2. Player douses all lights in the room.

Ambient light is now 0.05.

 

Example 3. The player brings in 10 candles, all lit.

"dynamic portion" goes 13 x 0.01 = 0.13. Too high, 0.1 is used instead.

Player sees ambient of 0.15, and it won't get any lighter by bringing more lights in.

 

Example 4. Mapper goes crazy and wants to make custom ultra-dark room.

He sets the ambient_light to 0, but has 3 lights in the dark room. Thus, the dark room has ambient of 0.03. In this VP area, the blackness is very sensitive to lights that are brought in or taken away (because there is no basic ambient_light.) With all the lights extinguished, the dark room would be completely dark. Bringing in 10 candles, will make it quite lit with an ambient of 0.1.

 

---

 

On falloff.

I tested it and I agree with Obst. It looks a bit strange that the shadows far away get lighter if the player is closer to a torch or other light source. The reason people have not complained, I think, is that it is not default and mappers probably have not dabbled with falloff settings yet.

[Tels]

Here is a drawing that tries to explain areas, locations and the PVS with visportals and location seperators. Is that picture clear or does it open up some questions?

 

 

Edit: a few notes:

 

* if the player moves up (north in same area), he can potentially see the visportal behind the door, so area A5 might become visible

* if the mapper removes the visportal between A4 and A5, then the area of A4 will cover both, and both will be visible through the door (even tho most things in A5 cannot be seen by the player).

[Obsttorte]

The "picture" would be clearer if it was actually there.

[Tels]

I don't want to nitpick if this is the right word, but regarding the pvs approach I must say that this is very suboptimal.

 

Imagine you are standing in a room with lots of light on the one side and no light on the other. In real life, if you were looking at the lights, your eyes would get used to the brightness and this would cause the unlit areas in your view to become even darker. On the other side, if you were looking at the dark side, your eyes would get used to the darkness and you could see much better in the shadows (thus meaning they become brighter).

 

It seems to me that the current pvs approach does exactly the opposite. If you have lots of light in your view, everything gets brighter, while on the opposite in dark areas everything gets darker.

 

Just my two cents.

 

The PVS aproach is only valid if you use distance falloff - basically it means "if there are lots of bright lights around/near you, the world gets a big brigher." (since this means "the entire visible world, it will be wrong for distant parts).

 

Without distance falloff, it will be even more wrong. (In my opinion I should never ever added the version without distance falloff, as it is simple wrong, no matter how you set things up or which "area" you use. If you use "only the current area" instead of PVS, that tries to fix the missing distance falloff be excluding anything that is not in the current area (which is usually far away).

[Tels]

Thanks, Tels! Lots of info to absorb.

 

Mappers will need to understand how it works in the simplest default level. That means no falloff, just standard dynamic behavior.

 

Is the stuff below correct?

 

1) Location system sets the "ambient_light" in a info_location_separator separated location. "Ambient_light" for that location is defined by the info_location entity.

2) A "dynamic portion" is automatically determined by adding all the lights in the visportal-separated area the player is in. The value of "dynamic portion" is the number of all lights in this area multiplied by "ambient_light_dynamic". If this sum is higher than "ambient_dynamic_light_cap", the cap maximum is set as the "dynamic portion".

3) The "dynamic portion" is added to "ambient_light."

 

So LOCATION sets the basic ambient_light level. The number of lights in the VISPORTAL SEPARATED AREA sets the bonus dynamic light level that is added to the ambient.

 

Examples:

For clarity I will use short hand notation of "0.05", which really is "0.05, 0.05, 0.05" for light colors. In these examples "ambient_light_cap" and "ambient_light_dynamic" are defaults, 0.1 and 0.01, respectively.

 

Example 1.

The player is in location of ambient 0.05. The player is also in a VisPortal area where there are three torches, all of them are lit. Thus "dynamic portion" will be 3 x 0.01 = 0.03. The ambient light the player sees is 0.05+0.03=0.08.

 

Example 2. Player douses all lights in the room.

Ambient light is now 0.05.

 

Example 3. The player brings in 10 candles, all lit.

"dynamic portion" goes 13 x 0.01 = 0.13. Too high, 0.1 is used instead.

Player sees ambient of 0.15, and it won't get any lighter by bringing more lights in.

 

Example 4. Mapper goes crazy and wants to make custom ultra-dark room.

He sets the ambient_light to 0, but has 3 lights in the dark room. Thus, the dark room has ambient of 0.03. In this VP area, the blackness is very sensitive to lights that are brought in or taken away (because there is no basic ambient_light.) With all the lights extinguished, the dark room would be completely dark. Bringing in 10 candles, will make it quite lit with an ambient of 0.1.

 

On a first brwosing, that appears all correct. In addition to what you wrote, the color is also respected. If you have f.i. blue torches in a dark, dimly reddish lit room (lava floor?), then the ambient will change color ever so slightly depending on which lights are on, and off.

 

Edit: And I should mention that both the ambient dynamic factor and the cap can be adjusted per location. In addition, you can adjust the color of only the ambient dynamic part, to simulate a "colored wall room". If you have a room with lots of blue wallpaper, then you can set "0.05 0.05 0.1" for the dynamic factor, so all lights brought in will contribute more blue to the ambient, even when their color is yellowish.

 

---

 

On falloff.

I tested it and I agree with Obst. It looks a bit strange that the shadows far away get lighter if the player is closer to a torch or other light source. The reason people have not complained, I think, is that it is not default and mappers probably have not dabbled with falloff settings yet.

 

The problem with "distant" parts is that these are always wrong, no matter what we do. So as a compromise I switch the ambient light to what it should be around the player (because that is what players mostly see/notice). For instance if you are in a area/room with yellow ambient light (indoors) and look at a room with blue ambient light (outdoors, moonlit), then outdoors will look wrong. If you go outdoors, and look back indoors, then indoors will look wrong. (Edit: The mappers solution to this dilemma is to use intermidiate rooms with a more neutral ambient so that the switch/view is not that harsh)

 

We can't have the cake, and eat it too, with the current system

 

Also note that people have not complained about the "no falloff (the default) because I tried tohide it's defieny by not actually using the PVS (as it was intended), but the current area. That swaps one problem (far away lights no longer contribute) to another (lights in the next area, which might be even part of the same room no longer contribute, just because they are one visportal further away, which might be 10cm).

 

The model with "no distance falloff" is just too simple to account for all scenarios.

 

Using PVS + falloff based on distance is much better. (Both models do not change the fact that distant areas will always look wrong because the ambient light is global but only computed local to the player pos. Depending on what you use, one will fail in this situation, the other will fail in another situation).

[Sotha]

Thanks again!

I think now I understand.

[Tels]

Thanks again!

I think now I understand.

 

Sotha, I just edited my last post and added a few more details, please reread it, as some things might have been still confusing

[Tels]

Obsttorte: picture added. Maybe someone wants to add this to the wiki (under visportaling info) and also tackle the other articles I wrote? It seems I'm not good at writing documentation.

[Obsttorte]

Wouldn't it be then better to replace the "no distance falloff" case by defining a standard falloff, which is used if the mapper doesn't specify his own values?

 

basically it means "if there are lots of bright lights around/near you, the world gets a big brigher."

If there are a lots of lights around you, the world is already bright. Decreasing the ambient light then would cause the contrast to be increased what may suit better here.

On the other hand, if the ambient light is increased a bit in dark areas, only weak lighted areas will look much more washed out due to low contrast, what may look good. As the ambient light also impacts the lightgem iirc, this would also simulate the effect of AI's eyes getting used to the darkness.

 

EDIT: This is a reply to post #18. I'm a bit slow these days

[Tels]

Wouldn't it be then better to replace the "no distance falloff" case by defining a standard falloff, which is used if the mapper doesn't specify his own values?

 

Unfortunately, the "no distance falloff" is the standard value used when the mapper does not specify anything and most don't even know they can change it.

 

Also, i probably should have made that a user choice, not a mappers choice, because how the light is simulated is something the user might want to influence globally (with the mapper only overriding it for specific effects). Right now you have to use what the mapper likes/wants, not what you want/like.

 

If there are a lots of lights around you, the world is already bright. Decreasing the ambient light then would cause the contrast to be increased what may suit better here.

 

Actually, no. In real life shining one light at a white wall will light up the entire room, and not create hard shadows. The D3 light simulation is way too simple and not correct. (We might want to keep a few things for gameplay reasons, after all, you must hide in shadows. But having a single bright torch divide the room (esp. a small room) into black and white isn't correct not does it look good.

 

On the other hand, if the ambient light is increased a bit in dark areas, only weak lighted areas will look much more washed out due to low contrast, what may look good. As the ambient light also impacts the lightgem iirc, this would also simulate the effect of AI's eyes getting used to the darkness.

 

Not sure if I get that. Anyway, the dynamic part of the ambient light should not influence the lightgem (at most one level), but only "look better". However, if you are standing in a small room next to three torches, the increased ambient should make it a bit harder to hide in a shadow. It all depends on the room (size, color), hence why the mapper can set this value for each location.

 

(One of the ideas behind it was that the mapper should have an push to extinguish lights in a room, because that makes it also a (tiny) bit easier to hide the shadows, as these are now "deeper".)

[Sotha]

Actually, the PVS does not work like that (counted from all areas the player can see). I did a bit darkroom testing.

 

 

Black are walls. Green is a visportal. L are lights. P is the player.

When the player is on the same side of the visportal as the lights, he sees the dynamic portion affecting the ambient_light of 0 value. The objects beyond the VP are visible (gray box).

 

When the player approaches the VP, the stuff is still visible in the next room.

 

The moment the player leaves the VP area where the lights are sitting and steps into the next area, the dynamic portion goes to zero as there are no lights there at all (black box). This suggests the lights are counted ONLY in the visportal area, where the player currently is.