rayleigh scattering: use accurate model #6135

Mc-Pain · 2025-05-21T11:25:37Z

Faster approach lead to some unpleasant render artefacts, use slower but accurate approach.

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

data/shaders/opengl/geosphere_terrain.frag

fluffyfreak · 2025-05-21T12:17:23Z

Nice work. Would you mind giving some explanation of the above tropopause work in here just so that I can understand it.

Mc-Pain · 2025-05-21T12:47:07Z

Would you mind giving some explanation of the above tropopause work in here just so that I can understand it.

Model uses two different formulas for calculating pressure/density
One below tropopause (where temperature decreases with height)
One above tropopause (where temperature is constant)

The one above tropopause is not implemented yet.

impaktor · 2025-05-22T05:20:45Z

Any pictures?

What would "slow" vs "fast" mean here, in performance? Would this put a burden on older machines that can still run pioneer?

Mc-Pain · 2025-05-22T07:45:34Z

Any pictures?

#5617 (comment)

What would "slow" vs "fast" mean here, in performance? Would this put a burden on older machines that can still run pioneer?

slow - O(n^2) complexity: 8 samples for calculating density for light ray
fast - O(n) complexity: 1 sample approximating density for light ray but it looks wrong near terminator

Mc-Pain · 2025-07-24T08:05:44Z

This fixes #6052

src/editor/ModelViewer.cpp

src/modelcompiler.cpp

fluffyfreak · 2025-07-24T12:21:17Z

There seem to be some commits that don't belong in this change history now

Make tropopause at 0.1 bar [1] Temperature starts dropping above tropopause [1] https://www.washington.edu/news/2013/12/09/astronomers-solve-temperature-mystery-of-planetary-atmospheres/

density calculating has been completely nonsense according to units used

Mc-Pain · 2025-07-28T08:09:49Z

There seem to be some commits that don't belong in this change history now

fixed

sturnclaw

Overall, I'm pretty happy with the perceptual quality on display here, though it does come at a potentially staggering performance cost.

In my performance testing, the baseline frametime with #define FAST 1 and 16 samples in the outer loop is ~9ms. I believe this to be the same effect as currently in master:

I'm using that as the baseline for the following measurements with #define FAST 0. For measurements which say "no variable sample count", I've removed the if-block which computes numSamples based on the distance through the atmosphere.

numSamples=16, no variable sample count (+0.1ms):

numSamples=16, max 256 samples; this PR as currently written (+6ms):

numSamples=8, max 64 samples (+1ms):

Finally for an idea of the cost and appearance of the cheapest possible version of the effect, I performed a test with numSamples=8, no variable sample count (-0.5ms):

Given the extremely small perceptual difference between the n=16, max=256, and n=8, max=64 cases, I cannot justify the performance cost of an additional 5ms on a high-end GPU. I'd like to see this PR adopt a setting of numSamples=8, numSamples = min(..., 64) before merge.

Eventually I'd prefer being able to specialize those numbers via a quality setting, for example a low-quality preset could support n=8, max=32, and a high-quality preset could go up to n=16, max=128, but that is somewhat out-of-scope for this PR.

sturnclaw · 2025-09-09T19:10:04Z

data/shaders/opengl/basesphere_uniforms.glsl


 	// Eclipse data
 	Eclipse eclipse;
+	vec2 tropoHeight;			// height for (R, M) in km, pressure is 0.1 atm


tropoHeight does not appear to actually be used anywhere.

sturnclaw · 2025-09-09T19:11:43Z

data/shaders/opengl/geosphere_terrain.frag


+	vec3 I = normalize(eyeposScaled - planetIntersect);
+	vec3 center = I * geosphereRadius;
+	frag_color = vec4(0.f);


This is an early write to frag_color that has no effect.

sturnclaw · 2025-09-09T20:27:08Z

data/shaders/opengl/geosphere_terrain.frag

 	vec4 diff = vec4(0.0);

+	vec2 atmosDist  = raySphereIntersect(geosphereCenter, eyenorm, geosphereAtmosTopRad);
+	vec2 planetDist = raySphereIntersect(geosphereCenter, eyenorm, geosphereInvRadius);


Is there a reason you're using the inverse of the planet's view-space radius here to compute the planetary intersection? In testing, this actually does nothing, as you're attempting to compute an intersection in planet-radii space with an incredibly small sphere (smaller than 1/1000th the visible size of the planet).

sturnclaw · 2025-09-09T20:28:39Z

data/shaders/opengl/geosphere_terrain.frag


+	vec2 atmosDist  = raySphereIntersect(geosphereCenter, eyenorm, geosphereAtmosTopRad);
+	vec2 planetDist = raySphereIntersect(geosphereCenter, eyenorm, geosphereInvRadius);
+	vec3 planetIntersect = geosphereCenter + (eyenorm * planetDist.x);


Under all cases, the value of planetIntersect is equal to the center of the geosphere or well behind the planet in the incredibly tiny area (no more than a fraction of a pixel) where the geosphere's center lies exactly on the camera ray.

sturnclaw · 2025-09-09T20:38:32Z

data/shaders/opengl/geosphere_terrain.frag

+	vec3 I = normalize(eyeposScaled - planetIntersect);
+	vec3 center = I * geosphereRadius;


As a consequence, I=V under all cases (and produces graphical artifacts when it is not). Thus, the entire ray-sphere intersect test can be dropped entirely, and center be redefined as V * geosphereRadius.

sturnclaw · 2025-09-09T21:38:15Z

data/shaders/opengl/rayleigh.glsl

