Two colored lights placed nearby removes the color

[Khoredran]

I didn't know if this was a bug and if it would be properly looked at, but I feel it is something that shouldn't be happening.

Summary: When placing two colored lights near each other, the color reverts to white automatically and we lose the color. In my test, I used the exact same color: FFFF9243
Ruleset(s): I tried in a fresh new CoreRPG and in Pathfinder 1st Ruleset campaign with no modules and no extension loaded, the result was the same.
Operating System / Language Setting: Windows 10 / English
Steps to Reproduce:
1. Create a new CoreRPG campaign
2. Drag and Drop BattleMap01.jpg from the FG Battle Maps into images and unlock it.
3. Enable Player Vision Preview (optional, but it let us see more clearly what happens)
4. Go in the Lighting tab and in the Add Lighting sub tab.
5. Click on the color box and copy/paste FFFF9243
6. Add two lights far from each other in different rooms; you should see this:
46736
7. Move one of the lights close to the other and marvel at the disappearance of the color; you should see this:
46737

Here is the CoreRPG campaign file:
46738

Thank you very much ^^

[darrenan]

Light sources are additive where they overlap, this is clearly called out in the wiki. Admittedly it does cause some unrealistic lighting effects. There's a note about it on this page in the wiki. (https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/1312784387/Adding+Lights+to+Maps+and+Tokens)

[Khoredran]

Additive is fine, but why would it revert the color to white when the lights are the same orange color? Placing yellow candles near each other would make the same issue and revert the color to white.

Nowhere is it stated that the color is removed by the additive lighting.

[Zacchaeus]

When you add light to another light it gets brighter and with enough it will go white - no matter what the original colour is.

[Khoredran]

Thank you Zacchaeus!

With your insight, I was finally able to get the effect I was looking for! My choice of color was indeed too bright.
I tried with FF9B4600 and we can see that the mix of color doesn't revert to pure white anymore! I am so happy now ^^

46739

[Zacchaeus]

It isn't just the colour. When you are lighting an area try reducing the Alpha channel and increasing the falloff of the bright and dim lights. You can also reduce the bright light to very small and have the dim light be big. Play around with the various settings until you get used to what they do.

[Khoredran]

Yup, the light tools are AWESOME!

When they came out to live, I was jumping around with joy and my wife was clueless as to the source of this burst of pure happiness.

[Tenkuya]

Turning down the Alpha doesn't really seem like a great solution. You then get two really dim lights instead of two areas of bright light with overlapping dim areas. An option to turn OFF the additive aspect of a light would go a long way to not having to spend a bunch of time fiddling around hoping to get two light green lights to not turn white or have weird areas between them.

The problem also doesn't seem to be fully understood honestly. Two lights with 255 in the green channel that overlap (or 200 lights) seem to NOT create a white light. Two lights with 100/255/100 seem to create areas of light with the value of 200/255/200 (closer to white). So if you want to have two torches placed on either side of the door they have to have 1 color channel and nothing else or those values seemingly just get x/x/x + y/y/y. This doesn't seem like a great way to handle things and just turning down the alpha just makes the lights less present.

The alpha workaround feels like it just hides the issue by making the lights harder to see/less present. Maybe I'm not understanding something but again, turning the additive feature off for at least the brightness levels would fix this. I don't mind color blending for different colors but something here is really wonky.

The outer ring of torches being prohibited from touching or they create a "bright" spot is also weird and feels like an extremely technical application of lighting rules. "Adding two dim things creates a bright area" sounds fine but when you have two people with torches standing with 5-10 feet of dim overlap and that overlap creating a bright area between the two sources makes it feel like a mystical third light source exists.

[chaiwalla]

Agree. No overlapping effect. And if two light sources of different strength overlap, just the brighter one illuminates the overlapped area.

[Moon Wizard]

As far as what I have been told, light physics are additive in nature. Since the lights in FGU are a cross between what looks good and showing game system "light regions", you may perceive that the overlaps don't look good to you, as the falloff levels in real-world lights are much different. You should play around with falloff levels and alpha levels to come up with the effect you want on your own maps.

Regards,
JPG

[Tenkuya]

As far as what I have been told, light physics are additive in nature. Since the lights in FGU are a cross between what looks good and showing game system "light regions", you may perceive that the overlaps don't look good to you, as the falloff levels in real-world lights are much different. You should play around with falloff levels and alpha levels to come up with the effect you want on your own maps.

