We all know that the default sky is broken and looks bad, and my opinion is that the fix for this bug is the nice skydome available when ALS is ON.
But instead of saying "hey we have a fix for the default sky who is broken ! It's the "skydome", you (or whoever) said "hey the default sky is broken, I will leave this broken sky and commit a better sky named skydome". I really don't understand why the skydome is an optional feature instead of the fix of our broken default sky.
I think we're going through that one periodically... Since I haven't done it for a year or so, let's explain it again
The answer in short is that ALS at lowest quality level in fact is the fix of the default sky.
Skydome and terrain aren't unrelated. The reason is that fog isn't an object associated with a 'fog' model loaded into the scene, it's always something rendered onto a background. So, to avoid jarring visual discontinuities, you need to render the same fog model onto both terrain and skydome. If you don't, you get this
(that's from Lauri's first implementation - skydome uses its native Mie+Rayleigh model, terrain uses the default rendering scheme diffuse haze mode, they ain't matching anywhere - bad)
Assuming we want no visual discontinuities (at least I don't want any, because that prompts just a bazillion of bug reports), in order to use the skydome shader it was therefore necessary to 1) add a layer of diffuse fog to the skydome rendering and 2) modify the default rendering scheme to use the same layer.
You can read up on the whole history
here and see the subsequent layers of 'fixes' being applied by yours truly. It's not like I didn't try what you suggest - it just didn't work.
That immediately led to the next problem, which is that the skydome shader shows very rich lighting at dusk and dawn (because it knows all about Mie and Rayleigh scattering) - so in low light, it never ever matched even semi-plausibly with a simple fog layer as the default scheme used. The solution was again to bite the bullet and do a complete position differential light calculation in both skydome and terrain shader to match.
So, ALS at low shader quality level is the minimal alteration you have to make to the default rendering scheme to use the skydome shader without creating visual discontinuities. It is impossible to make the skydome shader work with the default renderer's lighting or fogging scheme.
Since that minimal light and fog computation is substantially more GPU-demanding than the default sky with default light and fog, the decision to make it optional seems sort of reasonable.
And since light and fog in ALS need to be position-differential, you can't simply call a different fog function to get the effect, you need to do lots of extra geometry work in the vertex shader stage already. Which means you can't simply graft the light and fog model of ALS onto an existing shader effect, you have to re-implement the existing shader effect inside the ALS light and fog workflow.
You imagine there'd be a choice anywhere along the path, but I never saw one, and I don't see it now.
Why this feature is not simply available in the default rendering scheme ? Even if you like to have everything optionally we could have a checkbox for that "Trees moving in wind". Why it is an ALS-specific feature ? I don't see the point to make this feature available only in ALS, it should works as fine in the default rendering scheme. I really don't understand why this feature is not a standard feature available in default rendering scheme.
Because Stuart, who wrote both the tree rendering code for the default scheme and the trees move in the wind code decided to not include it. He's the maintainer of that effect, it's his decision, whereas I am the maintainer of ALS and made a different decision.
This is a question like 'Why are the sidewinder missiles of the F-14b not implemented for the F-16?' Because the person who maintains the airplane didn't do it. I don't know what your idea of FG development is - but as a rule, we just don't go changing things in areas maintained by other people without their approval. So it's not my call to make.
again, you added a nice eye candy here, but it's again an ALS-specific feature, why ? why it isn't a simple checkbox "Improve contrast on slope" ? why this feature require to be implemented in a separate rendering scheme and leave the default scheme looking bad ? (and here we are falling back to my first words: I would prefer that the existing stuff is improved instead of creating a separate stuff)
Because, again, there is no simple switch in GLSL 'render this effect using ALS' - the slope line code exists in some context and is matched to a particular fragment shader file. So, if you want it in Rembrandt or default as well, you have to write a corresponding effect and shader code from scratch, or adapt an existing effect. I could theoretically do that, but I am maintainer of all the Advanced Weather code as well as all of the ALS shader code, that's a lot of work already, and I'm not interested in adding yet more to my plate.
As stated above, ALS has to use quite different vertex and fragment shaders from default - we don't have any choice here. So in essence, you're asking me why don't I develop for default fog, sky and light rather than ALS fog, sky and light or why don't I double my workload. I think the answer to that one should be fairly obvious. Like everyone else in development, I have to focus my efforts.
Finally, yes it's just a matter of GUI re-work, but behind the scene it's finally a totally separated rendering scheme, and that's where I disagree, your work shouldn't be a separate stuff, it should be the improvement/bugfix of the default rendering.
Well, I'll let you in on a secret. If you use the default renderer, it reads terrain-default.eff and executes terrain-default.vert and terrain-default.frag. If you use the water effect in the default renderer, it reads water.eff and executes water_sine.vert and water_sine.frag - totally different files. Which is to say, for every different effect and many different quality levels, the default rendering scheme refers to separate files.
Whereas if you use the basic ALS terrain rendering, it reads terrain-default.eff and executes terrain-ALS-base.vert and terrain-ALS-base.frag. It also refers to separate files. It's internally no different from they way the default renderer manages different terrain types and quality levels.
So behind the scenes there is actually no technical difference between ALS and default - the defining difference is in the way they handle light, sky and fog, and these are not interchangeable (see above). You have to group matching shaders, otherwise you get graphical discontinuities. Which is what the GUI has to do in some way.