To be honest, I don't use default gamma and brightness for ages by now. Is it an issue? Do people here want to see it fixed? Windows support if we want to see this HDR in a window, rather than exclusive fullscreen.īack to color banding. graphics driver that can communicate to that screen and can translate from OpenGL, and 3. a screen that understands more than just linear color space, 2. So even if we get better color range in video memory, we still need 1. Similarly, Windows DWM only knows about 8 bits per color in linear space. The shocking conclusion (unless I am wrong) is, there's no way to actually display this improved picture to the end-user because your digital screen still can only show the same fixed colors. The idea behind it was, AFAI understand it, to give more precision in low-range (darker shades) which, if done properly would have effectively eliminated color banding. The gamma compensation works well for me but it's not actually how it was supposed to be used. Returning to sRGB feature I was playing with. If you want to light up the dark areas without overbrightening what's already well lit, then what about crunching up the main ambient light? Why are people stuck with non-default gamma/brightness? Is the picture too dark for them? Why is it a bad idea to just give them control over r_lightScale instead (lightgem excused)?Ģ. I would like to hear from everybody interestedġ. Same applies to postprocessing, unless it squashes all low-range pixels to black. It should mean that any non-default (1) value for r_gamma and r_brightness will absolutely result in loss of color precision. If your screen is cheap, you can get 64 instead of 256 (18-bit panels). I mean, there's exactly 256 grades of each color component that your screen can show, with any given backlight intensity. I take it for granted that everyone today is on digital-interface screens. ![]() In the end, it all boils down to your own perception - is the picture too dark or bleached out? (See the attached pictures) Toggling this option should give you some control over that.ĭone more web research and it gets frustrating. You obviously run TDM on an LCD that, theoretically, has nothing to do with CRT's non-linear input/output curves. ![]() Q: What is gamma again and why do I need to bother?Ī: It's all about your monitor. The sRGB values are fixed and cannot be adjusted AFAIK. Do I have the same options with sRGB?Ī: No. Q: But r_gamma allows me to tweak the correction to the level I'm most comfortable with. Total assets rebuild is not something anyone wants. Q: What about non-light materials, such as environment cubemaps, emissives, etc?Ī: It probably does not make sense to apply this color correction to them as it would break existing missions. On the other hand we can now use extended range framebuffer formats (e.g. We should probably drop r_ambientMinLevel completely as it's a worse option and clutters the shader code.Ī: Regret it's still there, and it might be the only deterioration compared to r_ambientMinLevel. This alternative works with all lights, and accurately does additive blending on them. Q: How is it better than r_ambientMinLevel?Ī: The latter cvar only applies to ambient lights (and arguably makes small ambient lights ugly). Other system windows, 2D and GUI remain un-bleached ![]() It seems like a good replacement for shader-level ambient crutch-up like I did way before with r_ambientMinLevelĪ: It only affects the 3D world.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |