Bright light vs Colored lights additive math reality vs game play-ability

[SilentRuin]

The lighting system in FGU is flawed for a gaming environment. Using pure additive math for white lighting is going to have anyone with a bright white light, as simple as a lantern, wash out any other colored light in range. This includes things like faery fire and other effect generated colored lights. Those effects are not made so that they can only work in pitch darkness with no vision modifiers. I get the math - but its not game playable. If I have a colored light - even dim - then I still want the players to be able to "see it" even if its washed out somewhat. Visibility being key. No effect lighting (or placed lighting) of a different color than white should be wiped out by a white light (all the colors are in a bright white light). This may make sense in math terms but in game terms it basically breaks it.

In no case do I ever want white bright white lights to wipe out all other bright or dim colored lights. I get blending two colors gets another color. But white light is all colors and if you try to apply that math additive rule unmodified to another color (which is part of white) then you usually wipe it out.

I consider this a bug as FGU is a game not some math reality matrix. If I have a different color and it gets blended, great - I can tell there is some different color there. But if it literally wipes it out making it invisible? As the lighting system currently does with bright white lights? That's wrong. Game wrong - not math wrong. And this is a game.

The current mechanics basically makes all other colored lights near a bright white light (background, lantern, whatever) get overwhelmed and players can't see it.

You can test it simply enough - faery fire is a dim light (0/10) by spell definition of blue/green/violet your choice. Any white light intensity (dim or bright) will basically wipe it out. Even making faery fire a bright light will still be wiped out by any bright white light (barely visible in a dim light which is fine). Dim white light vs Dim any other color will make it virtually invisible. Bright white light vs Dim or bright any other color will make it virtually invisible.

Math additivity logic should always have a "limit" to keep the blend minimally human eye visible You should always be able to see something about a different light color on the map even if it is washed out or blended as long as it is visible.

Any other DMs/players think this is a bug or is it just me?

[MrDDT]

I think dim light of any color should be seen even if bright white light is overlayed in that area. The area should be slightly color tinted to the dim lighting color.

I fully agree with you.

[Zacchaeus]

Some in depth discussion on the technicalities of lighting here https://www.fantasygrounds.com/forums/showthread.php?68472-Two-colored-lights-placed-nearby-removes-the-color

And, no it isn't a bug. It's meant to be that way since that's how it's programmed.

[LordEntrails]

I don't see it as a bug. But, IMO that is irrelevant. *
I understand how and why the behavior is as it is.
I have work arounds for it. In short I don't use 255,255, 0 for yellow lights. I use something more like 125,125, 0. Then overlaps is not really a problem.

I would hate to see SmiteWorks spend developer time reinventing how this works when there are so many other more valuable, to me, issues.

I look at it this way, is this really the most important thing? Or would I rather see work on architecture, or the support of community developer, or single vs double, or new rulesets, or consistent window and button behavior or zoom to fill map behavior or something else?

* Whether it is a bug, issue, or enhancement request; it is working as intended. Behavior changes, such as this, should be (imo) put on the feature request list so that users can vote on it. What anyone of us wants is really only anecdotal, it's what the community wants changed/enhanced/added that should generally (imo) be the focus of SmiteWorks.

[SilentRuin]

I am amazed at how putting a RGB component minimal blend visibility number after calculating the blended colors - which they certainly do blending calculations now - is somehow more than 5-30 min of dev time not including testing.

You set RGB blended result to minimal visibility thresholds. Poof - done. Almost every other game dealing with light contrast deals with this to insure lighting actually "works" in white light blending.

Claiming wiping out all other colors in the name of "I understand the math of it" is irrelevant. For a game, its basically making lighting definitions useless when dealing with white light.

Still no surprise. Defining point source lights or effect lighting of non white color will probably remain wiped out when a similar or greater level of white light is present (short of defining some color that somehow survives that blending according to above poster?). And it will be claimed "IN THE NAME OF MATH" these things will remain useless when some lantern or other bright light source wanders into your range.

Because this is how it should work.

Agree to disagree.

[LordEntrails]

