[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 a bit "hacky"! One problem are extended objects: Zodiacal light, Milky Way, atmosphere, DSO images need to be switched off first. This is handled automatically and easy to solve.

The worst problem is that the scene becomes too bright too quickly when any extended objects would be plotted. A 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; Windows 11 25H2
• Graphics Card: Nvidia Geforce 960M; Geforce RTX 3070Ti

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

[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]

Actually I think this can be squashed into one new minor feature.
Landscapes: Oops... will have a look now.
Screenshots: SUG 6.5.2, last sentence. If you find an easy way to do that, fine.

[gzotti]

Somehow I don't find the decisive difference in the shader code between decor and bottom parts. What works for the sides does not work at the bottom panel! I can only make it work in lowGL mode which also looks OK for me.

[gzotti]

@10110111 Are you OK with switching to lowGL, or can you identify the problem?
(With the lowGL solution, I cold revert the shading var tweaks.)

[10110111]

So I have fixed the ground issue now.

There are some glitches when panning around during daytime with star trails enabled: the atmosphere flickers, getting sometimes overexposed, other times completely absent. On disabling star trails the atmosphere doesn't immediately reappear for some reason. (I'm using ShowMySky with atmosphere_resolution_reduction enabled if this matters).

Generally, the current implementation is hard to follow. Not least because of the confusing name of the flag, but also because it's hard to even tell which objects are supposed to be smeared over the screen. (Is it only stars, planets, and satellites?)

Maybe a better way would be to do as follows:

• Prepare a framebuffer for accumulation of the items we want to see smeared.
• Make (and save) a list of pointers to the modules that should appear in this framebuffer (extracted from the list with the right call order).
• Make (and save) two lists of the remaining modules (first for the ones before the smeared modules, second for those after).
• When rendering:
  • draw the first batch of modules (those before the smeared ones)
  • switch FBO to our accumulation buffer
  • draw the modules we want to smear
  • switch back to the target FBO
  • blit the accumulation buffer
  • draw the rest of modules
• On panning clear the accumulation buffer.
• On screen resize also resize and clear the accumulation buffer.

Of course, the accumulation buffer doesn't have to be created and managed until the user enabled star trails.

This way only the handful of smeared modules will have to deal with the star-trail mode (disabling their labels), the rest will work just as usual (except maybe for the atmosphere that we may want to suppress in this mode).

As a bonus, we'll get back screenshots (except those with a custom size), and avoid the GUI artifacts (currently the bottom panel with the time rate button leaves trails too).

[gzotti]

So I have fixed the ground issue now.

Many thanks. I don't know where blindness struck me.

There are some glitches when panning around during daytime with star trails enabled: the atmosphere flickers, getting sometimes overexposed, other times completely absent. On disabling star trails the atmosphere doesn't immediately reappear for some reason. (I'm using ShowMySky with atmosphere_resolution_reduction enabled if this matters).

Yes, admittedly it's not perfect, just good enough for some effects. I do not understand why the atmosphere sometimes accumulates 2-3 frames (running into white-out) before being silenced, and why it then sometimes remains off.

Generally, the current implementation is hard to follow. Not least because of the confusing name of the flag, but also because it's hard to even tell which objects are supposed to be smeared over the screen. (Is it only stars, planets, and satellites?)

The name just describes what happens technically, not why. I hope the documentation string is complete enough for understanding.

Everything that causes large-area brightening must be disabled or the screen turns white within seconds. In 2021-23 my idea was to dim down the accumulated image to limit brightness, which would have also meant limited trail length. Guillaume's filter effect went into this direction but also blurred the view. In the end only stars (and other star-like extras: Novae, Supernovae), planets, satellites remained. But the other modules should be visible at the onset of the drawing, and the landscape must still cover the ground (if enabled).

Maybe a better way would be to do as follows:
[...]

I can roughly follow this in theory, but it vastly exceeds my OpenGL proficiency, sorry. I wanted to have this feature finally available showing something not the least for satellite annoyance awareness.

This way only the handful of smeared modules will have to deal with the star-trail mode (disabling their labels), the rest will work just as usual (except maybe for the atmosphere that we may want to suppress in this mode).

As said, the other modules including atmosphere (awesome twilight composites!) should draw one initial snapshot. E.g., constellations can show stick figures from which star lines grow. Of course, with your mode it would mix "current" view and recorded trails, that's another mode that promises to look interesting. Can we think of this as future version 2 of this feature?

As a bonus, we'll get back screenshots (except those with a custom size), and avoid the GUI artifacts (currently the bottom panel with the time rate button leaves trails too).

I keep the menus visible or switch them off entirely (Ctrl-T). Pressing Ctrl resets the scene.

[10110111]

I don't quite get the logic of sky clearing. Why is there this magic number 3? Why not any other? Besides, flagClearSkyOnce is not actually a flag, since it ranges from 0 to 3.

And, I think flagClearSky should be renamed to something like isAccumulatingStarTrails (with inverse condition), because it's not about sky clearing generally, but rather a hack exclusively for star trails (given that only a few modules actually draw something when this flag is reset).

[gzotti]

The naming grew historically. I thought a second flag would do for resetting, but it showed I need a 3-2-1-0 countdown to handle the initial 1-shot drawing completely. So, the counter could be renamed, ok. How does frameClearingResetCounter // for Star Trail Effect sound?
The flagClearSky, again, was the intention in 2021 to signal that at frame start the frame should be reset, as normal case. When disabled, frame is not reset, unless (flag)ClearSkyOnce is not 0, in which case there is some localized logic to handle the reset sequence. If you think this should be renamed in some inverted sense and handled with inverted logic to be better readable, OK for me.