Regards,
JPG

I mean, if this is more or less the "end result" I'd probably just opt to never use it. If you want to do something with fun light colors, it just doesn't work. Two light green (100/255/100) overlaps result in nearly white. That functionality doesn't look good and won't look good to most people. The suggestion of "turn the alpha down" doesn't really work either as you're left with weirdly dim lights that could be within screenspace of full alpha lights. The only result then is "turn the alpha down on virtually everything" but then your whole scene/map is just dark.

Nobody I play with or have shown this thinks this is "acceptable". Lights needing to be more than 50ft apart when set to "torch" preset (color edit for visibility) is kind of not worth using. All the tutorial videos seem to place torches really far apart so I almost feel like this is only ever intended to be used if you're going for a "mostly dark" setting and you can't really do anything cool like players having torches (they'll overlap for sure) or just a neat little "you have to light both of these torches/runes/whatever on the wall". So unless all torches (preset option) are default color and further than 50ft, you get artifacts like crazy. If this isn't "end result" or even near, totally cool, adding a toggle is just a suggestion.46761

[chaiwalla]

Can’t agree more. The bizarre overlapping additive effect has to go (or something you can opt out of at least).

[Khoredran]

The one thing that is absolutely awesome and that I just learned is that everyone can change the normal light presets with the new lighting menu in the option tab!
Here is the video for people that want to see it.
https://youtu.be/sF5Ntvc_3kU

With this approach, you can parameter every single pre-made lights and add new ones to fit your needs and let the lights have the exact behavior that you want!

[Zacchaeus]

I'm struggling to find what is so terrible about the lighting that it makes it unusable or unrealistic but after much faffing around I'm presuming you mean this situation as in my first image here? There is an area marked which adds the dimmish bits to make it a little brighter (which would be quite natural - you can't possibly be arguing that if you add two lights together that they aren't brighter than one).

If this is what is annoying you then move the lights closer together or change the falloff values of the dim and/or bright light as in my second screenshot.

[LordEntrails]

... Two light green (100/255/100) overlaps result in nearly white. That functionality doesn't look good and won't look good to most people. The suggestion of "turn the alpha down" doesn't really work either as you're left with weirdly dim lights that could be within screenspace of full alpha lights. ...

I wonder if FGU is adding the RGB values instead of averaging them and then adding the brightness values? Not sure any of that is such a thing, will have to go study up on how computer display brightness more.

[mdrichey]

Thanks for sharing that! I didn't realize that the ability to edit the presets had been added to Options.

[HywelPhillips]

There's more than one problem going on here. The colour problem is down to colour clipping, also called blown-out highlights. The ugly overlap between light sources is due to incorrect falloff of lights from the centre.

https://en.wikipedia.org/wiki/Clipping_(photography)

Take at look at this screenshot. Top row is two preset candles far apart - looks OK.

Second row, first example is a pure red light (FF0000) overlapping with a pure green light (00FF00). In the overlap, the two are correctly summing to produce a saturated yellow.

Second row, second example is a desaturated red light (FFC5C5) overlapping with a desaturated green light (C5FFC5). In the real world, the overlap in the middle will be a desaturated yellow, correctly calculated by FG in the dim light area. In the bright light overlap, the colours have clipped because the blue channel has gone to 255 along with the other two channels, producing white light.

This does not happen in the real world, that patch would be perceived as brighter but of consistent hue with the yellow dim overlaps. Human eyesight has a very wide dynamic range (in part because we tend to perceive things logarithmically rather than linearly) and we can retain colour information over a very wide range of brightness.

It CAN happen photographing the real world, especially with digital sensors and readout which have a hard clipping point either at full-well-capacity of the sensor or maximum-readout-value of the electronics. This results in an abrupt loss of colour information in the highlights, which is very ugly and especially with earlier sensors was a key point about working with digital cameras on set. To the point that my digital cine camera has a clipping warning display specifically to alert me to individual colour channels reaching clipping point, so I can change exposure or relight the set to avoid it.

The third example on the second row is the overlap between two candles, which absolutely should retain the yellow hue of each candle and not clip to white.

To avoid this clipping, you can turn the alpha down to about AA or so, which fixes the pools of light near the candle centres, but that still gives white clipping in the overlap between the two. Again, this is not what happens in the real world: see second attached pic which is a digital photograph of two LED candles on a stone floor. It is properly exposed for the overlap region, but the camera sensor/readout/processing chain can't quite handle the maximum brightness on the LED's, so they have clipped to white in the centre of the candles. In order to avoid that I would have to have underexposed the whole image and brought the shadows up in post-processing with a gamma correction to lift the mid-tones.

In FGU order to avoid the clipping completely with two lights, you need to turn down the alpha to half way (to 127 out of 255), so that the central values never clip when you add the two lights together. This results in very dark lights, with a brighter overlap between the two of them, see third attached picture.

In effect, you're again having to underexpose the whole image in order to avoid clipping in the highlights- which is tricky to do, especially when you've only got 8 bits per channel to work with. (Which is why more recent digital cameras use higher bit depths or different encodings).

The clipping itself is made more obvious by the second problem - that of incorrect light falloff, which I posted about in another thread, but which comes from neglecting the fact that in the real world light intensity from a point source falls off as one over the square of the distance from the source. This means that the overlap between two candles can never be brighter than it is right next to the candle flame - which is why the overlaping candles with the bright lens in between them in the bottom right of the first attached image looks completely wrong.

There ARE ways around these problems, from the quick and dirty (using the MAX of overlap values rather than addition) to the more complex (doing the calculations in different colour spaces like LAB which treats the luminosity separately from the colour tints, commonly used in video processing, or with different gamma curves, for example log curves which more sensibly distribute the information from dark to bright to help avoid these clipping problems) to the computationally intensive physically correct way which is to use floating point math rather than integer math, or use much bigger integers that 8-bit, and calculate your 1/r**2 falloffs correctly.

I am not a computer graphics expert or a rendering expert - but I believe there are standard solutions to these problems. I don't think FG need to reinvent the wheel, but I think the light rendering model could do with revisiting to avoid these problems doing something as common as overlapping the light from two candles.

I say that because I actually *am* a lighting expert - from physics Ph.D. to photographer and cinematographer working with light on set on a daily basis, and the current behaviour of overlapping lights is a poor implementation because of these two effects - colour clipping, and incorrect falloff. These produce unphysical artifacts which look wrong - and I'm 99% sure this is why.

Cheers, Hywel

46790
46791
46792

[LordEntrails]

I wonder if FGU is adding the RGB values instead of averaging them and then adding the brightness values? Not sure any of that is such a thing, will have to go study up on how computer display brightness more.
45 minutes later, this is what I learned... The human perception of color is not simple, or consistent from one human to the next. For a great example of this, see The Dress (https://en.wikipedia.org/wiki/The_dress). It looks white and gold to me, but is actually blue and black. Huh.

Anyway, light sources are generally considered to be additive. For our discussion this would simple mean that you would add the RGB value to a max of 255. And this would result in mixing of sufficient colored sources to result in white light. And, this is what does happen in real life if you mix lights of sufficient color diversity. So, FGU doing this is what would be expected.

But, all of that is for light sources that generate a spectrum of light. So the light might look yellow, but yellow is not the only color the light is giving off, it's just the primary one. A light source that did not emit a spectrum (i.e. a magical light source, or a very special light emitting diode) then the perceived color is not necessarily just a mix of the two RGB values. This is because a human actually only perceives some wavelengths of light, and the brain mixes the perceptions together to give a perceived color. i.e. human 'rods' only detect narrow spectrums of RGB.

And then it gets more complex, because the reflection of light off of surfaces is subtractive in nature. This means that when something looks red to you, it is because it is not reflecting the spectrum red. Hence why in printing and painting CMYK is used and not RGB. And those are based upon the object being exposed to an even spectrum of all colors (white) light.

What I couldn't find, was if you had two light sources of a single narrow color spectrum if they would result in white light or somehow a more intense version of the single color. I think it depends upon brightness/saturation, but not sure. Do also note, that even though source of red and blue (of sufficient brightness) might be perceived as white or purple, depending upon saturation and the human eye perceiving it.

I'm not sure where that leaves us with FGU, but I think the suggestion to adjust the alpha of the light sources is a good approach, but not sure yet.

For those of you wishing to go down the wormhole, here are some of the pages I referenced;
- https://en.wikipedia.org/wiki/Additive_color
- https://blog.thepapermillstore.com/color-theory-additive-subtractive-colors/
- https://isle.hanover.edu/Ch06Color/Ch06ColorMixer.html#:~:text=Additive%20color%20mix ing%20is%20what,wavelengths%20still%20reach%20our% 20eyes.
- https://www.reddit.com/r/askscience/comments/1yixdc/when_two_different_color_lights_intersect_or/
- https://www.physicsclassroom.com/class/light/Lesson-2/Color-Addition

And note, all of this is very human specific. Elves, Dwarves, Tieflings and others are unlikely to see color the same ways human do; https://jakubmarian.com/the-illusion-of-rgb-screens/

Edit: Hywel, how did I do with my brief research? How much did I get wrong? Though your discussion seems to find the actual issue much more precisely.

[Khoredran]

I never fathomed to see the post I created to become one of the most interesting and intelligent ones I've ever read in this whole forum. HywellPhillips arguments are pinpoint and bring constructive solutions to the maths behind the calculation of light overlaps.

[HywelPhillips]

What I couldn't find, was if you had two light sources of a single narrow color spectrum if they would result in white light or somehow a more intense version of the single color. I think it depends upon brightness/saturation, but not sure. Do also note, that even though source of red and blue (of sufficient brightness) might be perceived as white or purple, depending upon saturation and the human eye perceiving it.


You can simulate white light with a "spiky" spectrum source. We are used to seeing colours under continuous spectra - specifically the "black body" spectra emitted by glowing hot objects - like a tungsten lightbulb filament or the sun.

It's never perfect, because it depends on how the peak in the emission spectrum matches up with the response curves of the eye or the dyes in the pixel filters for a digital camera sensor. It also interacts with the reflectance spectrum of the objects being illuminated - if you happen to have a purple object which only reflects light in one particular bit of the spectrum between red and blue (rather than a broad range of colours) and you illuminate it with a sharp spike in the red and a sharp spike in the blue, both of which miss that peak in the object's spectrum, you can end up with it rendering very much darker than it ought to, almost black.

Early attempts at making photo/cine lights with LED's tried this and we found that the colours were all out of whack - and very dependent on exactly how the light emission peaks fell with respect to the pass-bands of the RGB filters on camera sensors. So the same object could have a green tint on a RED cine camera but a magenta tint on a Sony, for example.

Manufacturers have got much better at that since - LED's are inherently quite narrowband emitters, but you can supplement those emission peaks by adding phosophors which absorb the initial light colour and re-radiate over a broader range of wavelengths. The main innovation though was just to use more different colours rather than trying to make it with just red, green and blue - so most cinema LED lights now have LED-plus-phosphors that are a decent approximation of "warm white" (3200 K, like tungsen lights), "cool white" (5600 K like daylight), red, green, blue and maybe amber or deep red to help with skin tones.

If you've got broader emission in the red, green and blue which is pretty close to the passbands for human colour sensors in our eyes, you can get away with just three colours - as TV has done for years, and as computer monitors of all sorts still basically do.

None of which is particularly relevant to the FG lighting discussion, sorry! Couldn't resist the lecturing urge.

Cheers, Hywel

[HywelPhillips]

Just to inform the discussion a bit more, I tested how a couple of other programs handle lighting and overlap.

The first one is Roll20, which as far as I could see doesn't have a colour control for lights? (It's been a year since I used Roll20 as a GM rather than a player so I may simply have missed it).

They do seem to have a bit of the "lens" of light that's too bright in the overlap, but is is soft-edged and rather subtle - I'd have to try it on a flat grey background rather than my standard map example to be 100% sure it's the lighting not variations in brightness on the example map.

The second one is Foundry.

I would say they are doing a slightly worse job of the saturated red + saturated green = saturated yellow, but it is avoiding colour clipping on the bottom left.

The desaturated lights, bottom middle, look to my eyes as though they are colour clipping right in the middle, but it's softer-edged and more graceful looking than the FG example in my opinion.

Where they definitely are doing a better job is what I would think of as the most common use-case - two overlapping lights of the same colour, in this case a moderately-saturated yellow that I'd use for candlelight. There's no hint of colour clipping in the overlap there. I'm not sure how they have achieved it, but there's no question that the result there is significantly closer to physical reality than the FG results using default FG settings for the candles.

I don't know if Foundry are doing this by better rendering model or some sneaky tweaking of default settings to avoid the issues, but I definitely think it's worth a second pass at the rendering model in FG to try to avoid the ugliest colour clipping problems.

Cheers, Hywel

46824
46825

[Egheal]

Thanks for all the informations on lighting. I can't see your last 2 attachment though.
Edit: it works now, thanks.

[HywelPhillips]

Don't know what happened there, have reattached the pics, seems to work now for me.

Hywel

[HywelPhillips]

Final post from me for the moment - just to show that it is possible to make nice lighting look good with FGU.

Key tips:

1) Avoid overlapping the bright light portion of lights - this will almost always lead to ugly colour clipping. That's especially true for lights of the same colour, and very very much true for lights with relatively pale pastel tints. They will blow out to white straight away. Fewer lights = safer. Don't put two candles next to each other even if they are like that on the base layer map. Use a single candle and increase the distances instead.