I always laugh when my developers tell me it will only take them 30 minutes. Somehow the change never shows up in the pipeline for a couple of sprints.

[SilentRuin]

I always laugh when my developers tell me it will only take them 30 minutes. Somehow the change never shows up in the pipeline for a couple of sprints.

Oh for sure it depends on the competence of the dev and understanding of the code and ramifications. But somewhere there is code that does the blending calculation for a point or area (matters not) and that result can have a bottom limit for visibility set to show something visible in the one or more combined lights. Likely outside of our view to override. But not theirs.

And unless its crazy code - tis a simple change.

[Griogre]

I agree with Silent Ruin, and I have done so since the FGU beta. Additive light while being "realistic", IMO, is just not a good game mechanic and particularly with dim light it is hard to see where it ends. It's the number one reason I don't put any lights on my underground maps.

On development - the maths have to be calculated either way - but since they went additive I assume it's optimized that way with a light mask/grid instead of intersecting shapes but the Unity engine might lean more one way than another.

[rocketvaultgames]

I agree it's not a bug, but I'd love to see it work the way Silent Ruin suggests. I gave up on using colored lights long ago because they never get seen by the players who invariably have something that will make them show up white.

[SilentRuin]

I agree it's not a bug, but I'd love to see it work the way Silent Ruin suggests. I gave up on using colored lights long ago because they never get seen by the players who invariably have something that will make them show up white.

The only use for colored lights (even though modules I use have them defined in effects which are useless when point source or effect on characters or NPCs have their own white light source) is when you have no background lighting and no effect lighting - usually as point sources of some colored light. Pretty rare limited usage due to the additive math used with white light sources.

[nephranka]

I agree it's not a bug, but I'd love to see it work the way Silent Ruin suggests. I gave up on using colored lights long ago because they never get seen by the players who invariably have something that will make them show up white.

Same here!

[pindercarl]

60590

Okay. You've convinced me to take another look at it. I may have a solution that meets your needs. It preserves the color in overlapping light areas while ensuring that the light value is represented in at least one color channel. E.g. when full intensity white overlaps with full intensity red, the result is RGB -> 1.0, 0.5, 0.5. (light pink). In the attached image you can see the same lighting in the current version (left) and the new method (right). I'll chat with John about it next week. It would likely be a per image option with existing images set to the old method and new images potentially set to the new method.

[rocketvaultgames]

60590

Okay. You've convinced me to take another look at it. I may have a solution that meets your needs. It preserves the color in overlapping light areas while ensuring that the light value is represented in at least one color channel. E.g. when full intensity white overlaps with full intensity red, the result is RGB -> 1.0, 0.5, 0.5. (light pink). In the attached image you can see the same lighting in the current version (left) and the new method (right). I'll chat with John about it next week. It would likely be a per image option with existing images set to the old method and new images potentially set to the new method.

This looks promising!

[SilentRuin]

60590

Okay. You've convinced me to take another look at it. I may have a solution that meets your needs. It preserves the color in overlapping light areas while ensuring that the light value is represented in at least one color channel. E.g. when full intensity white overlaps with full intensity red, the result is RGB -> 1.0, 0.5, 0.5. (light pink). In the attached image you can see the same lighting in the current version (left) and the new method (right). I'll chat with John about it next week. It would likely be a per image option with existing images set to the old method and new images potentially set to the new method.

That looks...

AMAZING!

Thank you for reconsidering as I know this was brought up by others in the past.

I'd even take it as optional (as I'd always have that new way option ON).

[MrDDT]

Awesome work! Looks good, I think this is pretty much the best of both worlds without messing up either.

[MrDDT]

60590

Okay. You've convinced me to take another look at it. I may have a solution that meets your needs. It preserves the color in overlapping light areas while ensuring that the light value is represented in at least one color channel. E.g. when full intensity white overlaps with full intensity red, the result is RGB -> 1.0, 0.5, 0.5. (light pink). In the attached image you can see the same lighting in the current version (left) and the new method (right). I'll chat with John about it next week. It would likely be a per image option with existing images set to the old method and new images potentially set to the new method.



