Conversation
|
Kudos, SonarCloud Quality Gate passed! |
375gnu
force-pushed
the
askaniys-stars
branch
from
3ef517f to
11ed2a0
Compare
|
Co-authored-by: ajtribick <ajtribick@googlemail.com>
|
|
|
|
|
Let's count current bugs I created and left 🥲 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 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 1Star 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 ( Bug 2The 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 3The wrong brightness values are obviously being supplied to the input. The glow mode worked correctly before the exposure transition was made: Bug 4After 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 5Limb darkening was added, but the star surfaces have stopped rendering. It could be a typo or caused by deleting something extra. Bug 6There is a small “bug” with exposure setting in the interface: I failed to make integer output when updating a variable, i.e. now NotesBased 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 |
Split from CelestiaProject#1952, as suggested by Askaniy themself, allowing this component of that PR to be updated even if the PSF itself remains work in progress.
Split from #1952, as suggested by Askaniy themself, allowing this component of that PR to be updated even if the PSF itself remains work in progress.
|
|
|
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. |
|
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. |
|
@Askaniy do you still have your original python files? it lost them, i'd like to play with them with different exposures. |
|
@375gnu do you mean https://github.com/Askaniy/CelestiaStarRenderer or some older version of it? |
|
Yes, this one. Thanks! |
|
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? |
5 participants
No description provided.