NERRRRRRRRRRRRRRRRRDTynach wrote: Sat Nov 09, 2019 10:53 am It would be a crime for me not to respond to this Friday Facts. Not only do I both love Factorio and use a calibrated monitor (and own my own colorimeter), but I've also spent the past few years writing colorspace conversion and manipulation code in GLSL, for fun.
A LUT is certainly one way to go about creating a difference between day and night, but I'm not convinced it's the best way to do it - especially when the transition from one to the other is gradual over a length of time. The use of a LUT implies you're wanting to avoid converting to and from linear light values for blending (because literally everything else would be a super inexpensive matrix multiply against the RGB values), but... It's incorrect to blend between plain RGB values and the RGB values those translate to when using the LUT, without converting both sides of the LUT into linear light values for the blend between them!
Yes, it very well might look good enough to blend between not using a LUT and using the LUT. But consider this example:
Say we have a dull red color, #B05A44, and we want to pretend to adapt the white point from a more bluish one (I found somewhere that old Sony CRT monitors had a white point with xy chromaticity coordinates of 0.283, 0.298, and that's roughly also somewhere along the 'daylight' variation of the blackbody radiation curve, so lets just use that) to D65, and then reduce the luminosity to 1/8th of its former value.
After converting the sRGB color above into a linear light value, performing both operations, and then turning it back into an sRGB color, we get #3F1E1A This is the color that winds up in our LUT to replace the above dull red color. It's much darker, and slightly bluer.
So, what about at the halfway point? For fairness (to the extent of being unfair, which I'll get to in a moment), lets try a few times at the linear light side of the comparison so that the final green channel value is the same as the 'naive' blending approach (where the naive approach just takes a direct average of the two RGB values).
Turns out, the naive approach of blending the two values together results in #773C2F... But the result should be something closer to #783C2E.
Not a major difference, mind you, but as the differences between the two colors grow, so does the difference in how they blend. Already we have a slight difference in hue between the two values.
Furthermore, this is specifically adjusting things so that the green channel is equal in both... And that's a pretty artificially skewed test. All pixels on the screen have to be darkened by the same amount, and you won't be adjusting it slightly to match a target green channel value for every single pixel. That'd be silly. The real halfway point when blending via linear light, turns out to be #663227 That's first converting sRGB's halfway point (127.5 out of 255) to linear light, and using that (about 0.214) as the factor instead of 0.5. Otherwise, the value turns out to be much brighter. When matching greens, I had to use a value of roughly 0.36.
Of course those heavily polluted areas tend to be the most frequently visited, contraindicting the changes somewhat. Maybe something in between can be found.Impatient wrote: Sat Nov 09, 2019 6:02 pm ...
Factory damaging acid rain and darker/greyer daytime colors in areas with a lot of pollution in the air (also impacting solar panel output and player health?), or ground tiles shifting their color palette into the grey once polluted - like the trees dieing - would support that narrative better.
I know factorio isn't a environment simulator but a logistics game. Still, that area has some nice opportunities for some cause-effect game mechanics, which could make it more challenging in a diversified way (meaning, not an immediate logistics problem to solve but long term decisions and impact).
When I was a kid, I saw the same image being displayed on two different computer monitors when I was at school, and wondered if there was a way to adjust the picture on one of them so that they'd match.Honktown wrote: Sat Nov 09, 2019 7:42 pm NERRRRRRRRRRRRRRRRRD
Also, where did you learn these things? This sounds interesting. I've seen a bit on color spaces when it came to monitors, and YPbPr vs RGB, but that's as much as I know
A good way to do that is to make healthy nature brighter. That increases the level of contrast for when pollution drags it back down again. That way it looks better up front, good for that shiny first impression, and it improves the aesthetic flow as a way of showing the game progression later on.I think, in general I agree with those who have wished for more contrast between a healthy looking nature and areas exploited and polluted by the player.
Re: unemployed. I know that feeling. EE and a programming job that stopped paying (literally), which forced me to go on unemployment unless the state could've made them pay in time. I was kinda hoping you were using some tutorials or even a book... the shadertoy website looks very interesting. Much easier than coding a desktop application. I forked a mod after the author was rude and ended up banging out a more thorough version, spending up to 10+ hours a day coding. Should add it to my resume, as well as "Lua scripting". Back to colors, IPS/PLS and IPS-like panels came down in cost so much in recent years, with better response times. Once I had one I had trouble dealing with TN panels (especially the garbage view angles/off-contrast).Tynach wrote: Sat Nov 09, 2019 11:26 pm When I was a kid, I saw the same image being displayed on two different computer monitors when I was at school, and wondered if there was a way to adjust the picture on one of them so that they'd match.
Fast forward to today, and I'm an unemployed programmer with waayyy too much free time, and I found out I knew enough math to mostly follow along with articles like this one (as well as various Wikipedia articles, but it was that article which let me actually use the info on Wikipedia), which led to my first real attempt to do what I'd wanted to as a kid.
Sort of. What sparked off that shader was someone claiming to be accurately portraying how old CRT monitors displayed color by doing some simple operations, and I believed their claims to be incorrect. Hence I used some (probably dubious, to be honest) data I found for the colorimetric properties of an old Sony CRT monitor, and made that shader with the bits of knowledge I learned from the articles I'd read. I chose GLSL because it operates on a per-pixel basis by default (which is what I wanted), and since I already knew about the Shadertoy website, I knew I could then send links to what I made to the people making the claim (and they could see how I was doing it and independently verify every operation).
The thing is, however, that at the time I had no way of verifying my code was correct. It looked good, and the result looked convincing, but my own display was not calibrated or anything. Still, happy that I actually made something that appeared to work and agreed with various online calculators, I kept going. I found the CVRL website with data on how human vision worked, and how the biological aspects connect to display colorimetry. I found articles discussing color blindness, tone mapping, and so on... And at each turn I'd make a new shader or three testing things out (my stuff with tone mapping is not yet public, because it sorta mixes a bunch of things together and I want to instead make it so it just showcases the tonemapping and that's it).
I'm still unemployed and have way too much free time, but at least I'm keeping my programming skills exercised and building up a portfolio. I've also used some money I got from a temporary job at a call center, to buy myself a colorimeter (and two 'factory calibrated' monitors... Which turned out to not be terribly well calibrated, but at least now I can easily fix that).
A gradual fade-in would be nice, and maybe a little icon or something to indicate it somewhere. I honestly have trouble telling the day/night cycle on occasion because the coloring and brightness aren't too much different after you've been playing for hours. At most sometimes I notice a 'snap' in the graphics when night-vision kicks off, and to me it usually looks like it's going from brighter to dimmer, so I think night is starting.Deadly-Bagel wrote: Sun Nov 10, 2019 2:17 am While we're on the subject of night, can we consider increasing the light level that nightvision toggles? Currently there's a weird time of day where it's too dark to see comfortably, but nightvision hasn't enabled itself.
We can mod this, but it'd be nicer to have a slider in the options or something.
LUTs were chosen for their convenience. Artists can take screenshot in raw colors, stick identity LUT to a corner and modify the screenshot in Photoshop until they have a look they like and then put the resulting LUT back into the game. I don't know if Photoshot can spit out matrix representing color transformations that were made to the picture.Tynach wrote: Sat Nov 09, 2019 10:53 amA LUT is certainly one way to go about creating a difference between day and night, but I'm not convinced it's the best way to do it - especially when the transition from one to the other is gradual over a length of time. The use of a LUT implies you're wanting to avoid converting to and from linear light values for blending (because literally everything else would be a super inexpensive matrix multiply against the RGB values), but... It's incorrect to blend between plain RGB values and the RGB values those translate to when using the LUT, without converting both sides of the LUT into linear light values for the blend between them!
I just have an AAS degree in 'computer programming' from a community college.. And it took me a really long time to get because of mental disorders I only got help with starting when I was 24 or so. So I don't have much when it comes to credentials on paper, and with no prior actual job experience in the field I basically have a very short resume that most of the time gets filtered out automatically, so never gets seen by an actual human being. Now I'm 29 and still living with parents.Honktown wrote: Sun Nov 10, 2019 12:39 am Re: unemployed. I know that feeling. EE and a programming job that stopped paying (literally), which forced me to go on unemployment unless the state could've made them pay in time. I was kinda hoping you were using some tutorials or even a book... the shadertoy website looks very interesting. Much easier than coding a desktop application. I forked a mod after the author was rude and ended up banging out a more thorough version, spending up to 10+ hours a day coding. Should add it to my resume, as well as "Lua scripting". Back to colors, IPS/PLS and IPS-like panels came down in cost so much in recent years, with better response times. Once I had one I had trouble dealing with TN panels (especially the garbage view angles/off-contrast).
Code: Select all
#define rgbToXyz(space)\
(space.primaries*diag(inverse((space).primaries)*(space).white))
Code: Select all
#define xyzToRgb(space)\
inverse(rgbToXyz(space))
Code: Select all
// Rough approximation of the linear-light version of the 'dull red' from the other post; values are on a scale of 0 to 1
vec3 color = vec3(0.43415, 0.10224, 0.057805);
color = conversionMatrix*color;
I wouldn't use that example. There's no gamma correction, so you won't get accurate results. Furthermore, they don't show how they derive those matrices, and they don't even use matrices at all for some reason. The main thing that GLSL does to make life easier for this, they reinvent themselves for no reason. And just now I tested their code with some color blindness test images I have, and predictably, those filters don't even work for the purpose they exist for.Honktown wrote: Sun Nov 10, 2019 12:39 am Once I got on the shadertoy site I looked for a colorblind shader:
https://www.shadertoy.com/view/MdSGRW
I wonder if I can apply it to everything. Might be a bit enlightening.
I was thinking more from a programming perspective. With matrix transformations and the like, you can apply a different white point for each light - so fire can light things up with orange and red hues, a green light can actually glow green, and moonlight more bluish.posila wrote: Sun Nov 10, 2019 9:41 amLUTs were chosen for their convenience. Artists can take screenshot in raw colors, stick identity LUT to a corner and modify the screenshot in Photoshop until they have a look they like and then put the resulting LUT back into the game. I don't know if Photoshot can spit out matrix representing color transformations that were made to the picture.Tynach wrote: Sat Nov 09, 2019 10:53 amA LUT is certainly one way to go about creating a difference between day and night, but I'm not convinced it's the best way to do it - especially when the transition from one to the other is gradual over a length of time. The use of a LUT implies you're wanting to avoid converting to and from linear light values for blending (because literally everything else would be a super inexpensive matrix multiply against the RGB values), but... It's incorrect to blend between plain RGB values and the RGB values those translate to when using the LUT, without converting both sides of the LUT into linear light values for the blend between them!
You a have a good point with blending in sRGB vs. linear RGB. In general, working with sRGB as if it was linear color space does not create much issues (there are some - for example lot of smoke sprites overlapping makes the smoke darker around borders than its in the center), but I have not considered it might cause much more severe errors when doing color grading with LUTs. It's worth looking into.