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

[Griogre]

Thanks for spending the time on this Carl!

[Lo Zeno]

Attachment 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/Documen...orGrading.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/Documen...orGrading.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