since fgfs apparently knows the phase of the moon, it could adjust that slider for the current lighting condition...
Except FG really doesn't know the phase of the moon.
The moon actually is a real sphere in FG, and it's the only object coming with its own light source (because it has to be always white regardless of how sunlight appears on the ground). The sphere is moved around by the moon orbital code (including perturbations from Jupiter it seems) - so the moon phase emerges as a consequence of relative position between the moon's sun and the moon and the lighting equation on the screen.
There's no parameter anywhere in FG that tells you what the moon phase is.
Now, the actual code computes earth and planet orbits in double precision in a heliocentric coordinate system, but the moon goes around Earth, whereas the renderer operates in floating position, so no celestial object is at its true position as far as the renderer is concerned, and also the renderer doesn't know what geocentric is, it just does camera-centric.
So even something like getting pointing vectors to objects in the same coordinate system such as to do a dot product is not trivial in this context. I've actually spent some three hours reading through everything without finding the obvious position where to obtain the phase, and I've asked Durk (who wrote the celestial objects code in the first place) whether he'd know an obvious spot and he didn't know either.
That's the difference between 'could just' and actually doing it.
(Not that I wouldn't have tried, since the idea is so obvious even I got it back when I implemented the moonlight).
the key is to enable and disable those that don't apply to the current viewing angle... in other words, don't process all of them right now... only process those that pertain to the current view...
Thanks for teaching me optimization
Unfortunately, GLSL usually doesn't play along.
You'd think that if you do
if (condition)
{do something that takes 5 ms;}
else
{do something that takes 4 ms;}
you end up taking no more than 5 ms, but the sad reality is that under many conditions you will take 9 ms, because the way this is frequently processed is that the driver frequently thinks it wiser to evaluate first both branches fully and then decides which one to take (the reasons being connected with how a texture mapping internally is represented via gradiant fields and the need to avoid discontinuities).
Also, the condition to evaluate doesn't come free either - often it's surprisingly expensive because it's not just a simple a==b, it requires you to check on several environmental conditions and angles. And suddenly you save some work by not doing something, but you add workload by computing the condition - and you may in fact lose out on this.
So more often then not, the disabling thing doesn't work out the way you expect - the object disappears from view alright, but its performance footprint is still there. You can do this only under a rather limited set of conditions.
If you want to optimize shader code, you need to learn to think a different way. That's why I said in another thread that being able to read GLSL doesn't equal understanding why it's written the way it is or how it should be written
in a worse case scenario, a check box and a --prop: can be added to the sim for realistic lighting including moon lighting...
Yeah, then you have a property somewhere. You still need to write an extra set of shaders to make use of it, because, as explained above, chains of 'if-statements' don't do the trick. You need to maintain the shaders, i.e. whenever you want to change something in, say, haze, you need to modify all these extra shaders as well. That's a lot of work.
I wonder if there is a way of turning one off when the other is on? Assuming:
gl_LightSource[0] -> sun
gl_LightSource[1] -> moon
It would probably work quite well to assume that if there is any sun lighting, there will be no noticeable moon lighting.
We're using sun position until sun is 15 deg below the horizon to compute dawn light in ALS - you'd screw that first. Furthermore, you'd immediately screw Rembrandt and default, since they don't know we're doing trickery with the light source and just faithfully use it 'as is'. You'd probably get some strong discontinuities in lighting, with the Moon suddenly flashing on. This could be all made to work in principle by delving into all shaders and smoothing over the discontinuities, passing flags on what to do etc,
Again, plenty of work.