Note that this thread is written by me as part of a progress/discovery into those topics. A lot of the information and views from me presented here might be outdated, and not all have been addressed later on in this thread. So take everything with an extra grain of salt.

Original titel was "On Gamma handling in Unreal.", but I now changed it to more accurately represent the topic.
--Present Han

For a bit of background information you might want to read this article first:
http://gamedevelopment.tutsplus.com/articles/gamma-correction-and-why-it-matters...

Unreal content and rendering was initially designed for *not* performing any gamma correction on output, instead the gamma correction was preapplied to the texture resources themself. The table below shows a rough estimate on the gamma values used on the textures.

Surfaces	1.6-1.9
Meshes	2.0
Tiles/Sprites	1.65
Editor Actor Sprites	2.2

Most certainly they descided to render this incorrect way at the expense of poor lighting, to avoid heavy artifacts which would otherwise be introduced by limitations of that time (Thief 1/2 is a good example for the "correct" way around that time, which introduced heavy artifacts). Everything in rendering was build around and/or counter issues with the gamma incorrect rendering. Also in case of mesh skins, they used some heavy contrast enrichment (sigmoidal is my current educated guess).

Probably the best RenDev and version to judge how unreal intially looked like is Software Rendering on version 200. It shows some very well balanced lightning.
I made some tests to mimic the rendering behaviour of the 200er SoftDrv version, if you have Unreal 226b installed and want to give it a try: http://coding.hanfling.de/NoGamma226b-20150328.zip (If there is some interesst I can make an also 227i build of it, but it's mostly a demo for surface lighting, not intended for productive use).

Otherwise here are some screenshots:








Note that the more saturated look by GlideDrv was caused by a combination of a slight output gamma "correction" (1.25 by default) and probably the pyramide scaling which was neither linear nor quadratic. Maybe even it didn't handle color saturation at all correct or consistent.

So much for the nostalgic how it was part. The really complicated things start when one wants to turn the gamma incorrect rendering in some gamma correct rendering to improve the odd lighting. Basically it involves three parts: Using correct gamma correction on output (based on monitor!), adjusting textures to contain or to be loaded as linear data (gamma correcton, removing the extreme contrast enhencements on mesh textures, etc.), and the lighting itsself.

While the first part is straight forward, the second part about adjusting resources will become much of work and also include to develop a toolchain for ease of converting existing resources (I currently have something in development for this task).

The really complicated part starts regarding the lighting. It basically splits into two issues. One needs to adjust the overal light levels, which is probably creating another drop off function for the light data itsself, but the more problem point is to keep the color saturation levels as this is heavily influenced by this adjustment.

So much for now.

Looks like I need to revise my previous findings slightly. The resources themself seem to be stored with a gamma of 2.2, but instead are using a different RGB color space. My current assumption is that most surface textures (or at least the ones I checked) are stored in  Adobe Wide Gamut RGB color space while most mesh textures appear to be stored in Adobe RGB color space. However, this requires a more detailed analysis, as maybe other similar color spaces might be involved. Any informations about tools they used for creating the textures might be helpful to create a candidate list for the color spaces.

For Unreal it currently seems to work best to assume Apple RGB colorspace on most of the textures, while the textures in Nerf appear to be all in sRGB color space. So at least for Nerf getting the (solid) textures classified in terms of the right color space and generate mipmaps accordingly shouldn't be much work. For Unreal it will probably end up in beeing much of an on a per texture basis work, where I would need some decent higher quality display to get optimal results.

I came up with a light attenuation function for linear rendering which reessembles the overall behaviour and especially the light levels of the old weired distance attenuation code without the dimming issue when objects are too close to lightsources.

The basic form is:

(1-smoothstep(a*(LightRadius+b),u*(LightRadius+v),Distance))^2; 

where smoothstep is as defined in the GLSL spec and the parameters a,b,u,v are in the ranges shown in the table below

Parameter:	Range:
a	0-2
b	0-1
u	20-25
v	0-1

Additionally these parameters needs to satisfy the following relation as otherwise smoothstep is undefined:

a*(LightRadius+b) < u*(LightRadius+v) 

The old attentuation function has its maximum at approximatly 2*(LightRadius+1) and fell below a 1/512 = ~0.002 threshould (e.g. will definetly end up as zero in the results) at approx 21*(LightRadius+1).

I plotted some comparision for the effect of a dead on angle on a white texture while approximating the effect of the "old" ~sRGB rendering with a gamma of 2.2:
http://coding.hanfling.de/UnrealSmoothStepAttenuation.pdf

One motivation for prefering the smoothstep approach over some "physically more correct" 1/r^2 attentuation for point light source is too think of LightRadius also beeing a parameter controlling the physical extend of the light source itsself. If you are "close" to an extended light source, the light source itsself will appear flat and infinitly extended and thus the light intensity stays approximatly constant. This is basically the same geometric consideration as you might have heared in school for a horseshoe magnet or a parallel plate capacitor.

