New rendering for starfield

[375gnu]

No description provided.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
9 Code Smells

0.0% Coverage
0.0% Duplication

[sonarqubecloud]

Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

9 New issues
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[sonarqubecloud]

Quality Gate passed

Issues
34 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Askaniy]

Let's count current bugs I created and left 🥲
(For rendering box testing, I turned on the red filler at line 47 in star_frag.glsl)

There are two stages of rendering a star, depending on its individual visible brightness: "9 px" mode (3x3 box size) and "glow" mode (variable box size). For simplicity, the separating value is chosen to be 1 Vega brightness at exposure 1. The separation is in star_vert.glsl at line 46.

You can notice that in the glow mode, the glow doesn't completely fill the box. Actually fills, but only in internal Float values. sRGB gamma correction is assumed in the glow design, which will “pull” it to the box edges.

Bug 1

Star field have never been seen using both modes at once, depending on the brightness of a particular star. If you don't change the code (if (all(lessThan(scaled_color, vec3(1.0))))), the glow mode is used. If you change to if (true), the 9 px mode is used.

That's how 4 px mode looked like. Stars feel square, that's why I moved it to 9 px instead.

Bug 2

The 9 px mode was broken since my last testing in the summer 2024. When rotating the camera, the 1 pixel stars rarely appear and then disappear again:

Bug 3

The wrong brightness values are obviously being supplied to the input. The glow mode worked correctly before the exposure transition was made:

Bug 4

After ruthless code reduction, barycenters began to emit. I'm guessing it was an old optimization whose limits were accidentally removed. I think it's best to find and remove the barycenter glow all the way through.

Bug 5

Limb darkening was added, but the star surfaces have stopped rendering. It could be a typo or caused by deleting something extra.

Bug 6

There is a small “bug” with exposure setting in the interface: I failed to make integer output when updating a variable, i.e. now Exposure: 16.00 is printed instead of Exposure: 16. I rolled back my experiments

Notes

Based on the Discord discussions, it would be both more realistic and easier to program the overall process of rendering both stars, planets, and spacecraft if they are in point mode. Without special brightness enhancement of planets, for example. For the sake of simplifying visual search, you can set different thresholds for displaying names. Now there are no star styles, which may allow simplifying the logic globally. I also removed the glow and atmosphere of the stars, while adding changes from the limb-darkening branch to optimize the logic of everything planned at once. To keep the Sun looking bright, I suggest increasing the maximum size of the glow to the size of the screen. At typical exposures, only the Sun will be bright, and it will switch to a starry background with no jumps when removed.

Also, maximum glow box size is discussed to be min(min(screen_hight, screen_width), max_point_size), depending on the max point size that openGL supports.

[Askaniy]

Chara updated astronomical constants (#2371) and made Sun white point the default one (#2372), to delineate the branch

[sonarqubecloud]

Quality Gate passed

Issues
27 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
27 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[AstroChara]

Since it is somehow attached to this PR, I would like to propose that we cancel the complete deletion of the "Classic" star rendering mode; instead, we recycle its code infrastructure to create a "true colour" mode, where each star type's colour is based on colour from TrueColorTools — so light yellow late M-dwarfs and pink/magenta T-dwarfs, for example.

[AstroChara]

On a more general note, we have seen how combining multiple completely different tasks into one creates this mess which is very difficult to understand and by now taking over three years to complete.

I think we should look into taking apart this PR, putting each indivisible component of this PR into their own PR, where they can be debugged and reviewed and incorporated independently. Given the scale of this PR, it would be a lot of effort, but it should make things far easier and far more mobile in the long run.

We can also remove elements already in the program like updating constants or setting default star colour mode.

[375gnu]

@Askaniy do you still have your original python files? it lost them, i'd like to play with them with different exposures.

[Askaniy]

@375gnu do you mean https://github.com/Askaniy/CelestiaStarRenderer or some older version of it?

[375gnu]

Yes, this one. Thanks!

[ObmijSelaw]

greetings, I was recommended on Discord to come here to let you all know about my efforts in getting sRGB gamma correction working in tandem with this new star rendering method

I have been working on it as a "fork", but I am keeping it as closely updated to master upstream so it can be (hopefully) easily integrated when all bugs are squashed and the moment is right

link to my "fork" here on github

thus far, I have integrated code up to commit 2ca7268 from askaniys-stars branch

Now, to recap, @Askaniy said on Discord that this star rendering system should be able to "discriminate" between the 9px rendering mode (i understand this is for low-brightness stars) and glow mode (for brighter stars), however, this is not currently working.

i confirm in my builds that this is indeed broken and seemingly only glow mode works, if the stars get dimmed below a certain brightness threshold, they disappear altogether instead of becoming dim. Only very bright stars are rendered

so far i have not touched the code beyond said commit, so i have not integrated the commits replacing faintest-magnitude with exposure, nor deleting legacy star colors/styles, etc.

I am thinking the priority should be figuring out what's preventing this "dual mode" code from working, what do you say?

[Askaniy]

I just finished complete redesign of the star rendering method. It's both easier to implement and closer to the original PSF. And has been tested a lot.

Last time, the method required separating the modes within the shader. And that didn't work out. Now there's no need to deal with that: the new method could be split into two separate shaders, one for the point and one for eye PSF. See the general logic in RenderEngine.draw_source()

[AstroChara]

I just finished complete redesign of the star rendering method. It's both easier to implement and closer to the original PSF. And has been tested a lot.

Last time, the method required separating the modes within the shader. And that didn't work out. Now there's no need to deal with that: the new method could be split into two separate shaders, one for the point and one for eye PSF. See the general logic in RenderEngine.draw_source()

I wonder if we should just make a new PR, and we can simply reuse the important bits in this PR (like exposure implementation) and discard the outdated stuff like limb darkening or removing legacy colours (whose infrastructure can instead be reused).

[Askaniy]

Making a new PR is what I think could work.

we can simply reuse the important bits in this PR (like exposure implementation)

But exposure I implemented is exactly the thing that is broken in this PR.

I propose adding the stars first, and exposure system after. We would need to convert FaintestMag to linear irradiance (maybe it's better to use SI units), and then convert the irradiance to the radiance scale that the shader uses (where radiance=1 is the scale of transition between point and eye PSF modes).

[AstroChara]

I propose adding the stars first, and exposure system after. We would need to convert FaintestMag to linear irradiance (maybe it's better to use SI units), and then convert the irradiance to the radiance scale that the shader uses (where radiance=1 is the scale of transition between point and eye PSF modes).

I believe that works. If we add just the PSFs, we will need the star rendering itself, the removal of the current star styles (can we just comment out the infrastructure to be reused later?), and add the conversion of magnitudes to irradiance, as you said.