Rayleigh v2

[Mc-Pain]

Experimental approach to improve rayleigh shaders:

Might be slow, but still accurate pre-calculated density LUT's and synced models within physics and graphics engines.

[fluffyfreak]

What's the best way to test this? What am I looking for?
You mentioned that it might be slow but do you mean slower than the existing version?

[Mc-Pain]

What's the best way to test this? What am I looking for?

Try to look at Venus or Titan, it should not have any sharp edges

You mentioned that it might be slow but do you mean slower than the existing version?

A little bit, not that catastrophic drop from 50 FPS to 3 FPS using uniform arrays and doing mix() between its elements

With my GPU, it was like 55 -> 51 FPS drop

[impaktor]

If this is slower, this would be an optional setting.

What am I looking for?

In the original PR @Mc-Pain mentions:

This also makes water reflect rays from skylight, bringing realistic Earth colors.

[Mc-Pain]

It's still an optional setting along with legacy atmosphere

[sturnclaw]

Will make some time to benchmark this soon, and I'd like to investigate the possibility of using a similar precomputation method for other objects in the scene.

[Mc-Pain]

Some Work-In-Progress screenshots:

[bszlrd]

It crashes on my end. The new game starts, and crashes after a second.
output.txt
opengl.txt

[Mc-Pain]

@sturnclaw @impaktor there's a problem

I had implemented a new atmosphere model (with tropopause) to actually resolve #6052

Mars and Earth looks fine with this:

Venus does not:

To resolve this, I've increased samples count to 64 but had a significant performance drop:

[fluffyfreak]

Maybe you need different models per-atomsphere type? Or to base the number of samples on some atmospheric property?

Why does it work well for one planet but not another? Height of atmosphere? Density? etc and base it on that instead of fixed sampling number.

Then if you want to have a sampling "quality" could be set based on a multiplier of that number, eg (0.5, 0.75, 1.0, 1.25, 1.5)

[Mc-Pain]

Maybe you need different models per-atomsphere type? Or to base the number of samples on some atmospheric property?

Why does it work well for one planet but not another? Height of atmosphere? Density? etc and base it on that instead of fixed sampling number.

Then if you want to have a sampling "quality" could be set based on a multiplier of that number, eg (0.5, 0.75, 1.0, 1.25, 1.5)

Checking if I can return 0.001 atm as atmosphere threshold (I decreased it to 1e-15)

UPD
Nope. I can't, edge is looking sharp:

[Mc-Pain]

Then if you want to have a sampling "quality" could be set based on a multiplier of that number, eg (0.5, 0.75, 1.0, 1.25, 1.5)

I'd suggest {1.0, 1.5, 2.0, 3.0, 4.0}
16 already looks good enough not causing any performance problems on most planets
It looks bad when atmosphere is either thick or dense (maybe there's a correlation between both)

[sam52796]

Not sure if this is the right PR to bring this up, but the lighting in Pioneer doesn't seem bright enough.

For example, see below for a comparison of how I expect the sky on Earth at midday with bright sunlight to look, vs how it looks in Pioneer currently.

The ground is also not as brightly lit as I would expect.

Can this be addressed as part of the Rayleigh improvements?

[sam52796]

Apparently I was running "legacy" sky code instead of "experimental". But even with the "experimental" one the sky itself still seems a bit dim. The sphere on the left in my previous image has a "bright sky" quality to it, which the below image doesn't manage. Also the terrain looks brightly illuminated at the horizon near the sun, and darker near the camera, which doesn't look quite right either.

[sturnclaw]

I'm generally happy with the look of this PR. It makes a huge difference to have the terrain match the sky, especially at highly-grazing angles, and the water on Mars appears incredibly beautiful.

However.

There are some bugs with the implementation that render it unsuitable for merge at the moment. The biggest one is the fact that the terrain appears to only be doing a ray-test against the geosphere radius and not taking the current sample depth into account, as at incident angles the terrain becomes shaded as though it were the sky.

This manifests as a visible "line" near the horizon where the terrain receives a completely different color, and at grazing angles even makes the terrain appear invisible.

(This terrain is not bugged / invisible, it's just being shaded as though it were sky.)

Finally, and this is an incredibly minor thing, when flying the horizon line appears to "warp" / "undulate", faintly visible in this screenshot here (note the jagged edge between terrain and sky rather than a smooth line). I'm not sure exactly what's causing this, but it's quite attention-grabbing.

---

On the whole, performance is quite good. At 1440p, a near-fullscreen Terrain+Sky pass takes approximately 2ms of GPU time on my 2070 Super; this is way better than I expected and much faster than previous iterations of the feature. In the future, I can look into an early-Z pass to reduce overdraw, now that terrain lighting is an appreciable amount of time.

I don't think the above issues will all be fixed in time for the upcoming bugfix release, but once the points raised here and in the review comments are addressed I consider this PR almost ready to merge; I haven't gone over the shader code with a fine-tooth-comb yet but I'm liking what I see.

[Mc-Pain]

There's more hard work to be done:

1. As @sturnclaw mentioned, density computations should be for vertex position (which is a known issue) instead of virtual geosphere instersection - for high ground (do not underestimate my power!) terrain looks as being almost transparent, as if looking from very high altitude (which is true) to terrain near zero-alt (which is false)

2. With bringing density calculations to a GPU-side one would split physical and graphical models of atmosphere, which I have gotten rid of. Shader code is now to be untouched if someone decides to pretend if atmosphere is having constant pressure/density for all volume. Commit 08b384f demostrating it clearly.

3. For more complex approach as rendering stars/bodies/rings/objects correctly, the rendering pipe should clearly split apart material preparation and rendering steps.
   Current implementation does not - lazy approach is in effect.

There should be a sequence point (in C++ means: https://en.cppreference.com/cpp/language/eval_order) between materials and rendering: not a single object is to be rendered until all materials are prepared and fully evaluated.
Without this, we'll have to approximate eclipses or shadows for every object using different shaders (as we do now for rings, other planets, and, recently, terrain (#6372)

UPD
I'll also make some further research to make Rayleigh actually elastic: photons scattered more than once should not be discarded, leading to (almost) pitch-black Venus surface, compared to this:

[sturnclaw]

Following our discussion on IRC, I've dug into and fixed a few mathematical anomalies with this PR in the name of getting it out the door.

I'm leaving a series of before/after comparisons to illustrate the graphical effects of said anomalies - they primarily stem from the fact that the clamped cosine lobe lighting term was being applied a few times too many, and that the effects of terrain height were not being fully propagated into all of the lighting calculations.

While there are a few things that could be further improved (the appearance of in-scattering at the planet/atmosphere edge when viewed from space for one), this is Good Enough to release on Monday.

I'd like to extend my commendation to @Mc-Pain for doing all of the hard work on this PR and keeping with it through its extended development cycle. You can manually squash together your development commits or I can do a squash merge at your discretion.

---

Before my changes:

After:

---

Before:

After:

---

Before:

After:

As you can see, there's definitely some visual fidelity lost in this last example (Moscow on Earth) compared to an "ideal" photorealistic Earth. However, compared to the legacy version, I think there's no comparison...

---

As an addendum, @sam52796 will be happy to note that he got his wish of a brighter blue Earth sky 😆.