Does anyone understand the Dynamic Ambient Light

[Tels]

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.

 

Yes, that is true, the current code works like that. The original intent was to use the PVS, the function is even named that way. But I later changed it because without a distance fall off, the PVS can be huge and a lot of distant lights get considered.

 

The first post from today of me is wrong, I posted an edit of it. (Will edit the post to make it more clear). Edit: Done, edited the first post. Also, this post was the correction, maybe it was just overlooked: http://forums.thedarkmod.com/topic/14563-does-anyone-understand-the-dynamic-ambient-light/page__view__findpost__p__306898

 

Right now, I am leaning towards changing the code to:

 

* no distance fall off => use the current area only (anything else is quite complicated, like finding out which area is next to the current area)

* distance fall off => use the entire PVS

 

In both cases, limit the distance to some minimum value, so a distance of 5 units will not overly brighten the dynamic part.

[Tels]

Just found another bug in the code: it did add all lights, including ambient_world. Since that has a huge radius, this could contribute quite a lot. The new code will now ignore any ambient lights and only add non-ambient lights.

 

Presumable we should also exclude fog or blend lights but I have no real idea how to find out which one of these a light is.

[Obsttorte]

In the editor fogs have the light flag "fog" while blend lights have the light flag "blend" and ambient lights uses "ambient". Don't know if this flags can be read out via a function or so.

[Sotha]

Sounds good, especially the part where very close proximity to light shouldn't cause too much brightening. That's prolly the most unnerving effect in the falloff system. Without the overbrightening, it will probably be a neat system.

 

This will be pretty cool now when one understands how it works. The mapper can design his rooms so that the room ambient lighting varies between a minimum and a maximum: ambient_world and ambient_world + dynamic portion. Leaving the ambient_world lower and dynamic cap higher will give the OVERALL amount of lights in the room genuine gameplay effect. The room could be impossible to sneak in at all if the player didn't somehow reduce the lighting.

 

The default dynamic setting is so mild it is difficult to spot any effect on the ambient lighting by the reduction of overall amount of lightsources. This is probably good so that dynamics don't ruin work for those mappers who don't fully understand its function.

[Tels]

Sotha, would you be willing to design a few testmaps and test the new settings?

 

@Obsttorte: There was already an IsAmbient() function added by J.C.Denton for idLight, I added isFog() and isBlend() and now exclude these blend lights are still in for now. But it should be already better.

 

The bug with adding "ambient_world" meant that depending on where this light was located, some areas got a much brighter dynamic part than they should have, just because ambient_world was in this area, opposed to the next, otherwise identicaly area. I've observed the effect before, but could never explain why it was that way.

[Obsttorte]

Sounds good to me.

[Sotha]

Sotha, would you be willing to design a few testmaps and test the new settings?

 

I can make a testmap, no problems, and I can test changes that work in the current TDM release.

However, I cannot and will not start fiddling with developer versions / SVN. Time is so scarce I have to draw the line somewhere. Sorry.

 

What kind of testmap you need?

[Tels]

I can make a testmap, no problems, and I can test changes that work in the current TDM release.

However, I cannot and will not start fiddling with developer versions / SVN. Time is so scarce I have to draw the line somewhere. Sorry.

 

No problem, although I'd need someone to test the new code, because we already know how the old one works:)

 

What kind of testmap you need?

 

The one with the box and the 3 lights and one visportal above would be a good start, also any other situations where you could describe how you think the dynamic ambient part should work/look like.

 

F.i. a cross-shaped one, or one with a long "street" and so on. All extremely simple, but using different ambient light setups, so the different scenarios can be tested.

[Obsttorte]

although I'd need someone to test the new code

Grayman and Springheel are working on some code changes anyway, so you could ask them.

 

EDIT: If someone can tell me were to get the latest code and how to compile it, I could test it myself.

[Sotha]

Here is a testmap:

[Link removed, see later for a new one.]

 

ROOM1

The player starts in a room with almost zero ambient light. There are 10 candles, which should make the door on the opposing side visible (ambient of 0.1). The niche between the rooms has a visportal: when the player steps on the other side, towards the door, the dynamic portion disappears and the player sees nothing.

 

ROOM2

Beyond the door is a general testing area. Visportalled cross-shaped corridor with a big room on the southern end. The area has standard settings and a standard "ambient_light" of 0.05.

 

ROOM3

The door on the north end of the cross-shaped corridor leads to a big room with multiple candles.

The idea here is to experiment with special dynamic min-to-max lighting. I fear there may be some bug with the dynamic light.

In this area, info_location has

"ambient_light" of 0.05

"ambient_light_dynamic" of 0.05

"ambieng_light_dynamic_cap" of 0.5

So I expected to have the ambient to be between 0.05 and 0.5 depending how many candles are lit in the room. This does not work and there does not seem to be any effect on the visuals upon extinguishing the lights.

 