In other news, I made some progress on the toolchain front too. I wrote an UExporter for exporting bitmap fonts with correctly rebuild borders around the glyphs and an UExporter an a UFactory for exporting UPalettes to ACT (Adobe Color Table) files. Sadly ACT is just 24 bit, but this should be sufficient nontheless.

The idea behind the UPalettes UFactory/UExporter is that one hand I cannot use P8 textures for storing sufficient quality mipmaps, but they are still needed for the palette based light effects. Also this is a step towards exporting/reimporting fractal textures, where for most of them the palette is crucial. My plan for exporting/reimporting fractal textures is basically to use some sort of an ini file to store the properties of the fractal texture and it's sparks.

I conclude for now with some screenshots showing the effect of scaling the light based on the Brightness setting rather then messing with the gamma ramp to control the brightness. The screenshots are done using linear rendering, but the results are similar to those one gets when using the old non linear rendering.

Alright, I implemented support for generating mipmaps in CIELAB and CIELUV space.

Though I probably posted this before, the motivation is based on this paper by Burger pointing out that performing linear filtering in neither sRGB nor linearized sRGB is actually a good choice while at the same time suggesting to use CIELAB or CIELUV.

Comparission:
http://coding.hanfling.de/MipsFilter.bmp

Legend:
a) Mips generated in sRGB space, filtered in sRGB space ingame
b) Mips generated in linear (sRGB) space, filter in linear (sRGB) space ingame.
c) Mips generated in CIELAB, filtered in linear (sRGB) space ingame.
d) Mips generated in CIELUV, filtered in linear (sRGB) space ingame.

I haven't done any excessive testing yet, but wanted to give some road with a white stripe a test as this usually always ends up in some bloating of the white stripe after anisotropic filtering gives up (I guess my driver settings enforced 8x anisotropic filtering for this shot).

The differences are certainly just minor, but imho the white bloating is slighty reduced when generating the mipmaps in CIELAB or CIELUV space, so I'm curious to try out if storing the texture data in CIELAB to make the GPU filter it linear in CIELAB space, and afterwards convert it to (linearized) sRGB inside the fragment shader will further reduce this effect *and* whether this will hopefully provide more pleasant texture magnification.

One further note towards a), which doesn't seem far off towards b). Especially in case the diffuse textures are rather dark like in Deus Ex, a) will cause a clearly noticable and odd darkening in the distance effect, while b) works fine.

However, CIELUV is a bitch. Take a look at the CIEXYZ<=>CIELUV transformations on Bruce Lindblooms really helpful site:
http://www.brucelindbloom.com/index.html?Eqn_XYZ_to_Luv.html
http://www.brucelindbloom.com/index.html?Eqn_Luv_to_XYZ.html

For XYZ -> LUV: In case of (X+15Y+3Z)==0 you get divide by zero errors for u' and v'. My current workaround is to set LUV=(0,0,0) in case (X+15Y+3Z)<SMALL_VALUE, however just L=0 makes sense in this case, for U and V this is more like some "what else" kind of choice. I think one approach for selecting UV in this particular case would be on some sort of what would provide the the most desireble results for a texture filtered towards a black hole.

For LUV -> XYZ: In case of (u+14*L*u0)==0 and/or (v+14*L*v0)==0 you get a divide by zero for a and/or d respectivly. My (not bulletproof) current solution is to check whether L<SMALL_NUMBER and -- as this is black -- set the XYZ values to (0,0,0). This seems to be sufficient for my two test textures so far. To make it bulletproof one could just clamp (L,U,V) into [0,1]x[0,1]x[0,1] and afterwards do the L<SMALL_NUMBER check. This is probably required for filters like Lanczos as values get weighted with a negative sign, so L could become negative. But I should actually add that straight ahead to be safe. However, I'll keep CIELUV for filtering unless it causes more troubles, recommend CIELAB over it and for textures storage and shader code I'll not consider it at all.

So much for now.. oh and hey.. looks like my ideal of Nerf beeing in sRGB starts to crack. For me a great amount of especially the player skins seem more right in AdobeRGB space compared to sRGB and other people I asked also can't really tell what would be more right, so at least the difference for Nerf doesnt seem that large...

Thanks for this information Hanfling, this is useful. *thumbs up*

I'll go back over my other textures and re-export them with the colour spaces you've mentioned both in this thread and IRC.

Oh and, about same scene as above on the nogamma shots, but this time rendered linear, with linear (box-) filtered mipmaps with texture input for most textures in the scene assumed as Adobe RGB. Roughly adjusted attenuation functions, lots of work left, etc. etc.

The quadratic simulated light definately looks very useful, especially simplifying what would currently be = place a bright, small radius light actor around the light source, and then make a more macro light which is emitted from the light source much thinner to cover the general area.

Good job, keep up the good work Han.

Whoa. Thanks Han, I'm going to see that everywhere now lol.