[Feature]: Allow darkness to affect Day vision

[kwvanderlinde]

Feature Request

I'd like to be able to use areas of darkness (light with negative lumens) on maps even which could be used with either Day or Night vision. Currently this is not possible since Day vision does not account for light sources and thus cannot remove areas of darkness from a token's vision.

The Solution you'd like

I would like to have areas of darkness with a lumens value of -100 or less to remain hidden from players in the Day, unless they have sight with a suitably high lumens value. This should make the default area of vision in Day behave like sight with the default lumens value.

Alternatives that you've considered.

Using VBL to occlude a given area could be done. But this is all-or-nothing and doesn't allow tokens with special vision to see into the area the way we can do with negative lumens.

Additional Context

This is what is looks like for a token with darkvision at Night with a -100 lumen source of darkness nearby:

At day the darkness hides nothing, even though it may not be intended for the players to see into it:

The request is to make Day obscure the area of darkness like this:

[adyoungblood]

Actually, I think making these changes would be immensely beneficial towards resolving #1908, as currently the Day and Night modes interact in a hard-coded way with regards to light and vision. The changes I'm envisioning would have fog be the default over the entire map, with Day mode adding a light (at 99 lumens, perhaps) over the entire map. Lights and sights would overwrite the fog aesthetically.

[FullBleed]

This all sounds interesting. I can see the intersection of your ideas working out quite well.

Actually, I think making these changes would be immensely beneficial towards resolving #1908, as currently the Day and Night modes interact in a hard-coded way with regards to light and vision. The changes I'm envisioning would have fog be the default over the entire map, with Day mode adding a light (at 99 lumens, perhaps) over the entire map. Lights and sights would overwrite the fog aesthetically.

Out of curiosity, why 99 lumens? Why not 100? If Darkness is -100 it seems that "day light" used this way should be 100.

[adyoungblood]

Out of curiosity, why 99 lumens?

I'd forgotten that equal light and dark combine to dark, so it should be 100 lumens.

[kwvanderlinde]

I've got a couple of questions, assuming it's agreed that this change is desired:

1. Should darkness also be kept when vision is Off?
   • The defining feature of Off would still be the lack of VBL calculations.
2. Should the new behaviour be the default or required a preference setting to be enabled?
   • ... or should it be disabled via preference?

In my totally objective and unbiased view, I would say:

1. Yes, make darkness work for all map vision settings. As a GM, when I put darkness somewhere I expect things to be dark. If I want to reveal an area of darkness, there are better tools than changing the map vision setting.
2. Make the new behaviour default. Same reason as in (1), really: I put sources of darkness where I want things to be dark, I find it surprising when it such areas aren't dark. And I would find preference useful only if the existing behaviour is considered desirable, but I don't see it. That said, changes like this have a tendency to run afoul of someone's expectations, so...

[FullBleed]

I've got a couple of questions, assuming it's agreed that this change is desired:

1. Should darkness also be kept when vision is Off?
   
   * The defining feature of Off would still be the lack of VBL calculations.

2. Should the new behaviour be the default or required a preference setting to be enabled?
   
   * ... or should it be _disabled_ via preference?

In my totally objective and unbiased view, I would say:

1. Yes, make darkness work for all map vision settings. As a GM, when I put darkness somewhere I expect things to be dark. If I want to reveal an area of darkness, there are better tools than changing the map vision setting.

2. Make the new behaviour default. Same reason as in (1), really: I put sources of darkness where I want things to be dark, I find it surprising when it such areas aren't dark. And I would find preference useful only if the existing behaviour is considered desirable, but I don't see it. That said, changes like this have a tendency to run afoul of someone's expectations, so...

My take...

1. Yes. Basic Darkness/Light isn't vision. I don't think users should be forced to use vision to get "basic" effects like this.

2. I think the new behaviour would be more intuitive and that should be foundational to changes that alter defaults. If existing behaviour is desired, and a preference can make it so, that would be a pretty minor "growing pain."

[Phergus]

No objection to making darkness work in Day or Vision Off modes. Can't think of a scenario where someone might add Darkness sources to a map and not want it to work.

