Maptool: Support for DND 5e additive darkvision

[Merudo]

Is your feature request related to a problem? Please describe.
In 5e, Darkvision is additive: it turns Darkness into dim light, and dim light into bright light.

This type of vision cannot be currently implemented in MapTool.

Describe the solution you'd like
A extra parameter to sight, add#rrggbb, which would add the #rrggbb code to every light source seen by the token.

[JamzTheMan]

Are you going to add Pathfinder darkvision in as well? 😸

It's only black/white (greyscale) vision and would look really cool for sight to be reduce to greyscale! Of course, it's only within range (normally 60/90/120ft) and any other light source in the area would overwrite/overpower/replace this within the lights range...

[JamzTheMan]

Oh and Pathfinder 2E lowlight (and other DnD versions) bump dim to bright as well.
Also, Darkness spells reduce bright to dim and dim to dark. But we can't do "that" right now (dim to dark, or dark to dim)

[melek]

I use dark red personal lights for darkvision (which washes the color out pretty well), and a bluish gray value for dim light; Something that has always irked me a bit in MT is that lights combine into darker colors, so my 'dim light in darkvision' looks darker than either dim light or darkvision.

They _should_ add together to make brighter areas, which would resolve some of the weirdness.

MT Light (Subtractive):

Actual Light (Additive):

[JamzTheMan]

@Phergus ya, why doesn't MapTool do it this way? Although, aren't we using RGB for lights and isn't that "additive" vs "subtractive" and should end up white?

I remember googling similar things doing the "color picker" for VBl and holy crap did I go down a rabbit hole and basically found out colors are hard lol (started getting into what "we" perceive as color and similar colors and some complicated algorithms for it. ended up just using a guesstimate instead)

[Phergus]

My memories on this are fuzzy at best and I haven't looked at the code to see how light colors are being combined. Given what we see in MT it wouldn't surprise me if we are doing a simple (R1+R2)/2 and so on which of course won't preserve luminance levels.

[melek]

Whatever is happening in MT right now is pretty weird.
Here are some values of the pure colored lights, 'Night' vision mode over pure white background drawing (which appears gray because of the slight night coloring).

// MT Definitions
Green: circle 20#00ff00
Red: circle 20#ff0000
Blue: circle 20#0000ff

// White base color under darkness, in RGB / HSL
White BG: RGB 210, 210, 210 / HSL 0° 0% 82% 

Red:   255, 155, 155 /   0° 39% 100%  // Pure colors, brighter than white base
Green: 155, 255, 155 / 120° 39% 100%
Blue:  155, 155, 255 / 240° 39% 100%

R+G:   194, 155,  94 /  37° 52%  76%   // Combined colors, dimmer than white base
R+B:   194,  94, 155 / 323° 52%  76%   // Why do these skew in favor of red/blue?
G+B:    94, 155, 194 / 203° 52%  76%

R+G+B: 157,  94, 118 / 337° 40%  62%  // Center. Muddy Red; Should be GRAY or WHITE

[JamzTheMan]

Took a quick peek, we're doing a graphics2d.fill()

So a quick google search led me to adding the setXORMode line above the render block here:

newG.setXORMode(Color.black);

    for (Entry<Paint, List<Area>> entry : renderedLightMap.entrySet()) {
      newG.setPaint(entry.getKey());
      for (Area area : entry.getValue()) {
        newG.fill(area);
      }
    }
    timer.stop("lights-5");
    newG.dispose();
  }

And I got the below results... Promising. I don't have time to chase it down further... We'll have to probably render the lights like this elsewhere in the code before adding the background image or something, but looks like we can at least set the coloring to additive a bit better...

vs the original

[cwisniew]

You might want to try two overlapping lights of same colour before you go too far down the XOR path :)

What you will want to do is implement AlphaComposite and set the setComposite on the graphics context you are rendering lights to (should be separate image to map then final result drawn on map).

for simple case draw each of the lights on this new image black with alpha 0
newRed = existingRed + lightRed (clamped to max value so it doesn't overflow)
newGreen = existingGreen + lightGreen (clamped to max value so it doesn't overflow)
newBlue = existingBlue + lightBlue (clamped to max value so it doesn't overflow)

Then you need to decide what to do with the Alpha's there are three choices
1) Min value of existing and light (but use light where existing = 0).
2) Max value of existing and light.
3) Average of existing and light (but use light where existing = 0).
Probably need to try all three and see which is more aesthetically pleasing for several overlapping lights. But option 3 would give you the most distinction with multiple overlaps (doesnt mean it will look best). Definitely dont add the alphas.

[bubblobill]

Since you are fiddling with lights, I would suggest accommodating gradients for those that enjoy realism. Not saying you should implement gradients, just that if implemented they would work with any changes.

lamp: circle 20#ffffdd>#000000    linear
lamp: circle 20#ffffdd>>#000000   inverse square
lamp: circle 20#ffffdd>>>#000000  inverse cube

[JamzTheMan]

Since you are fiddling with lights, I would suggest accommodating gradients for those that enjoy realism. Not saying you should implement gradients, just that if implemented they would work with any changes.

lamp: circle 20#ffffdd>#000000    linear
lamp: circle 20#ffffdd>>#000000   inverse square
lamp: circle 20#ffffdd>>>#000000  inverse cube

Think there is another issue for this but i like your notation...

[melek]

Yeah I made that issue for the same reasons @bubblobill suggested; figured it might be possible to accommodate if someone was messing with lights anyway ;)

I didn't want to dog-pile this issue too badly but I can't say I wasn't tempted.. #1908

[Merudo]

Another topic that might be relevant: Strange lighting when coloured light sources overlap