+	float maxSegment = atmosphereHeight / numSamples;
+
+	if (height(tCurrent * dir, center) > 0 && numSamples * maxSegment < (boundaries.y - boundaries.x)) {
+		numSamples = min(int(ceil((boundaries.y - boundaries.x) / maxSegment)), 256); // max 256 segments


256 segments is quite excessive. The perceptual difference is small, and the performance cost is quite stark.

In testing with a 2070 Super (already a very hi-spec card by Pioneer's standards), just adding this branch with a maximum of 16 samples is a baseline cost of 0.2ms/frame, and with a scene set on Earth, a 64 sample maximum represents an additional cost of 2ms/frame.

At 256 samples, the additional cost of 6ms per frame(!) on high-spec hardware is decidedly well out of our performance budget, especially for the incredibly tiny perceptual difference from a 64 sample maximum.

These tests were performed at 1920x1080, paused, with all other details set to low so as not to introduce any other competing factors.

sturnclaw · 2025-09-09T22:08:23Z

src/galaxy/SystemBody.cpp

+	if (altitude > m_tropopause) {
+		return double(GetAverageTemp()) - lapseRate_L * m_tropopause;
+	}


Note that this appears to set a constant atmospheric density above tropopause regardless of altitude. Is this actually physically correct?

If this is intended, this if-block isn't needed, as you can simply use std::min(altitude, m_tropopause) to replace the altitude scalar in the following line.

sturnclaw · 2025-09-09T22:09:40Z

src/galaxy/SystemBody.cpp

+		}
+
+		double tropopause_temperature = surfaceTemperature_T0 - lapseRate_L * m_tropopause;
+		m_atmosRadius = log(0.001 / 0.1) * GAS_CONSTANT_R * tropopause_temperature / (-surfaceGravity_g * GetMolarMass(GetSuperType())) + m_tropopause;


I'd appreciate a comment here explaining the resulting value of m_atmosRadius. At what pressure or altitude is the radius set?

sturnclaw · 2025-09-09T22:24:37Z

data/shaders/opengl/geosphere_terrain.frag

 		//water only for specular
-	    if (vertexColor.b > 0.05 && vertexColor.r < 0.05) {
-			CalcPlanetSpec(specularReflection, uLight[i], L, tnorm, eyenorm, WATER_SHINE);
+		if (vertexColor.b > 0.05 && vertexColor.r < 0.05) {


This test causes noticeable "speckling" on regular Mars terrain (i.e. not water) when looking in the direction of the sun. In testing, the vertexColor.b > 0.05 test needs to be increased to at least 0.15 to eliminate errant pixels from being classified as water.

Mc-Pain · 2025-09-10T08:16:39Z

@sturnclaw you just tested the scattering effects for the most common case possible: direct daylight
Please try again with twilight light on ground or at some altitude as near as possible to light/shadow border

UPD there are much more corner cases like atmosphere on Venus

fluffyfreak reviewed May 21, 2025

View reviewed changes

data/shaders/opengl/geosphere_terrain.frag Outdated Show resolved Hide resolved

fluffyfreak reviewed May 21, 2025

View reviewed changes

data/shaders/opengl/geosphere_terrain.frag Outdated Show resolved Hide resolved

Mc-Pain force-pushed the rayleigh branch from 944028f to 38416eb Compare May 21, 2025 12:53

sturnclaw self-requested a review June 10, 2025 20:18

Mc-Pain force-pushed the rayleigh branch from 38416eb to 9c57b34 Compare July 23, 2025 06:29

fluffyfreak reviewed Jul 24, 2025

View reviewed changes

src/editor/ModelViewer.cpp Show resolved Hide resolved

fluffyfreak reviewed Jul 24, 2025

View reviewed changes

src/modelcompiler.cpp Show resolved Hide resolved

Mc-Pain added 8 commits July 28, 2025 11:08

better atmosphere model

0917cc4

Make tropopause at 0.1 bar [1] Temperature starts dropping above tropopause [1] https://www.washington.edu/news/2013/12/09/astronomers-solve-temperature-mystery-of-planetary-atmospheres/

use actual atmosRadius calculated earlier using tropopause model

7fc014c

rayleigh: use accurate approach, keep fast

d4a8d82

improve water reflection based on Rayleigh distribution

1e216b2

rayleigh: increase number of samples if segment gets too big

a0234ab

rayleigh: multiply by inverse AU

4dacd3d

new density formula

ec99e79

density calculating has been completely nonsense according to units used

rayleigh: scale density from tropopause height

e673af1

Mc-Pain force-pushed the rayleigh branch from 00bfc29 to e673af1 Compare July 28, 2025 08:09

sturnclaw requested changes Sep 9, 2025

View reviewed changes

sturnclaw reviewed Sep 9, 2025

View reviewed changes

		vec3 I = normalize(eyeposScaled - planetIntersect);
		vec3 center = I * geosphereRadius;

Uh oh!

Uh oh!

rayleigh scattering: use accurate model #6135

Are you sure you want to change the base?

rayleigh scattering: use accurate model #6135

Uh oh!

Conversation

Mc-Pain commented May 21, 2025

Uh oh!

Uh oh!

Uh oh!

fluffyfreak commented May 21, 2025

Uh oh!

Mc-Pain commented May 21, 2025

Uh oh!

impaktor commented May 22, 2025

Uh oh!

Mc-Pain commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mc-Pain commented Jul 24, 2025

Uh oh!

Uh oh!

Uh oh!

fluffyfreak commented Jul 24, 2025

Uh oh!

Mc-Pain commented Jul 28, 2025

Uh oh!

sturnclaw left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mc-Pain commented Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Mc-Pain commented May 22, 2025 •

edited

Loading

sturnclaw left a comment •

edited

Loading

Mc-Pain commented Sep 10, 2025 •

edited

Loading