What about dim colored lighting, with bright white lighting? How would that play out? Will we be able to see some of the color from the dim?

[pindercarl]

What about dim colored lighting, with bright white lighting? How would that play out? Will we be able to see some of the color from the dim?

60595

Same lighting as previous example, but the colored lights are at half intensity.

[HywelPhillips]

That's certainly an improvement, although it has got some unphysical features still (the arc of paler light through the white light source, for example).

The ideal would still be to do the math in a log space or LAB or HSL colour model to avoid this immediate clipping to white. Maybe even just trying doing the calculations with an inverse gamma transform, then applying the gamma transform again?

https://gmshaders.com/tutorials/tips_and_tricks/

//Useful on textures because they are already gamma-encoded.
vec3 decode = pow(color.rgb, vec3(0.4545));
//Useful with linear gradients or lighting. It should be the last step.
vec3 encode = pow(color.rgb, vec3(2.2));

But that does mean doing computations in float rather than integer which may not possible the way FGU is set up to render, I don't know. I thought Unity always used float for shaders (https://docs.unity3d.com/2020.1/Documentation/Manual/SL-ShaderPerformance.html ) but of course I've no idea how you are actually doing the processing.

[SilentRuin]

60595

Same lighting as previous example, but the colored lights are at half intensity.

I'm completely satisfied as this solves all the issues I presented (bright white light wipes out all other colored lights, dim white light wipes out all other dim colored lights).

Look forward to update.

[mlbrown]

NVM I was replying to an earlier comment, and see that this is being addressed to correctly show light sources.

[Griogre]

Thanks for spending the time on this Carl! :)

[Lo Zeno]

60595

Same lighting as previous example, but the colored lights are at half intensity.

I agree with HywelPhillips that there's still margin to improve, but man this is already so much better.
It goes to show that realism doesn't always equate to a better playing experience

[pindercarl]

I agree with HywelPhillips that there's still margin to improve, but man this is already so much better.
It goes to show that realism doesn't always equate to a better playing experience

HywellPhillips had some good suggestions. Biasing the intensity toward green (perceived intensity) looks better, but red lights nearly disappear. Similarly, gamma correction improves the appearance of the light, but reduces the intensity of dim values. Both improve the appearance, but at the expense of the goal. The examples shown are at the extreme end of the color preservation. In most situations, I would expect the results to be less dramatic.

[HywelPhillips]

Glad the suggestions were useful.

The current industry state-of-the-art is ACES (Academy Color Encoding System, devised by the Academy of Motion Pictures Arts and Sciences ie the Oscars people).

Take a look at the two examples of rendering and image in sRGB (what I assume FGU is working in) vs ACEScg on this page:
https://acescolorspace.com

Notice the difference in the ugly clipping to white on the highlights, which is the same problem as FGU has with assuming bright light is maximum white = 255,255,255.

The problem is there's nowhere to go from there. You can't register any hues because you have no headroom left - add red light 255,0,0 to FGU's bright white 255,255,255 and you get white light 255,255,255. Whereas human perception, which works logarithmically, would effectively "rescale" this to 510,255,255 then constrict the pupil to reduce overall exposure and produce a perceived light of something more like 255,200,200 (-ish) - a definite pink tinge.

How exactly does one handle this? Normally by going to a wider gamut higher dynamic range working space (like one of the ACES ones) doing the calculations there and then mapping back to sRGB values for display as the final step.

Carl, have you looked into the possibility of doing the calculations in a different colour space and transforming back to sRGB at the end?
https://acescolorspace.com
has some excellent tools for getting started and seeing how it works, and ACES is provided free to the industry/community.

There may already be Unity utilities available as a lot of work is going into things like LED Volumes for film production and they're all hitting these sorts of clipping issues. OpenColorIO is an opensource tool from Sony Imageworks to facilitate this for example.

Because this is a largely solved problem since ACES came out a few years ago, and the whole of the camera/post-house industry is shifting over to it. I don't believe it is too heavyweight to do for FGU once you've got your head around it because it's intended for heavy duty data flows like 8K+ motion pictures, LED volumes and the like.

A quick Google of the Unity docs shows that Filmic (ACES) is an option for post-processing in Unity:
https://docs.unity3d.com/560/Documentation/Manual/PostProcessing-ColorGrading.html

So there is already SOMETHING implemented in Unity... maybe worth a look?

Cheers, Hywel

[pindercarl]

Glad the suggestions were useful.

The current industry state-of-the-art is ACES (Academy Color Encoding System, devised by the Academy of Motion Pictures Arts and Sciences ie the Oscars people).

Take a look at the two examples of rendering and image in sRGB (what I assume FGU is working in) vs ACEScg on this page:
https://acescolorspace.com

Notice the difference in the ugly clipping to white on the highlights, which is the same problem as FGU has with assuming bright light is maximum white = 255,255,255.

The problem is there's nowhere to go from there. You can't register any hues because you have no headroom left - add red light 255,0,0 to FGU's bright white 255,255,255 and you get white light 255,255,255. Whereas human perception, which works logarithmically, would effectively "rescale" this to 510,255,255 then constrict the pupil to reduce overall exposure and produce a perceived light of something more like 255,200,200 (-ish) - a definite pink tinge.

How exactly does one handle this? Normally by going to a wider gamut higher dynamic range working space (like one of the ACES ones) doing the calculations there and then mapping back to sRGB values for display as the final step.

Carl, have you looked into the possibility of doing the calculations in a different colour space and transforming back to sRGB at the end?
https://acescolorspace.com
has some excellent tools for getting started and seeing how it works, and ACES is provided free to the industry/community.

There may already be Unity utilities available as a lot of work is going into things like LED Volumes for film production and they're all hitting these sorts of clipping issues. OpenColorIO is an opensource tool from Sony Imageworks to facilitate this for example.

Because this is a largely solved problem since ACES came out a few years ago, and the whole of the camera/post-house industry is shifting over to it. I don't believe it is too heavyweight to do for FGU once you've got your head around it because it's intended for heavy duty data flows like 8K+ motion pictures, LED volumes and the like.

A quick Google of the Unity docs shows that Filmic (ACES) is an option for post-processing in Unity:
https://docs.unity3d.com/560/Documentation/Manual/PostProcessing-ColorGrading.html

So there is already SOMETHING implemented in Unity... maybe worth a look?

Cheers, Hywel

Thanks for the suggestions. Any sort of exposure control is going to modify the values of the lights. Since these have a mechanical meaning within many rulesets (5E, in particular) changing the values for the purposes of appearance contradicts that stated goal of preserving color information without modifying the light intensity, e.g., bright light is 1.0 and dim light is 0.5.

[HywelPhillips]

So is the issue that you need for game mechanical purposes to assess how bright the light is at a certain spot on the map?

So for example is the 5E ruleset doing a test on whether a token is in bright or dim or no light and applying to-hit penalties accordingly? (Or COULD do in principle even if not currently implemented that way?) In other words do you need to read the rendered intensity of the light back to the ruleset and take actions accordingly?

That certainly would make it trickier.

But I wouldn't have thought it ought to be prohibitive- for the sorts of tints and colours we've been describing, wouldn't a range of brightnesses in the test be adequate i.e. if brightness > 0.8 (summing over RGB suitably, whatever your preferred method) then its bright light, brightness 0.3 to 0.8 is dim light, etc.?


If the issue is only a rendering one though working in a higher dynamic range space is probably the answer. All your bright lights can still be 255,255,255. It's just when you come to work out how to render than on the map that you need to figure out what happens if you overlap two bright lights, especially if they are of different colours. If the ruleset isn't reading the final intensity back from the map, it doesn't matter if a 255,255,255 light doesn't render exactly the brightest white you could render - indeed, you probably don't want it to, precisely to allow for some headroom for highlights not to clip.