2) As default, try using alpha of about 200 rather than 255 for everything. This gives you some headroom to avoid clipping.

3) Falloff 99 for dim light is your friend. Gives a much more natural look, although admittedly does make it a lot harder to distinguish dim light from Fog of War colour. Nonetheless, if you want to avoid artefacts, it is well worth doing. Play with this if you need to distinguish dim light mechanically. For prettification, 99 is the way to go.

4) Choose more saturated colours. The more pastel they are (ie the closer all components are to 255) the more likely they will clip to white before you want them to. So for the two torches I wound down the blue channel quite a bit to avoid losing the yellow when lights started to overlap. Ditto, the bonfire in the middle is quite a deep orange with not too much green and very little blue, and the ghost's glow is blue 255 and 0 in the other two channels and alpha down a bit to 200 ish. They can all overlap their dim lights without any nasty artefacts, and the bright light overlap is OK for everything except the two torches (see hint 1 above).

5) For "pretty effect" lights rather than stuff you want to use to keep game system track of dim vs. bright light, use 99 falloff for both bright and dim light, and consider doing 1/3 bright to 2/3 dim instead of 50:50. Again gives you more headroom to avoid clipping whilst keeping a nice look for the central part of the light.

When I move things around, they no longer clip in a really ugly way unless I overlap the bright light segments of the two torches.

