star trails

[gzotti]

Description

This little branch adds an interesting "wow" effect by not blanking frames. You can configure a keyboard shortcut to toggle this, and then render star trails.

This is totally unfinished! One problem are extended objects: Zodiacal light, Milky Way, DSO images need to be switched off first. This may be configured automatically and easy to solve.

The other problem is that the scene becomes too bright too quickly. The solution would be to not just "forget" blanking, but add a slight dimming of the scene. This should then result in an afterglow effect where star trails don't get infinitely long. Maybe the dimming can be made configurable.

Due to the nature of this method, screenshots have to be made with operating system tools, not Stellarium's own screenshot renderer.

OpenGL/Qt experts please continue on this. Change StelCore::preDraw() and implement the methods in the StelViewportFaderEffect class, or maybe directly in StelCore::preDraw().

Screenshots (if appropriate):

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update

How Has This Been Tested?

Test Configuration:

• Operating system: Windows 10 21H1
• Graphics Card: Nvidia Geforce 960M

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[todo]

dim whole framebuffer to 90%, else we are overexposed much too fast.

stellarium/src/core/StelCore.cpp

Lines 499 to 504 in 4f0cab6

	// TODO: dim whole framebuffer to 90%, else we are overexposed much too fast.
	gl->glClear(GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
	}
	skyDrawer->preDraw();
	}

---

This comment was generated by todo based on a TODO comment in 4f0cab6 in #1888. cc @Stellarium.

[todo]

I am still unsure about how to use this. When I want to have a scene fading to black (effect of a light echo or showing star trails),

stellarium/src/core/StelViewportEffect.cpp

Lines 352 to 357 in 4f0cab6

	// TODO: I am still unsure about how to use this. When I want to have a scene fading to black (effect of a light echo or showing star trails),
	// will the main buffer be changed, or can I only apply an effect to the finally displayed image?
	// https://stackoverflow.com/questions/6810591/how-to-make-fading-to-black-effect-with-opengl
	}

---

This comment was generated by todo based on a TODO comment in 4f0cab6 in #1888. cc @Stellarium.

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files

[guillaumechereau]

I tried to complete the viewport effect code, using a blending function with alpha = 0.08:
GL_CONSTANT_ALPHA, GL_ONE_MINUS_CONSTANT_ALPHA

I can get this result:

While the trails are not very clear, this has the nice effect of not affecting the non moving parts of the screen, like the landscape.

Should I commit in this branch?

[gzotti]

Yes, this looks very good for a start, thank you. I may be then able to play around with different alphas and maybe still different blending functions, and resetting the screen when view direction was changed etc. The non-affection of the landscape is very welcome!

[guillaumechereau]

OK I'll commit what I have, feel free to modify it. Unfortunately the only way to keep the landscape stable is to use a blending function of the form: color = new * t + prev * (1 - t), and instead of the accumulating effect, we get something that looks more like a blur. Not sure how to improve that.

The other problem here is that we apply the effect to everything, including the labels and UI, so it makes the interface clumsy.

[gzotti]

Thank you, it is certainly a progress. But the blur is strange, indeed.

I think we can auto-hide the GUI while the effect is active, or do similar things. It's mostly a show-off effect.

I wonder how alterBuffer would ever be applied in a ViewportEffect?

[luzpaz]

Bump

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[gzotti]

Some modules are auto-inhibited now: gridlines, labels, planet and DSO hints, planet halos, Milky Way, Zodiacal light.

Now it depends on what users expect.
The best use is to switch off landscape and press Ctrl-Alt-C. This works for a few spectacular effects in a demo, but can run into really ugly white-outs if not applied with caution.

I would like to see landscape being replotted and NOT run into white-out, however I am unable to see an easy solution.

Also, changing view direction or fov changes should re-initialize (clear) the view. This would need a few new signals. Is the overhead worth it?

I cannot get @guillaumechereau 's solution to show again. :-(

[10110111]

Why not just draw all the cosmic items into a separate FBO for accumulation, and blit on each frame into the main render target after rendering into this FBO?

[gzotti]

Sounds like a plan :-)
I think by now you have the better overview about which buffers exist and how they correlate with each other. (This architecture should be described somewhere!!!) It may also be related to your longer-term ideas around using physical radiance units and post-process effect filtering (blur up bright stars/planets) which should also be applied to the sky only. (And not on labels, hint icons, ... or landscapes.) I will be glad if you bring in your skills here.

The net view effect I envision in this mode should be "interactive foreground" (i.e. landscape should redraw well), stars should not run over the landscape (I tried several blending options, all but current looked bad), and on change of view direction, this "sky buffer" should reset to black (or background color). Dithering should be applied only to the final view (Currently it of course accumulates and looks bad as well). An extension could be that the buffer is dimmed instead of blanked, so that the star trails fade away after e.g. 10...60 seconds.

