[posila] [0.18.0] surface.min_brightness issue

[Yehn]

Setting game.surfaces[1].min_brightness to 0 does not make the map completely dark/black outside of light fields at the darkest portions of the night.

[posila]

It indeed does not: https://lua-api.factorio.com/0.18.0/Lua ... brightness

• LuaSurface::min_brightness doesn't have any effect on rendering as brightness of night depends only on color LUT of night.

The solution is to create pitch black night LUT and modify daytime_color_lookup in utility-constants.lua.
However, I am aware this is not good general solution and is weaker than what min_brightness allowed to do (for example if you want main surface with normal night, but second surface with pitch black night), so I am searching for use cases to figure out what is the best way to expose more functionality around this.

Are making scenario (without any mod dependency), or are you making mod?

[cogito123]

Hi,

That's also an issue in my scenario. Having surface as dark as possible during the night was part of a game. What's this "LUT" thingy and how can I use it, in scenario code?

[Dupl3xxx]

Being able to make the night 'fully black' is really useful as part of scenarios like 'eternal night'. It also means lights are a lot more valuable. It's also a great way to hide map-borders for things like 'underground' maps.

[posila]

Thanks for the feedback.
It seems to me min_brightness was used just for making night pitch black. For 0.18.1 I've added property LuaSurface::brightness_visual_weights of type Color. It defaults to {0, 0, 0}, which is current behavior of not having any effect at all.

The engine will use it as following:

Code: Select all

color_no_light = lookup_color(game_view_pixel_color) * ((1 - weight) + brightness * weight))

(where lookup_color is function that does color lookup using LUTs defined in utility-constants.daytime_color_lookup or utility-constants.zoom_to_world_daytime_color_lookup)

So, if you leave min_brightness at it's default value of 0.15, you can set brightness_visual_weights to { 1 / 0.85, 1 / 0.85, 1 / 0.85 } which will make color_no_light black at brightness 0.15. Negative values will make the result brighter; setting different values for different color channels will tint the night, etc.

Now question is, if min_brightness is usefull at all now, since it doesn't have any effect on energy output of solar panels.

[Yehn]

It seems to me min_brightness was used just for making night pitch black.

The mod that I use this as a part of is called "Clockwork". While I think the most common use case is to make nights as dark as possible, that is by no means a requirement. At least pre-18, it could also be used, of course, to make nights brighter - perhaps helping those without the best monitors or without the best vision still see, or help when recording videos as some recording apps tend to darken the resulting video.

On the more pragmatic side, I'm a bit concerned about the accessibility of this new function of the API. It's, naturally, a lot more intuitive to expose my users to a single value and say "increase this if you want brighter nights, set it to 0 if you want pitch black spooky nights." I'll need to play around with it to see if I can find a way to simplify it on the lua side, I suppose, but this is much more roundabout now...

[posila]

That sounds fine to me. Ideally, you'd author couple of LUTs that look good (take a screenshot of the game in daytime, put identity LUT to corner, then make the screenshot look like night in your favourite image editor, copy now modified LUT from corner of the image back to separate file and use that in the game), and give an option to chose one. In the worst case, you can change daytime_color_lookup in utility-constants.lua to always use identity (so no color transformation) and set brightness_visual_weights. Since set weigth per color channel, you can even emulate blue tint of vanilla night.