On a Vision/Day map should any level of Darkness work or should there be a defined ambient light level that must be overcome?

FB suggests that Darkness/Light should work without vision enabled. On the surface that seems reasonable but what does it actually mean to say Lights work on a Day map or a No Vision map? To make Lights visible on a Day or No Vision map we either have to "dim" the map display or wash it out when showing the presence of lights. I can see how if you have Darkness sources on a map then you might want the ability to put countering Light sources and would want those to be visible.

[melek]

I think the feature sounds cool and makes some sense. Note that if this works for 'Day' and 'Off', Darkness effectively becomes auras with conditional VBL.

• Pro: Makes hover behavior consistent: Vision calculation is already happening with 'Off' selected when you mouse over a token, so including darkness would make the vision outline consistent across all the 'Vision' modes. It also makes sense to render any color for the darkness assigning light as well so you can visualize the obstacle there -
• Con: Compromises Performance: Part of the advantage of the 'Off' setting is that it is both simplifies the view and saves a lot on performance by skipping light calculations. That said, I think at very least having the vision outline correctly display when hovering over a token would be a more consistent experience.

The 'Vision' submenu is about enabling lights and sights, and has a very limited subset of the possible combinations (presumably the most useful subset). To summarize my thinking here is a little matrix of the levers the Vision settings use and which combinations we have, please correct me if I'm missing something:

Vision Setting	VBL Calculation (Shown on hover)	Vision Blocking	Auras	Lights	Darkness Color	Darkness VBL Calculation	Clamp vision to Lights
Off	✔️	-	✔️	-	-	-	-
Day	✔️	✔️	✔️	-	-	-	-
New Off	✔️	-	✔️	-	✔️	✔️	-
New Day	✔️	✔️	✔️	-	✔️	✔️	-
Night	✔️	✔️	✔️	✔️	✔️	✔️	✔️

Note that Darkness has two components: How it blocks vision like VBL does (Darkness VBL Calculation) and any colors rendered when you can see into the darkness (Darkness Color)

[FullBleed]

I might be misinterpreting @adyoungblood 's idea... but it sounds like he wants to incorporate a kind of "Fog of Night" over Night/Day maps so that light sources with fades can be rendered properly. And that on day maps, it would be totally bypassed with a default 100 Lumen source overlay. And since that's not necessarily a "vision" related feature, if would tie into @kwvanderlinde 's desire to have darkness work via lumens on day maps... I don't mean to mash the ideas together but it seemed like they might be compatible to achieve the desired goals.

[kwvanderlinde]

On a Vision/Day map should any level of Darkness work or should there be a defined ambient light level that must be overcome?

If we define an ambient light level, I would suggest 100 lumens. This is the default for lights, so it would make Day function very much like Night where a token has a very long range light source. But now that you bring it up, I like the idea that Day would not reveal any darkness, as it would make low-lumen darkness be completely useless in Day. This woud effectively make Day act as light with either 1 or 0 lumens. Another idea is that the GM could assign a lumens values to Day vision according to what works for them. I'm not really a fan of this idea, but maybe others have differing opinions.

FB suggests that Darkness/Light should work without vision enabled. On the surface that seems reasonable but what does it actually mean to say Lights work on a Day map or a No Vision map? To make Lights visible on a Day or No Vision map we either have to "dim" the map display or wash it out when showing the presence of lights. I can see how if you have Darkness sources on a map then you might want the ability to put countering Light sources and would want those to be visible.

This ties into melek's table, I would suggest that lights be rendered for Day and Off as well. Currently lights are just skipped in those cases. Pure white lights wouldn't really be viisble but at least others would be. But also the last bit of what you said is the key: mechanically, a light source exists to beat back darkness (whether a darkness from a light source or FoW). And that's exactly what lights would do with vision set to Day or Off

[kwvanderlinde]

Thanks for the table @melek! As I aluded in my above comment, the only change I would make to the table is that the Lights should render for New Off and New Day. I.e., treat lights and darkness equally. Otherwise it's exactly what I was thinking and a good summary of current behaviour.

