A Valve engineer fixed 3D lighting so hard he had to tell all the graphics card manufacturers their math was wrong, and the reaction was: 'I hate you'
A Valve engineer fixed 3D lighting so hard he had to tell all the graphics card manufacturers their math was wrong, and the reaction was: 'I hate you'
A Valve engineer fixed 3D lighting so hard he had to tell all the graphics card manufacturers their math was wrong, and the reaction was: 'I hate you'
Now, can we fix flashlights in games such that we don't get a well defined circle of lit area surrounded by completely a black environment? Light doesn't work that way, it bounces and scatters, meaning that a room with a light in it should almost never be completely dark. I always end up ignoring the "adjust the gamma until some wiggle is just visible" setup pages and just blow the gamma out until I can actually see a reasonable amount in the dark areas.
Yes, really dark places should be really dark. But, once you add a light to the situation, they should be a lot less dark.
Now, can we fix flashlights in games such that we don’t get a well defined circle of lit area surrounded by completely a black environment?
Sure, we can do that, but we won't because of the narrative and functional in-game purpose of the flashlight. It's not meant to be realistic, it's meant to make the game feel a specific way.
It's also why a flashlight may be able to run for dozens of hours straight on a single battery but in video games it'll die in minutes if not seconds. Realism is unfair. Also the same reason why nuclear reactors in video games are always dangerous. Because representing them realistically would be boring to the average adrenaline junkie "gamer".
You just described ray tracing. The problem is, it's incredibly computationally expensive. That's why DLSS and FSR were created to try and make up for the slow framerates.
there’s more to dynamic global illumination than just ray tracing
I've seen an awesome "kludge" method where, instead of simulating billions of photons bouncing in billions of directions off every surface in the entire world, they are taking extremely low resolution cube map snapshots from the perspective of surfaces on a "one per square(area)" basis once every couple frames and blending between them over distance to inform the diffuse lighting of a scene as if it were ambient light mapping rather than direct light. Which is cool because not only can it represent the brightness of emissive textures, but it also makes it less necessary to manually fill scenes with manually placed key lights, fill lights, and backlights.
That's exactly the sort of thing his work improved. He figured out that graphics hardware assumed all lighting intensities were linear when in fact it scaled dramatically as the RGB value increased.
Example: Red value is 128 out of 255 should be 50% of the maximum brightness, that's what the graphics cards and likely the programmers assumed, but the actual output was 22% brightness.
So you would have areas that were extremely bright immediately cut off into areas that were extremely dark.
Unreal Engine 5.5 Lumen supposedly does it well with the light scattering.
"It's a bit technical," begins Birdwell, "but the simple version is that graphics cards at the time always stored RGB textures and even displayed everything as non linear intensities, meaning that an 8 bit RGB value of 128 encodes a pixel that's about 22% as bright as a value of 255, but the graphics hardware was doing lighting calculations as though everything was linear.
"The net result was that lighting always looked off. If you were trying to shade something that was curved, the dimming due to the surface angle aiming away from the light source would get darker way too quickly. Just like the example above, something that was supposed to end up looking 50% as bright as full intensity ended up looking only 22% as bright on the display. It looked very unnatural, instead of a nice curve everything was shaded way too extreme, rounded shapes looked oddly exaggerated and there wasn’t any way to get things to work in the general case."
Made harder by brightness being perceived non - linearly. We can detect a change in brightness much easier in a dark area than a light- if the RGB value is 10%, and shifts to 15%, we'll notice it. But if it's 80% and shifts to 85%, we probably won't.
Reminds me of a video I watched where they tested human perception of 60/90/120 FPS. They had an all white screen and flashed a single frame of black at various frame rates, and participants would press a button if they saw the change. Then repeated for an all black screen and a single frame of white would flash.
At 60 and 90 FPS, most participants saw the flash. At 120 FPS, they only saw the change going from black to white.
Sick!
The guy was a fine arts major too. Bunch of stem majors couldn’t figure it out for themselves.
As a person who tends to come from the technical side, this doesn't surprise me. Without a deep understanding of the subject, how would you come up with an accurate formula or algorithm to meet your needs? And with lighting in a physical space, that would be an arts major, not a math or computing major.
Most of my best work (which I'll grant is limited) came from working with experts in their field and producing systems that matched their perspectives. I don't think this diminishes his accomplishments, bit rather emphasizes the importance of seeking out those experts and gaining an understanding of the subject matter you're working with to produce better results.
Yeah. I have a STEM degree and work in a STEM field, and it's a bummer to see just how... not well rounded people's educations are. Otherwise intelligent people that seem incapable of critical thinking.
Justice!
Fixing anything in industry is like fighting a very big, very lazy elephant seal bull
"Just code around it. This is the way it has always been done, and the way it always will be done."
Hardware takes a long time to change.
A temporary patch while we wait for hardware is the way to go.
Nothing is more permanent than a temporary fix.
They already fixed it in software we don't need to prioritize the hardware fix.
Like getting devs to stop using TAA
"the garbage trend is to produce a noisy technique and then trying to "fix" it with TAA. it's not a TAA problem, it's a noisy garbage technique problem...if you remove TAA from from a ghosty renderer, you have no alternative of what to replace it with, because the image will be so noisy that no single-shot denoiser can handle it anyway. so fundamentally it's a problem with the renderer that produced the noisy image in the first place, not a problem with TAA that denoised it temporally"
(this was Alexander Sannikov (a Path of Exile graphics dev) in an argument/discussion with Threat Interactive on the Radiance Cascades discord server, if anyone's interested)
Anyways, it's really easier said than done to "just have a less noisy technique". Most of the time, it comes down to this choice: would you like worse, blobbier lighting and shadows, or would you like a little bit of blurriness when you're moving? Screen resolution keeps getting higher, and temporal techniques such as DLSS keep getting more popular, so I think you'll find that more and more people are going to go with the TAA option.
Interesting read.
Now can somebody please fix the horrible volume sliders on everything.
I just max all the volume sliders and use voicemeeter to control the volume levels of the different audio sinks. Although I guess that doesn’t help if you’re trying to leave game sfx audio at max volume but lower in game music or something.
Started doing this and I'll never go back.
Go on
I’m impressed by how well my Steam Deck plays even unsupported games like Estival Versus.
I just wish they bundled it with a browser. Any browser even Internet Explorer would have been better than an “Install Firefox” icon that takes me to a broken store. I had to search for and enter cryptic commands to get started. I’m familiar with Debian distros and APT, what the hell is a Flatpak? Imagine coming from Windows or macOS and your first experience of Linux is the store bring broken. It was frustrating for me because even with 20 years of using and installing Linux, at least the base installation always comes with some functioning browser even if the repos are out of sync or dead.
The most recent version of Steam on the Deck addresses this if you go to the "Non-Steam Game" page. It gives you the option to install Chrome and add it as a non-steam shortcut with one click. It also has a short note about how you can easily do it with any app in Desktop Mode, and that they're working on a way to do that within the Gaming Mode interface.
Not ideal, but they're working on it. Also, would prefer Firefox obv.
What store was broken?
Edit: I ask which store, because while I prefer CLI for updating and maintaining packages on my main device, the Discover store has always worked perfectly fine for me. And if you're using it on the Steam Deck level (SteamOS is immutable), then you don't really need to understand what a Flatpak is any more than you understand what an .exe is. Think if them as literally the same thing for your purposes.
And if anything, maintaining and updating programs is way easier than Windows as it does it all automatically.
there is chrome now
Yep. Now imagine it happening in the space program, because it totally does
I think modern graphics cards are programmable enough that getting the gamma correction right is on the devs now. Which is why its commonly wrong (not in video games and engines, they mostly know what they're doing). Windows image viewer, imageglass, firefox, and even blender do the color blending in images without gamma correction (For its actual rendering, Blender does things properly in the XYZ color space, its just the image sampling that's different, and only in Cycles). It's basically the standard, even though it leads to these weird zooming effects on pixel-perfect images as well as color darkening and weird hue shifts, while being imperceptibly different in all other cases.
If you want to test a program yourself, use this image:
Try zooming in and out. Even if the image is scaled, the left side should look the same as the bottom of the right side, not the top. It should also look roughly like the same color regardless of its scale (excluding some moire patterns).
On that web page, the left side is similar to the bottom, but on Lemmy, the left side looks purple like the top right. The bottom right appears grey to me. Is that supposed to happen?
Same experience here. On the website, the left side never fully matched either shade on the right side to me, appearing closer to the bottom but always somewhere in between most of the time. But when I view the screenshot linked above in my mobile app for Lemmy, it looks a lot closer to the top than the bottom, but varies a bit based on how much I zoom in (almost like moire patterns).
On, Lemmy the image is definitely not producing the same effect as on the website. On the phone, I can do incremental zooms of the page. If I zoom very lightly there is a sweet spot where it looks exactly like the top, but fully zoomed out(the default view) it is looking the same as the bottom. Clearly there is a problem with scaling the image unlike what /u/AdrianTheFrog said
People here have no idea how any of this works, or why the lighting was off.
CRT monitors did not display light intensity linearly. Remember gamma ? That was it, gamma correction. Gpu chips at the time practically had to have that in. And it didn't even matter that much if it was a bit off because our eyes are not linear. Like remember quake ? Nobody cared quake was not color accurate.
The gpu manufacturers knew it all, be it nvidia, ati, 3dfx. Color spaces were well known, and nobody had a color accurate monitor at home anyway. Even today you can buy a monitor that's way off.
Maybe that guy did get them to care more about it, but I can not read such a "hateful" article to make a conclusion (I did skim it).
Anyway none of it matters now when color is in 32bit floats and all the APIs support multiple color spaces.
It's impressive how many times Valve goes "fine, I'll do it myself":
to list but very few
You mean the mouse and keyboard?
Also Wayland in Linux wasn't improving as fast as they'd like so they're creating their own development protocol for that too lol
The whole "don't reinvent the wheel" mantra in software development is strong, and for very good reason. When a company basically does so, repeatedly, and are repeatedly successful at it, that truly is notable.
I guess that's just your comment though, with more words and no examples lol