46826

[HywelPhillips]

Not actually the last post from me it turned out, as I suddenly thought of a simple solution to the clipping highlights problems that camera manufacturers used extensively in the days of very limited sensor dynamic range:

use a "knee".

Here's a fairly simple explanation from Sony:

https://helpguide.sony.net/di/pp/v1/en/contents/TP0000909107.html

The idea is that once the brightness passes a threshold (the knee point) you stop doing linear addition and start doing something more complicated to preserve the highlight colour information. Take a look at the two picture samples on that page from Sony - you can see the highlights clipping to white in a very ugly way in the top picture, especially in the pink ribbon on the top left. That's what is happening to our overlapping pastel-coloured lights in the bright light zone. See how the knee preserves the colour information in the highlights.

Again with the caveat that I am no computer graphics programmer, I believe it is possible to implement a knee relatively simply as it has been done in real time on cameras with very simple digital signal processing.

These days we use colour look-up tables (called LUTs) in camera to do the job, which is an alternative approach which also has limited computational overhead.

https://nofilmschool.com/what-is-a-LUT

https://en.wikipedia.org/wiki/3D_lookup_table

As I said, this problem has been around since the early days of digital imaging and there are standard techniques to handle them which do a better job of handling highlights without clipping. I hope that maybe the FG team can take advantage of some of this work and find a relatively easy off-the-shelf way to improve things :) I note that graphics cards and Unity have built-in LUT support, although whether it is in any way useful for FG's implementation I'm not qualified to say.

Cheers, Hywel

[LordEntrails]

Great info Hywel. Both from what's happening and what we can do now as users to get the results we want. Thanks :)

[Khoredran]

We need the implementation of the brightness knee ^^

All this information made me certain that changing the additive nature of light from linear to logarithmic at a certain precise user-movable point is very important for multi-bright-colored-filled maps to avoid color cancellation to white mix.

I have been playing with falloff and indeed, your recommendations are working, but I can see the limits of FG lights when having two small rooms with a door separating them and a colored light in each. The moment the door opens, we lose the color and the mood we wanted to set in each room.

[kevininrussia]

Final post from me for the moment - just to show that it is possible to make nice lighting look good with FGU.

3) Falloff 99 for dim light is your friend. Gives a much more natural look, although admittedly does make it a lot harder to distinguish dim light from Fog of War colour. Nonetheless, if you want to avoid artefacts, it is well worth doing. Play with this if you need to distinguish dim light mechanically. For prettification, 99 is the way to go.



I'm hoping there will be an option to turn off FoW which will make the falloff of 99 look great. An option in the Options panel for people like me that don't need FoW.