Regarding performance, I'm both really concerned about it and not concerned at all about it. On the one hand, if people are accustomed to using "Off" to avoid some bad lighting performance, this change would certainly stomp all over that which would be unpleasant. But on the other hand, if performance is bad enough to warrant turning vision Off, then Day or Night is probably not being used and light sources are kind of redundant. Or Day and Night are being used but the experience isn't great, so maybe trimming the number of light sources would be a better solution anyways.

[melek]

I hate to say this, but at this point I think you should have more configuration options. For instance, legacy 'Off', 'Day', 'Night', plus a 'Custom' option with these levers are available to get things just right. Custom options, even when the 'Custom' setting isn't selected, are saved per-map.

😬

[Phergus]

Note that Darkness has two components: How it blocks vision like VBL does (Darkness VBL Calculation) and any colors rendered when you can see into the darkness (Darkness Color)

@melek minor nit - Darkness doesn't block vision. Tokens with vision can see tokens on the far side of the darkness if their vision extends that far. Darkness merely hides tokens from view.

[Phergus]

At this point in time we don't need to make things more complicated, thus requiring even more support, and just make Lights/Darkness render on all three map types.

At some point in the future when we do actual lighting and can do things like simulate night with a full moon or twilight when can worry more about adding options to maps.

[Phergus]

@kwvanderlinde Testing and I don't believe it is working as intended.

A "Darkness" source does not render as a dark area but just hides tokens within that area for Day and Night vision modes. On maps with vision Off, darkness has no effect. The area of darkness just gets the vision outline like this:

Possibly one of the other changes to light/vision broke this?

[kwvanderlinde]

@Phergus Can you confirm what your setting is for Fog opacity in application preferences?