If possible, gridlines or DSO markers, or even the MilkyWay/ZL could be made visible again without streaking. (I.e., not put into that "celestial" FBO. (But another FBO for MW/ZL/DSO textures/DSS/HiPS is yet another indirection, may be overkill, so IMHO it's OK to just switch them off).

This all is meant to be for stronger systems. The "low graphics mode" running on memory limited systems should not be further encumbered with yet another FBO.

[10110111]

This architecture should be described somewhere!!!

Well, it's still gonna change when I split the rendering between layers to make labels etc. separate from physical objects and tone mapping.

Dithering should be applied only to the final view

This must always be true, since it's a conversion from full color depth to the monitor space.

If possible, gridlines or DSO markers, or even the MilkyWay/ZL could be made visible again without streaking. (I.e., not put into that "celestial" FBO. (But another FBO for MW/ZL/DSO textures/DSS/HiPS is yet another indirection, may be overkill, so IMHO it's OK to just switch them off).

What would a star streak represent if the Milky Way remains at one position? Sounds unphysical. If you want to simulate a long-exposure photo, all celestial objects should move and be smeared. Otherwise you could just as well draw the stars as lines (similar to orbits).

The "low graphics mode" running on memory limited systems should not be further encumbered with yet another FBO.

The low graphics mode shouldn't receive any new graphical features IMO. Only fix the existing bugs (except the ones requiring a serious rework).

[gzotti]

This architecture should be described somewhere!!!

Well, it's still gonna change when I split the rendering between layers to make labels etc. separate from physical objects and tone mapping.

Yes, but just as code evolves, docs can evolve and later versions can supersede current docs. If somebody wants to join right now, it's super hard without some information on what goes where. (It has always been like that, though...)

Dithering should be applied only to the final view
This must always be true, since it's a conversion from full color depth to the monitor space.

Sure. Just in the current state, it accumulates, so I must switch it off.

If possible, gridlines or DSO markers, or even the MilkyWay/ZL could be made visible again without streaking. (I.e., not put into that "celestial" FBO. (But another FBO for MW/ZL/DSO textures/DSS/HiPS is yet another indirection, may be overkill, so IMHO it's OK to just switch them off).

What would a star streak represent if the Milky Way remains at one position? Sounds unphysical. If you want to simulate a long-exposure photo, all celestial objects should move and be smeared. Otherwise you could just as well draw the stars as lines (similar to orbits).

The MW and other extended features could either continue rotating with the stars as they are newly plotted, or stop at the place when this mode was activated, or be smeared. In the last case, it must dimmed down however, or the sky will be white within seconds. Therefore I currently switch it completely off.

The "low graphics mode" running on memory limited systems should not be further encumbered with yet another FBO.

The low graphics mode shouldn't receive any new graphical features IMO. Only fix the existing bugs (except the ones requiring a serious rework).

OK for me.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[dromeuf]

Hi, I'm looking to make an illustration with a long exposure effect of circumpolar star trails. Does this feature work in Stellarium 24.2 ? In the documentation I can only find the trail planets. Kind regards,

[gzotti]

Would you mind reading the first description above? This is an experiment. No, it is not available in the public release. No, it is not finished, else it would be. You are free to play with the source code to make it work.

[dromeuf]

Georg, I did read the thread you created in 2021. I didn't know whether you had completed this experiment. Thank you for all your great work on the Stellarium project.

[dromeuf]

Further to our discussion, here is the solution that I found last night to illustrate the circumpolar rotation at the northern horizon of the site studied and the movement in the sky of the star Vega in 4000 BC which rubs the horizon of the place of observation :

• stop animation
• set the date
• capture screen with capture tools
• change the date (min)
• capture screen.... n times...
• Use StarStaX https://markus-enzweiler.de/software/starstax/ for stacking capture screen

I read in the latest Stellarium 24.3 user guide that the representation of the proper motion is good to within 100,000 years but that the ‘Carte du Ciel’ software will be more accurate than Stellarium. In 2021 Georg you indicated in #1546 + or - 40,000 years. By comparing with ‘Carte du Ciel’ on the star Vega, I have the impression that the proper motions of Stellarium are those of the Hipparcos 2007 catalogue. In 6,000 years, Vega's proper motion is 35'. When I calculate the angular distance between the coordinates for the date between Stellarium and ‘Carte du ciel’, I find a difference of about 4'. I don't have the explanation because I haven't had time to examine the details of the calculations made by the 2 software packages: precession model, mean coordinates, etc.

[gzotti]

I did not intend to say Stellarium is accurate within ±40.000 years, just to be more conservative about what to expect. The settable date range is ±100.000 just to have round numbers. The available models concentrate on present times. A few like precession declare date range (exceeding the 100.000), no information is given for nutation, so we invented the limit given in the Guide. VSOP87 is recommended for -4000...+8000 but delivers "something" also at the edges of the date range; the DE[34]31 solutions provide data for -13.000...+17.000 only. It should be clear that linear proper motion is not enough for accurate positions over tens of thousands of years, still the idea of motion is often more important than the actual figure change. Just don't trust it to the last decimal place! (Don't ask us to reduce the number of displayed digits in prehistory!) And in a previous (rejected) PR a suboptimal way to fix the current problem can still be seen.

Currently a new star catalog is in preparation (#3982). therefore I will not compare anything that involves the current, known-to-be-somewhat-flawed solution.

[dromeuf]

In my case and for the purpose mentioned, the precision is sufficient for visual illustration. Thanks again and congratulations on all the work done by the Stellarium team. It's also good news if your synergy focuses on updating star catalogs. I've read #3982