[10110111]

But still, can you explain the idea behind this 3-2-1-0 sequence? Why can't this be done in only two stages (everything once, then accumulation of the few items)?

[gzotti]

Reducing (Starting) the counter back to 2 causes overly frequent white-out with the daylight sky when pressing Ctrl to reset the trails.

[alex-w]

@gzotti @10110111 any news?

[gzotti]

Sorry, conference week. It is as described in the User Guide a hackish approach, but it works usually. It will probably only be found by users that stumble over it while reading the advanced options in the SUG. Separating that into several buffers may be the technically cleaner way, but is beyond my knowledge. I would like this showpiece effect "in", obviously accepting improvements if e.g. @10110111 finds time. I could also add yet another manually modified config option to hide the feature for beginners.

[10110111]

If I don't find time to add any improvements here by the end of the next week, I guess this can then go in as is. Otherwise it'll have too small time to be tested before release.

[gzotti]

The occasional atmo white-out or absence may be caused by the overall brightness estimator getting confused. Must have another look. Weekend, hopefully...

[10110111]

This crashes unconditionally in debug mode with assertion failure "singleton" in StelApp.hpp:132:

#8  0x00007ffff4ec1366 in QMessageLogger::fatal
    (this=<optimised out>, msg=0x7ffff522aad8 "ASSERT: \"%s\" in file %s, line %d")
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/corelib/global/qlogging.cpp:883
#9  0x00007ffff4ebf450 in qt_assert
    (assertion=<optimised out>, file=<optimised out>, line=<optimised out>)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/corelib/global/qassert.cpp:105
#10 0x0000555555fca49f in StelApp::getInstance ()
    at /home/ruslan/src/stellarium/src/core/StelApp.hpp:132
#11 0x000055555644053f in StelRootItem::setSize (this=0x555558afbdd0, size=...)
    at /home/ruslan/src/stellarium/src/StelMainView.cpp:381
#12 0x000055555642fa99 in StelMainView::resizeEvent (this=0x7fffffffd740, event=0x7fffffffcee0)
    at /home/ruslan/src/stellarium/src/StelMainView.cpp:725
#13 0x00007ffff6df750e in QWidget::event (this=0x7fffffffd740, event=0x7fffffffcee0)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/widgets/kernel/qwidget.cpp:9153
#14 0x00007ffff6e5d866 in QFrame::event (this=0x7fffffffd740, e=0x7fffffffcee0)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/widgets/widgets/qframe.cpp:521
#15 0x00007ffff4f878da in QCoreApplicationPrivate::sendThroughObjectEventFilters
    (receiver=receiver@entry=0x555558a518a0, event=event@entry=0x7fffffffcee0)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/corelib/kernel/qcoreapplication.cpp:1243
#16 0x00007ffff6d9d48f in QApplicationPrivate::notify_helper
    (this=<optimised out>, receiver=0x555558a518a0, e=0x7fffffffcee0)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/widgets/kernel/qapplication.cpp:3294
#17 0x00007ffff4f8add8 in QCoreApplication::notifyInternal2
    (receiver=0x555558a518a0, event=0x7fffffffcee0)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/corelib/kernel/qcoreapplication.cpp:1106
#18 0x00007ffff4f8ae1d in QCoreApplication::sendEvent
    (receiver=<optimised out>, event=<optimised out>)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/corelib/kernel/qcoreapplication.cpp:1546
#19 0x00007ffff6df0ebe in QWidgetPrivate::sendPendingMoveAndResizeEvents
    (this=this@entry=0x5555589a6360, recursive=recursive@entry=false, disableUpdates=<optimised out>, disableUpdates@entry=false)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/widgets/kernel/qwidget.cpp:7982
#20 0x00007ffff6df4ab7 in QWidgetPrivate::show_helper (this=this@entry=0x5555589a6360)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/widgets/kernel/qwidget.cpp:8033
#21 0x00007ffff6df55c3 in QWidgetPrivate::setVisible (this=0x5555589a6360, visible=<optimised out>)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/widgets/kernel/qwidget.cpp:8394
#22 0x00007ffff6df4f9e in QWidgetPrivate::showChildren
    (this=<optimised out>, spontaneous=<optimised out>)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/widgets/kernel/qwidget.cpp:8482
#23 0x00007ffff6df4ad3 in QWidgetPrivate::show_helper (this=this@entry=0x555558d17910)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/widgets/kernel/qwidget.cpp:8039
#24 0x00007ffff6df55c3 in QWidgetPrivate::setVisible (this=0x555558d17910, visible=<optimised out>)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/widgets/kernel/qwidget.cpp:8394
#25 0x00007ffff6de337b in QWidget::showFullScreen (this=0x7fffffffd740)
    at /usr/src/qt6-base-6.9.2+dfsg-1ubuntu1/src/widgets/kernel/qwidget.cpp:3056
#26 0x0000555556438136 in StelMainView::setFullScreen (this=0x7fffffffd740, b=true)
    at /home/ruslan/src/stellarium/src/StelMainView.cpp:1500
#27 0x0000555555fc65f0 in main (argc=1, argv=0x7fffffffdaf8)
    at /home/ruslan/src/stellarium/src/main.cpp:477

[10110111]

This crashes unconditionally in debug mode

Fixed by 14c74c4.

[gzotti]

Thanks!

[github-actions]

Hello @gzotti!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions]

Hello @gzotti!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest