HDR and tonemapping

[ghost]

Feature request: HDR.

HOWEVER the lighting model as-is needs consolidation and some careful thought before the benefits of HDR could be properly used in the engine.

There is a good amount of discussion above and below this post in the "Re-scaling experiment" thread on the forum, arising from the changes in lighting needed to support making Oolite systems physically bigger: Oolite forum

Summary of the forum post:

• Oolite uses a white point of 0.84 because the Jim Hejl formula is used for tonemapping plus gamma correction. (remaining headroom to 1.0 must be used for representation of high dynamic range values). It has been used because it does gamma correction and generates vibrant and pleasant colors, all in one step.
• Because Jim Heijl is carefully crafted to account for gamma correction it is best not to apply any raw multipliers to its output. (Multiplication is used in "Space Nerds in Space" and looks good but would be hard to integrate with any other changes to the model.)
• If one simply needs exposure without tonemapping, then yes, multiplying the final color by a factor higher than 1.0 before the gamma correction step would suffice and no costly exp() will be needed.
• The exposure formula proposed by @AnotherCommander to @Redspear-of-oolite is also a tone mapping function (https://learnopengl.com/Advanced-Lighting/HDR), taking HDR values and normalizes everything to LDR, just in a different way from Jim Heijl. If it is used as proposed above, the end result will be two tonemapping functions in sequence.
• However, the maintainers would rather refactor and bring in "proper" HDR before stacking fancy tonemappers.

Tech note: by trial and error, @AnotherCommander has found that light calculations in Oolite can easily go up to (10.0, 10.0, 10.0) for white or maybe even a bit higher. Although technically this is higher than normal dynamic range, all this happens inside the shaders and values higher than 1.0 are truncated to 1.0 when displayed on screen. There is no rendering to floating point framebuffer, which is essential for a proper HDR implementation. So, certainly something can be gained by applying tonemapping but I am not sure if what we are actually leaving on the table can be considered too much or too little. This is why the decision for this particular tone mapper was based more on good looking results and less on technical reasons.

[AnotherCommander]

HDR on Windows is now implemented fully, with rendering to floating point framebuffer and support for up to 1000 nits display output with automatic selection of two tone mappers, depending on desired max output luminance. For maximum ouput luminance of 400, 500, 600, 800 and 1000 nits an ACES based sigmoid curve from https://knarkowicz.wordpress.com/2016/08/31/hdr-display-first-steps/ is used for tone mapping, while Reinhard is used for any other value between 400 and 1000 nits that might be requested in the future (original from https://learn.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range). The feature can be activated by passing the -hdr parameter when launching the game.

This has now been tested on a variety of HDR setups on Windows and works beautifully. Future improvements may include the implementation of an HDR calibration screen under Game Options, but for the purposes of this issue what we now have should be more than adequate.

All this is Windows only at this time. However, since Linux does not have official HDR support yet and since we are sorely missing Mac maintainers, I would like to consider the feature request complete and proceed to close. Feel free to reopen the issue if you believe that it should remain open until all ports have their own HDR implementation each, but this is something that would probably take a long, long time to get to.