This is exactly the use case in https://acescolorspace.com/ in Use Case 1 - Image conversion for use as a texture. The map is the texture image, the lights are illuminants with maximum brightness 1, and ACEScg effectively remaps this to a space with maximum brightness 16, does the calculation there by use of a transform (Utility - sRGB - Texture) to account for this difference in mapping of maximum brightness. Then apply the display transform to get back to sRGB at the end and you should get a much more nicely shaded version for display without having to change the game-system values of 1 = bright light?

Cheers, Hywel

[pindercarl]

So is the issue that you need for game mechanical purposes to assess how bright the light is at a certain spot on the map?

So for example is the 5E ruleset doing a test on whether a token is in bright or dim or no light and applying to-hit penalties accordingly? (Or COULD do in principle even if not currently implemented that way?) In other words do you need to read the rendered intensity of the light back to the ruleset and take actions accordingly?

That certainly would make it trickier.

But I wouldn't have thought it ought to be prohibitive- for the sorts of tints and colours we've been describing, wouldn't a range of brightnesses in the test be adequate i.e. if brightness > 0.8 (summing over RGB suitably, whatever your preferred method) then its bright light, brightness 0.3 to 0.8 is dim light, etc.?


If the issue is only a rendering one though working in a higher dynamic range space is probably the answer. All your bright lights can still be 255,255,255. It's just when you come to work out how to render than on the map that you need to figure out what happens if you overlap two bright lights, especially if they are of different colours. If the ruleset isn't reading the final intensity back from the map, it doesn't matter if a 255,255,255 light doesn't render exactly the brightest white you could render - indeed, you probably don't want it to, precisely to allow for some headroom for highlights not to clip.

This is exactly the use case in https://acescolorspace.com/ in Use Case 1 - Image conversion for use as a texture. The map is the texture image, the lights are illuminants with maximum brightness 1, and ACEScg effectively remaps this to a space with maximum brightness 16, does the calculation there by use of a transform (Utility - sRGB - Texture) to account for this difference in mapping of maximum brightness. Then apply the display transform to get back to sRGB at the end and you should get a much more nicely shaded version for display without having to change the game-system values of 1 = bright light?

Cheers, Hywel

I appreciate the input. I think I've addressed why we won't be applying any post-processing to the lighting. Thanks again.

[johnecc]

Are we forgetting that this is a representation of a tabletop role playing environment to allow us to play a game remotely? When was the last time you had coloured lights in a face to face game?

Yes it is nice to have, but do we really need to be arguing about industry standards that are probably for film or video games (not sure because I haven’t read them, nor have a desire to).

Just my opinion. I think Carl and Smiteworks have done outstanding work getting us what we have.

[Lo Zeno]

When was the last time you had coloured lights in a face to face game?

Apple to oranges. In a face to face game we don't have line of sight, combat automation, animated tokens, automatic distance calculation and so on.
A VTT is not a physical table and allows things that can't be achieved in a traditional face to face, pen and paper game; the fact that we don't have coloured lights in a face to face game is completely irrelevant.

[HywelPhillips]

Umm, I wasn't arguing, I was trying to help, and to understand the issues. I am also relatively happy with the solution as it stands presently - I've not made any noise about it since the last round of threads several years ago when lighting first came out.

FGU is literally built using a video game engine, and the problem we're discussing (colour channels clipping to white in an unattractive way) is a long-standing issue in the both the video game and the film industry. I happen to be a physicist-turned-cinematographer, I was just pointing out that this particular problem - the rendering of overlapping coloured lights in the presence of super-white values above the nominal white point of 255,255,255 has been solved. I know about that solution from my day job, and I was just trying to point out some resources that exist within the framework that FGU is developed in that might help if a more comprehensive solution to this rendering problem is required.

I'm absolutely happy with Carl's decision not to go down the road of that solution because it's not suitable for the requirements of FGU as a VTT, and I was just trying to understand exactly what those issues are in my last reply. (Because physicist and therefore curious).

For my own games I still use the formula I recommended people to use a couple of years ago, which I'll restate here for completeness:


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.

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.

For general use where you just want to know if the character can see or not, sticking with FGU defaults for lights won't send you far wrong, although you will have some unphysical artefacts where lights overlap that will look weird to some. Carl's new shading procedure looks like a worthwhile improvement without going to the full solution of working in a different colour space, which he has explained they're not going to adopt.