This same thing applies to the lights in the general testing area ROOM2. Only in the small rooms where the ambient_light is very very low, the dynamic portion has some effect on the appearance. Based on my experience what an ambient of 0.1 should look like, the scene is too dark. Remember the first dark room? It was supposed to have 0.1 ambient from the 10x0.01 candles. But it looks darker than the standard "ambient_light" of 0.05 in the general testing area ROOM2.

 

Something is wrong: either I did it incorrectly or the system is bugged.

 

EDIT: stand by. Mapper error. Fixing..

[Sotha]

Okay, the map was flawed. Download this one instead:

http://www.sendspace.com/file/ix2ez6

 

Now the area in ROOM3 works. But still, the dynamic portion feels way too dark.

In the first dark room, the "ambient_light" is almost zero. There are 10 candles, so the "ambient_light" after dynamic portion addition should be around 0.1. But the ambient is much darker than the "ambient_light" of 0.05 in the next corridor.

 

Also I added a new room to the ROOM3 testing area. There is a small wooden boxy room in the middle of it. In that area, there is only an info_location with "ambient_light" of 0.5. ROOM3 ambient_light_dynamic_cap is 0.5 and ambient_light_dynamic is 0.05. With ten candles it should be 0.5. But it is much darker than the example ambient_light in the boxy room.

 

The dynamic portion isn't in line with the ambient_light. This makes it difficult for the mapper to gauge in the correct values for ambient_light_dynamic and *_cap in order to achieve some kind of custom effect.

[Tels]

The dynamic portion isn't in line with the ambient_light. This makes it difficult for the mapper to gauge in the correct values for ambient_light_dynamic and *_cap in order to achieve some kind of custom effect.

 

Have you tried torches and fireplaces? There can be two problems here:

 

* the ambient_light_dynamic is a factor and this factor might be too high or low (e.g. this value is multiplied with each light source, by making the factor 2x as big, you can raise the light each light source contributes by 2x)

* there is some scaling that computes how much "energy" a light source puts out. The scaling is done by radius of the light source, and lightcolor. Unfortunately, light color alone is not enough to distinguish a candle from a torch (both have almost the same color),and the radius is also in the same order of magnitute. In real life, a candle gives maybe 0.01 of the light of a torch flame, but looking at radius/color is maybe only a factor of 2..10. (I don't know the exact values off-hand). This means that if this scaling based on color+radius is wrong, then maybe we need to define an "energy" value for each light - this is what I wanted to avoid, because it is quite cumbersome and can go wrong, also lots of testing and tweaking.

 

So one of these (the overalf actor or the scaling) can be wrong. It can also be that 10x candles do not contribute as much, simple because if you bring in one torch, it overpowers everything, anyway.

[Sotha]

Oh, yes. Changing the candles into torches made the scene in ROOM3 more lit. (The room with custom settings.) After reading the wiki, I assumed the "ambient_light_dynamic" is per light, without radius or color taken into account. This info should be in the wiki, preferrably with the formula how the factor is defined.

 

Out-of-the-box defaults are so mild that 10 torches lit and unlit do not make significant effect on the visuals. The mappers need to customize to make the dynamic lights to have some kind of significant effect to their work.

 

So I dunno how useful it would be to make an "energy" spawnarg or something similar. Also any drastic changes to the current system should be carefully thought of and discussed with others in the team. Changing the defaults might cause suprising changes in existing FMs. Like said, dynamic portion with default settings is so mild, it is effectively as if the dynamic portion was disabled altogether.

[Tels]

Oh, yes. Changing the candles into torches made the scene in ROOM3 more lit. (The room with custom settings.) After reading the wiki, I assumed the "ambient_light_dynamic" is per light, without radius or color taken into account. This info should be in the wiki, preferrably with the formula how the factor is defined.

 

Not quite sure what you mean here. But yes, a candle contributes a lot less to the dynamic portion of the light than a torch. (Wether the amount is right in boht cases, or wether itmust be lower for torches and/or higher for candles, I don't know. Literally nobody EVER looked at this and gave feedback.

 

Edit: In real life a candle has a few magnitudes of order less light energy than a torch - but in D3 their color are nearly the same and the radius are not that far off, either. So the amount of "energy" computed by looking at these two values is maybe a factor of 10 away from each other. But this is about right, because candles in TDM are rather bright compared to real candles, probably to make up for the fact that we do not have real ambient (radiosity). If you created a real candle in TDM, it would be very dim, and since no light bounces of the wall, the shadows would be completely black. End of edit.

 

Out-of-the-box defaults are so mild that 10 torches lit and unlit do not make significant effect on the visuals. The mappers need to customize to make the dynamic lights to have some kind of significant effect to their work.

 

So I dunno how useful it would be to make an "energy" spawnarg or something similar. Also any drastic changes to the current system should be carefully thought of and discussed with others in the team. Changing the defaults might cause suprising changes in existing FMs. Like said, dynamic portion with default settings is so mild, it is effectively as if the dynamic portion was disabled altogether.

 

Well, I told you this ("the default fall off should be 1, not 0") a few years back when I designed the system And it is quite unfortunate that this is tested so long after it was released and cemented in stone by existing maps now *sigh*

 

Anyway, I'm still working on it. Here are a few things I've done so far:

 

* added a cvar (tdm_ambient_dynamic_falloff), defaulting to -1. If it is >= 0, then it overrides what the mapper sets. This is essential for testing, otherwise you always need to modify the map and reload D3 just to see the difference. Seeing it in real-time is much better.

 

* I've removed the "ambient_light_dist_scale" variable (and parameter to the function). The reasoning is, that this was a factor where you could scale the amount of light that gets contributed to the dynamic portion. However, that factor has a different magnitude for each falloff value, and was computed by script, unless the mapper set it themselves on the location entity. Unfortunately, the doc was not clear, f.i. in your map you have set it to "1" on the location entity. Since this is a fixed value, the magnitude will be right for some locations, and totally wrong (factor 10 or 100 off) for other locations.

 

But after all, if you take the magnitude of this factor out (which was computed automatically, anyway), all you are left with is a linear scaling factor, and one can achieve the same by just changing "ambient_light_dynamic" (which is a factor, afterall).

 

So now this variable is ignored, and the system will automatically compute the right magnitude in all cases. This avoids that mapper error, simplifies the interface and code a lot.

 

After the changes are done, we need to test old maps to see if they changed, but as long as the default case ("falloff = 0 - no falloff") is used, the results should be the same. I don't think anyone ever used any of the other cases, because either they were broken, or the usage was so arcane that no-one managed to do it, anyway.

 

So here is how the system is supposed to work:

 

* the ambient light varies between "ambient_light" and "ambient_light" + "ambient_light_dynamic_cap". The amount of dynamic ambient light is determined by:

 

* the magnitude of the light source (currently determined automatically by looking at color and radius of a light source)

* for each light in the area (no falloff), or PVS (linear or quadratic falloff)

* and can be adjusted by adjusting "ambient_light_dynamic"

 

The values in the C++ code need to be tweaked so that the default is the same for old maps, and linear+ quadratic case still look good w/o too much mapper interaction.

 

I'll post back when I'm done with the changes so it can be tested against old maps. Your testmap is very helpful, btw.

[grayman]

I'll post back when I'm done with the changes so it can be tested against old maps.

 

ambient_light_dynamic has been set to 0 on various location entities in 10 maps, probably where the lighting change when changing zones was too noticeable. (I had to do this in one room of In the North, and Remembrance has it turned off everywhere.) If the new math tempers the default lighting changes when changing zones, then that would be a good thing.

 

Otherwise, ambient_light_dynamic has not been explicitly set by mappers. Since dynamic ambient is an opt-out system and not opt-in, all existing location entities where 0 wasn't explicitly set are using the default values for dynamic ambient.

 

If the new default settings are going to match the old default settings, does that mean no maps will experience a change in appearance? Or will there be a change anyway because of the way the new math uses those default settings, and that's what needs testing?

[Tels]

ambient_light_dynamic has been set to 0 on various location entities in 10 maps, probably where the lighting change when changing zones was too noticeable. (I had to do this in one room of In the North, and Remembrance has it turned off everywhere.) If the new math tempers the default lighting changes when changing zones, then that would be a good thing.

 

The dynamic part of the ambient light is dynamic, meaning in real-time. Oppossed to the base ambient light, which gently fades from zone to zone. If we want to fix the "the dynamic part suddenly and visible changing at border crossing, then there are three ways:

1. reduce the amount of dynamic ambient light (I think we need to coin a term like DAL for this, I get tired writing it - however if we reduce the cap, then we reduce the dynamic of the system, it can only represent very very small unnoticable changes. Don't think we want this, if you light 10 torches in a chamber, it should change the ambient visible.
   
2. add some magic to store the old dynamic of the old zone, and then gently ramp it to 0, while keeping the new dynamic light, basically over time fade between the old (now static) and new (now the new dynamic) values.
   
3. Using the PVS + distance scaling will also fix this for any non-location visportal crossing, but can still show a sudden change if two neighbouring locatings have wildly different dynamic caps settings.
   

If we implement anything, it should probably be #2 plus #3, as #1 is not what we want.

 

(If the above is unclear, please ask me to explain it again)

 

Otherwise, ambient_light_dynamic has not been explicitly set by mappers. Since dynamic ambient is an opt-out system and not opt-in, all existing location entities where 0 wasn't explicitly set are using the default values for dynamic ambient.

 

If the new default settings are going to match the old default settings, does that mean no maps will experience a change in appearance? Or will there be a change anyway because of the way the new math uses those default settings, and that's what needs testing?

 

It's a bit early to tell, because atm it is unclear wether the old values/math were good and worth keeping, or broken and worth changing. For a first step I'd like to cleanup the code and simplify it to the point where one has not 5 different knobs to turn just to achive sane defaults.

 

However, it points to "the old code was bunk and needs to be changed". Here is a summary of things that were wrong/problematic:

 

* only the current area is considered. That means a room split by a visportal will have strange changes when you cross the invisible border. Likewise leaning into doors, around corners (with visportals etc). OTOH, if the room (area) is huge, all lights where considered, even if they are 100m away (at the end of a long street f.i.). Changing this to "use the PVS" has other issues (the PVS can be potentially huge), so PVS can only be used if you use distance falloff.

* The distance scale could easily be set wrong by the mapper, arriving at totally wrong values (dynamic ambient always at the maxium or at zero)

* the sudden dynamic change if you cross some boundaries (depending on the old/new settings in each area/location, area size, lights in that area etc.)

* The defaults "0.1" for cap, and 0.01 for dynamic_factor might be too high

 

Since the old settings where somewhat broken (in some cases), I don't see how we could ever match them. Bascially, if they were wrong we want to change them. OTOH, if they were good, we should keep them.

 

Of course maps using the old, default values should not have visible changes in appearance, except where the old behaviour was clearly wrong. (But I'm not sure we can arrive at a "this is wrong, this is right" point at the moment, because details are fuzzy).

 

Does this clear things up?

[Sotha]

I don't pretend to understand much the discussion anymore as it goes more into coding-technical business and that is okay for me.

 

I do have one idea for the basic default dynamic light levels to bring for your consideration.

 

The lightgem brightness has levels, right?

 

What if the dynamic lighting defaults were set so that in a standard room with 10 standard lights the "dynamic portion" would increase an amount.

The amount the "dynamic portion" would increase would be enough just to raise the player lightgem one level up.

 

In simple terms: by default, 10 lights in a area would increase the lightgem by once notch. The maximum capped dynamic light would act as a lightgem penalty of one. Dousing, say, one or two lights would drop the dynamic portion enough to remove the LG penalty.

 

I don't imagine that would be a game killer, as the player can always lower the lightgem brightness by one notch by crouching, thus negating the dynamic light penalty.

 

The good side is that the dynamic lights would get a gameplay effect and probably be more noticeable to the player. They stand in darkness, LG is almost dark. They put off one light. They stand in darkess, the LG is completely dark. I think ambient_light changes that cause LG change of one should also be strong enough to be detected by player. Surely it is a waste to have a cool dynamic light system but nobody notices it as the default settings are so mild?

 

 

Your testmap is very helpful, btw.

 

Great!

[Tels]

I don't pretend to understand much the discussion anymore as it goes more into coding-technical business and that is okay for me.

 

I do have one idea for the basic default dynamic light levels to bring for your consideration.

 

The lightgem brightness has levels, right?

 

What if the dynamic lighting defaults were set so that in a standard room with 10 standard lights the "dynamic portion" would increase an amount.

The amount the "dynamic portion" would increase would be enough just to raise the player lightgem one level up.

 

In simple terms: by default, 10 lights in a area would increase the lightgem by once notch. The maximum capped dynamic light would act as a lightgem penalty of one. Dousing, say, one or two lights would drop the dynamic portion enough to remove the LG penalty.

 

I don't imagine that would be a game killer, as the player can always lower the lightgem brightness by one notch by crouching, thus negating the dynamic light penalty.

 

The good side is that the dynamic lights would get a gameplay effect and probably be more noticeable to the player. They stand in darkness, LG is almost dark. They put off one light. They stand in darkess, the LG is completely dark. I think ambient_light changes that cause LG change of one should also be strong enough to be detected by player. Surely it is a waste to have a cool dynamic light system but nobody notices it as the default settings are so mild?

 

Basically, yeah, the "design" is so that it affects the light gem by maybe 1, at most 2 levels, so it is not game-play breaking, but still has an effect that goes beyond pure visual eye-candy. However "10 lights" is not a good definition, because 10 candles are equal to X torches (1, 2, 3?) and so on. But I get what you are saying and thats the goal.

 

 

 

Btw, the more I think about it, the more it sounds the old system is too complicated. The mapper should only have to set:

 

* the basic ambient (min. value)

* the dynamic cap (max. value)

* the dynamic factor (how fast it varies)

 

The rest, which area affects the dynamic portion, how it changes when the player moves etc should all be done automatically, and be right.

 

So I think I need to go a step back and list all the problems with the current system (and possible solutions) and then see which new system fits all these design goals, and still does not break old maps. But time is extremely limited and 20min compiling for each change does not help..