Today I was digging inside old files on an external drive and came upon an old experimental 2008 build by Da Woon using HDR to simulate the fading of dim light source (far stars) when a strong light source is present on screen. Fridger, do you plan to integrate such technique inside .Sci?

So far there are no concrete plans. I know Da Woon's modified code pretty well. He has injected his mods in many places and hence it must have been a lot of work. For some reason not known to me, very few people seem to have experimented with his code (except DW himself). Neither have I...

Despite my rather close collaboration with DW on my texture tools, he never recommended his work to me, which is a bit strange.

DW also showed rarely or never? any comparisons of his new code with the old one.

Fridger

PS: the proper purpose of HDR is actually to enhance the dynamics of light rendering on the screen, since screens have a problem with too large brightness ranges.

My hdr code consists of 2 parts, of which the first is most relevant to this discussion:

1. Exposure control: Adapting the brightness of stars in the scene according to the dynamic range (total scene brightness range). Exposure is varied exponentially with time to simulate the gradual contraction/expansion of the human iris.

2. Bloom (glare): Applying a shiny blur around spots with a brightness above a certain threshold. I used a "poor man's" method which could run on old graphics chips without shaders but this method was slow and can be considered completely obsolete now.

#1 is almost entirely implemented inside the Renderer::draw() method.
Here is the logic:

1. Find the maximum magnitude of any objects within the scene
Here we ignore the magnitude of any planet beneath us, but this could be changed to simulate light pollution, etc.

2. Compute an eclipse between eye <-> closest object <-> brightest star to prevent a bright shadowed star from inflating the scene's dynamic range. To reduce computational load, a single ray is cast between the eye and the star to compute the shadow, so this only works well for spherical blockers (but luckily works with most planets and moons) and single-star systems (works nicely in our solar system, but maybe not so for others).

3. Compute the exposure, which decays exponentially with time according to some not very scientifically accurate but aesthetically-pleasing parameters (of course, more physically accurate models could be substituted):


4. Scale the brightness of stars inversely with the exposure.

As the exposure control code is designed to take advantage of existing code in Renderer::draw() that loops through the list of objects in the scene, #1 and #2 are actually done after #3 and #4, but this is ok since the exposure varies with time and is updated every frame and so is only off by 1 frame or ~1/30 seconds.

The advantage of this method is that the computational requirements are quite modest as there is already code to loop through objects and code to find the brightest one can be inserted easily. Also, brightness of stars is already scaled by a brightness factor and the exposure control just hooks into this.
It is better I think than the traditional way of exposure/tone mapping which is to render a floating point texture and use pixel shaders, because my way can scale even with large screen resolutions.

It works quite well, but I did have some problems with the brightness of stars on the surfaces of planets. The brightness would sometimes not vary smoothly as the planet rotated into/out of darkness. I suspect a numerical precision issue. It could be solved with some more careful analysis.

Despite I understand why Fridger is not very interested in this quite common stuff (in term of physics) and this feature is not proper to a soft dedicated to cosmology, I still believe it should be considered seriously to finally present to the public a correct view of space unlike what we may have seen from decades in whatever scifi movie or pseudo educational TV shows. The idea that most people are completely unaware that in many cases absolutely no stars are visible in space, is just horrific just like believing space is full of nice colorful nebulas and other marvelous but chimeric objects...

So in short, if the soft is all about cosmology, this feature is a non sense, but if the solar system is also a specific point of attention with atmospheric rendering an other cool stuff, then the occultation of dim sources light by bright objects should be part of the show!

I agree in that if we are viewing a raw dataset (e.g., Sloan), it makes little sense to adjust star magnitude based on a perceptual model of the human eye.
But exposure control with a time-varying "iris" is only one way to map data with a very large dynamic range into a range that can be displayed/perceived. If we think of the human eye as a sensor, we could generalize the sensor response and swap in different mapping functions (time varying or not) according to the kind of sensor that we wanted to simulate.