If you want to make an impressive cinematic scene with coloured lights in FGU today, stick to my advice quoted above and tone any lights carried by the characters down to alpha 200 or so, avoid overlapping the coloured lights on the map, and you'll get a perfectly serviceable and atmospheric result, which Carl's optional rendering mode should improve still further.

Cheers, Hywel

[rocketvaultgames]

Are we forgetting that this is a representation of a tabletop role playing environment to allow us to play a game remotely? When was the last time you had coloured lights in a face to face game?

Yes it is nice to have, but do we really need to be arguing about industry standards that are probably for film or video games (not sure because I haven’t read them, nor have a desire to).

Just my opinion. I think Carl and Smiteworks have done outstanding work getting us what we have.

Literally last night. PCs manipulated some arcane machinery. Altar changed from glowing purple to glowing yellow. I hit 1 button on the stream deck and all the DMX lights (except the pin spots on the dice trays) shifted smoothly from purple to yellow... and the players smiled and said 'woah. cool.'

I didn't bother changing the light on the map, as there would have been no discernable difference under the current implementation.

[rocketvaultgames]

Umm, I wasn't arguing, I was trying to help, and to understand the issues. I am also relatively happy with the solution as it stands presently - I've not made any noise about it since the last round of threads several years ago when lighting first came out.

FGU is literally built using a video game engine, and the problem we're discussing (colour channels clipping to white in an unattractive way) is a long-standing issue in the both the video game and the film industry. I happen to be a physicist-turned-cinematographer, I was just pointing out that this particular problem - the rendering of overlapping coloured lights in the presence of super-white values above the nominal white point of 255,255,255 has been solved. I know about that solution from my day job, and I was just trying to point out some resources that exist within the framework that FGU is developed in that might help if a more comprehensive solution to this rendering problem is required.

I'm absolutely happy with Carl's decision not to go down the road of that solution because it's not suitable for the requirements of FGU as a VTT, and I was just trying to understand exactly what those issues are in my last reply. (Because physicist and therefore curious).

For my own games I still use the formula I recommended people to use a couple of years ago, which I'll restate here for completeness:



For general use where you just want to know if the character can see or not, sticking with FGU defaults for lights won't send you far wrong, although you will have some unphysical artefacts where lights overlap that will look weird to some. Carl's new shading procedure looks like a worthwhile improvement without going to the full solution of working in a different colour space, which he has explained they're not going to adopt.

If you want to make an impressive cinematic scene with coloured lights in FGU today, stick to my advice quoted above and tone any lights carried by the characters down to alpha 200 or so, avoid overlapping the coloured lights on the map, and you'll get a perfectly serviceable and atmospheric result, which Carl's optional rendering mode should improve still further.

Cheers, Hywel

Everything you have contributed here has been utterly fascinating. Thank you so much for the detailed explanations!

I do think the current proposed change will be a "good enough" improvement that is vastly better than it is now, and I suspect using some of your tips above, I will start exploring using colored lights again.

[Arghun]

Some in depth discussion on the technicalities of lighting here https://www.fantasygrounds.com/forums/showthread.php?68472-Two-colored-lights-placed-nearby-removes-the-color

And, no it isn't a bug. It's meant to be that way since that's how it's programmed.

It is a 'usability' bug. Programming only serves one purpose: meeting customer needs. If a programmed feature doesn't work for users then it can be considered as a bug. That's what happens in my company which is major software company. While I understand your point I beg to disagree with you.

[SilentRuin]

My goal in posting has been met by Carl's solution. The only concern I have is that of lights defined - dim or bright - can be lost completely. Its a relatively simple thing to make this, as Carl has shown, so that it can be no longer an issue.

Cameras, video = trying to mimic realism. Can be expensive in processing/gpu to this in certain fixed environments - which FGU is.

Realism is not a game.

My post is to address purely game issues. I'm sure there a numerous solutions (as in most coding) to approach the problem, but I don't want to get lost in "they gave us and inch, lets see if we can take a mile" as I was very familiar with this in my coding days and even today in my extension coding days. I'm ruthless in maintaining "good enough".

