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.