The reason I ask is that I can only reproduce what you describe for Day and Night vision (here and in #1895) when the following is true:

1. The area of darkness has previously been revealed. I.e., it is not covered by hard FoW.
2. The Fog opacity is set to zero
3. The darkness color is black (#000000)

Otherwise I see the soft Fow providing a darkness effect like this for Day and a similar one for Night:

Regardless of that, there are a couple of things that this has made clear need fixing:

1. There is some improper clipping when vision is Off (explains the white circle of darkness in your comment on the other issue)
2. Darkness renders just like any other light. I.e., black does nothing to other colors while white forces everything white. This should work oppositely for darkness.
3. Darkness should render as its own overlay on top of lights. This would allow darkness to always look like it is "supressing" the light somewhat.

[Phergus]

Wasn't using Fog but the opacity is set to 50 (default I think). I have since discovered that darkness sources must have a color specified to function semi-correctly.

Just setting lumens to a negative value doesn't produce darkness it just negates light sources and doesn't make an area of the map dark.

[kwvanderlinde]

Interesting. Yeah, lights without colours were previously considered "bright lights". They weren't rendered themselves, but had the effect of overriding all other light colours. This also included darkness! Here's is a screenshot from 1.11.5 with player view at Night:

So treating darkness as a bright light is obviously a bug and that is nothing new in itself.

Bright lights were changed in #3339 so that they no longer any effect on rendering at all. However, they are still being filtered out of the set of rendered lights, which means such "bright light" darkness still isn't being rendered and thus won't darken anything. I think we should be rendering such darkness as though it were black.

The other problem I mentioned in my previous comment is clipping. Because lights are clipped to the visible area (which does not include soft FoW areas) there is a hole created wherever the darkness is. This look okay when FoW is enabled as the soft FoW will naturally darken the area. But when FoW is off or Fog opacity is set to zero, those areas just plainly show the map underneath with is not so good. I don't see a correctness reason to clip lights this way (hard fog will be rendered on top anyways), but there is a possible performance case to be made for clipping. I think the solution for now would be to just avoid that clipping altogether. In the future we can try to clean up the zone renderer so it's state is more managable which would allow us to make more intelligent decisions about clipping.

[Phergus]

Bright lights were changed in #3339 so that they no longer any effect on rendering at all. However, they are still being filtered out of the set of rendered lights, which means such "bright light" darkness still isn't being rendered and thus won't darken anything. I think we should be rendering such darkness as though it were black.

That makes sense to me. I'll open a new bug ticket for that.

I would expect to be able to drop a darkness source on a day map and get a darkened area. Obviously a GM needs to still see what's in the darkness so on a GM client would we go with essentially a soft-fog effect? How would they differentiate between darkness and regular soft fog area? On the Player side I would expect it to be fully black unless there is a light source that fully offsets it. Which probably veers into game rule territory. Does a 80 lumen light partially negate a -100 lumen darkness or does it have to fully counter it and if so does it just look normal?

[kwvanderlinde]

I disagree that darkness should necessarily be black. If players have already explored an area then come back to it, they should still be able to see the map even if darkness was added after. So I quite like the idea of darkness looking similar to soft FoW. I think darkness and VBL-blocked vision can be seen as just two different ways to get to the same sort of thing: hiding tokens without hiding the map itself. Hiding the map is a job for Hard FoW IMO.

From an aesthetic standpoint, one way to achieve solid darkness is to have darkenss be rendered to its own overlay with its own opacity. If the opacity is cranked to 255, it would be a solid color and completely obscure the light and map underneath. Could be handy when used as a literal table top or something, though it couldn't enforce the effect for anyone else.

[FullBleed]

I disagree that darkness should necessarily be black. If players have already explored an area then come back to it, they should still be able to see the map even if darkness was added after.

Couldn't something be using darkness (added later) to obscure an actual change to the "map" though? Or to obscure known map obstacles?

I don't know how it is in most games, but in D&D I've always used darkness as an all-or-none effect over an area. Soft fog does not quite rise to that threshold. I certainly wouldn't let players use basic knowledge of an area to navigate newly darkened areas without consequence.

As MT currently is I'd probably drop a solid black token or drawing over an area of a map to represent darkness because I can't be bothered to figure out how to achieve the same effect with light and lumens (if it's even possible), etc. ;)

Hiding the map is a job for Hard FoW IMO.

If I could produce hard FoW that a token couldn't expose then I'd agree. But I would, in a perfect world, want something more dynamic with 100% opacity that doesn't follow the rules of hard fog, that I can see through as a GM, and that the players can't see through at all.

From an aesthetic standpoint, one way to achieve solid darkness is to have darkenss be rendered to its own overlay with its own opacity. If the opacity is cranked to 255, it would be a solid color and completely obscure the light and map underneath. Could be handy when used as a literal table top or something, though it couldn't enforce the effect for anyone else.

Is there a reason we can't have a kind of "Darkness Aura" with a forcible opacity level? Perhaps trying to get "lights" to do the job is creating unnecessary hurdles.

[kwvanderlinde]

After fooling around with this a bit more, I've been swayed that darkness should render as a solid colour for players (and it might as well be black). Players shouldn't generally be able to determine the nature of the darkness, such as the exact layout of the sources, etc., which would be plainly visible if we allow players to see blended darkness. I'm still not personally sold on the idea that darkness needs to be opaque (i.e., hide the map), but my PR sets that as the behaviour for the time being.

[kwvanderlinde]

Couldn't something be using darkness (added later) to obscure an actual change to the "map" though? Or to obscure known map obstacles?

This is what FoW means to me:

• Hard FoW means players don't even know what the map looks like.
• Soft FoW means players have already know what the map looks like, but they may not know what tokens or objects are there.
• Lack of FoW means player are allowed to see plainly what is there.

So from that perspective, hard FoW should be added back in if the GM intends for the darkness to once more hide the map from the players.

I have to admit that it isn't as dynamic. Though with the right macro functions and a motivated macro writer it shouldn't be too hard to make a system that would restore hard FoW as needed, and could be based on the presence of darkness or any other property of certain tokens.

[Phergus]

Agree with your statements on FoW but disagree with your conclusion as I don't think that Darkness should mandate the use of FoW.

Take an outdoor map in the day for example that has no structures or other interiors that need FoW. Now posit some mage has cast a large area of darkness to hide what is going on in a particular area. Maybe to hide traps, or defenders or to hide the entrance to something. Perhaps the party has access to a light spell that can negate the darkness but only in a limited radius. No need to manage things by adding Fog back in or taking it away. The characters with the light source just move around normally.

[Phergus]

Tested. Player clients now render darkness areas as fully opaque black while GM clients are partially transparent.