The solution carl has shown is "good enough" - if he wishes to do more that's up to him. But based on performance etc. - and what he has told us - this solution is "good enough".

I'll take the inch.

Others can battle for a mile.

Looking forward to seeing faery fire and other effects in all types of lighting (unless they are the same of course) in FGU.

[Jiminimonka]

My goal in posting has been met by Carl's solution. The only concern I have is that of lights defined - dim or bright - can be lost completely. Its a relatively simple thing to make this, as Carl has shown, so that it can be no longer an issue.

Cameras, video = trying to mimic realism. Can be expensive in processing/gpu to this in certain fixed environments - which FGU is.

Realism is not a game.

My post is to address purely game issues. I'm sure there a numerous solutions (as in most coding) to approach the problem, but I don't want to get lost in "they gave us and inch, lets see if we can take a mile" as I was very familiar with this in my coding days and even today in my extension coding days. I'm ruthless in maintaining "good enough".

The solution carl has shown is "good enough" - if he wishes to do more that's up to him. But based on performance etc. - and what he has told us - this solution is "good enough".

I'll take the inch.

Others can battle for a mile.

Looking forward to seeing faery fire and other effects in all types of lighting (unless they are the same of course) in FGU.

Well said.

[SilentRuin]

I appreciate the input. I think I've addressed why we won't be applying any post-processing to the lighting. Thanks again.

Any idea when we might see this change? I thought maybe this last Tuesday update but was not to be :(

[superteddy57]

When the testing of the changes is finished. We don't want to introduce any new issues with the changes.

[SilentRuin]

Very reasonable. I only asked as once again my players got in a session with Rhime of the Frostmaiden in the Jarlsmoot map and lit 6 braziers - of which you could not see one of the colors as they were all wiped out by a lantern (and the white light among the braziers).

[Moon Wizard]

I just pushed an update today for the changes provided by @pindercarl. Please run a new Check for Updates and try again.

Regards,
JPG

[SilentRuin]

MUCH better than it was - though it still does not show the true light in the immediate 5ft area it comes out of or some muted version of it.

Here are my tests (Most have background of moonlight):

Kelvin with bright lantern with two Invisible Stalkers made visible by faery fire of blue and green on the dim edge of lantern light. This is DIM white vs DIM blue vs DIM green - very acceptable result.

60718

Kelvin moves his bright light in range of dim light of faery fires. Not what I'd consider a good result as I said in original post something of the color - even muted should be visible near core of dim light. Bright White light wipes out all other dim colors.

60719

Faery Fires are set to bright - very acceptable where Bright light does not wipe out bright other colors.

60720

Only dim faery fires with moonlight background lighting. Very acceptable.

60721

Multiple bright fires of different colors overlapping with Kelvin also near with his bright white light. No core lighting is visible at all just the blend. Better than it was but not what I'd call a good result as I should be able to tell the color of the bright light near each core light.

60722


Overall much better than it was - but still not seeing that core lighting dim or bright standing out when a similar or greater strength light is near. Unless the lights literally overlap their cores I would think you could see the color of the core.

[HywelPhillips]

Try setting your bright light to Alpha 200 instead of 255 in the second example, SilentRuin. That might give you enough headroom to avoid the highlights clipping to white.

[SilentRuin]

Try setting your bright light to Alpha 200 instead of 255 in the second example, SilentRuin. That might give you enough headroom to avoid the highlights clipping to white.

I know that as a workaround but there is no way I'm going around changing the many lighting behaviors and backgrounds that are bright to compensate for this. Way to much time and effort. And likely would have to do for every new campaign with a new default "lantern, torch, etc." in it - not to even mention effect definitions.

Just stating how lighting by default should work. This is way better than it was, just missing the "glow" of original lighting in the surrounding squares even if faint. Visible lighting is visible and invisible lighting is - well... not.

[Jiminimonka]

This is one of things I hadn't noticed much before, but I think Silent Ruin is onto something here.