Fellow rebels,
I don't know if any other mod has come down the pike dealing with landscape lighting as controlled by the Sun and Moon. A while back I attempted to mod the Sun.class so as to improve upon the 4.09 (and earlier) performance.
As we all know, the stock game does not take into account any variation of day of month, treating all instances as the 15th. Furthermore, the year is not taken into account at all. For this reason, the Moon's historic phases were not needed to consider.
Another failing of the code--which is still present to this day (!)--is the incorrect assigning to the Moon a declination (celestial 'latitude', if you will) *always* equal to that of the Sun. This results in such glaring discrepancies as a summer full Moon being up to 45 degrees higher in the sky than it should, rising well before sunset/setting well after sunrise. Or a winter full Moon being too low in the sky, rising long after sunset/setting long before sunrise. (In reality, the full Moon rises/sets the same time as the Sun sets/rises. And it's always 180 opposite the Sun.)
I've rectified this last issue, with just a single line of code.
In my earlier work on the 4.09 Sun.class I made some progress on better controlling the lighting parameters Ambient, Diffuse and Specular, as controlled by both Sun and Moon. I used a logical scheme based on formulae that provided smooth changes and transitions. But I was stymied by what appeared to be other code at a deeper level that introduced jarring changes. That would have required me to introduce 'fudge factors' at key solar depression angles (to be determined experimentally), and I just got a bit too tired to delve further into that morass.
The other day I decided to incorporate the 4.12 Sun.class into 4.09, because I could see that it uses a much more sophisticated routine for lighting of landscape and clouds. This involved adding the new Moon phase calculation classfile, and altering a few other classes as well. After the better part of two days of brain melting (and assistance from our one-man help desk, Mike), this non-Java monkey finally succeeded.
Getting it working, that is. There remain some issues with cloud lighting to grapple with. It might mostly be the result of the aforementioned deeper code in the game being not properly compatible. It may that be the case that in 4.10 (when this new Sun.class was introduced) there was a change made in what to us is inaccessible game code.
But already, in the main the new lighting is an improvement, particularly in lighter twilight and when the Sun is close to the horizon
The main problems:
- In deep twilight the clouds are too bright.
- As the weather type increases (from "Good" to "Thunderstorm"), the way the cloud brightness is seen to increase as one's viewpoint rises from ground level up to the cloud underside gets really awful. By the stage of thunder, the cloud underside practically *shines* a brilliant white, even at sunset.
- I don't know how 4.12 handles the twilight-to-night transition in *sky* brightness (which is NOT controlled by Sun.class), but in 4.09 it goes from moderately dark to final darkness all too suddenly, near the end of the twilight period (which lasts too long to begin with.) This might necessitate adding a compensating 'fudge factor.'
Alongside this, the Sun.class code necessarily uses actual Y/M/D dates, in order to calculate the correct Moon phase. And so now my missions can have this calendrical data incorporated.
Another project... Modding Zloy Petrushko's Atmosphere Mod v4.3 (or is that 3.4?) I didn't feel it necessary to have the mission designer think about these elements:
- Top height of wind layer.
- Strength of gusts.
- Strength of turbulence.
My rationale is as follows: Have the mission maker supply only a wind direction and speed.
It's generally fine to have the wind present at all altitudes. And so setting a top layer of 10,000m (or higher) in code suffices.
I treat turbulence as arising from two sources, and hence are treated separately:
- Mechanical, due to wind friction with and hence strongest nearer the ground/sea.
- Convective, in cumulus clouds.
I model the mechanical turbulence as a function of wind speed; faster wind, greater turbulence. And it falls off with height, this upper limit rising with stronger wind. I will be making this turbulence both weaker and of shallower depth over water.
The convective turbulence is strongest within the cumulus cloud layer, tapering off to zero by some height above the cloud tops. Below the cloud base, this turbulence falls off also, going to zero at sea level. And the maximum turbulence scales with cloud type, being obviously greatest for thundercloud.
With both components of turbulence calculated separately, that value which is the greater applies. (They do not add together where both components are in operation simultaneously.)
For the time being I have omitted the business of gusts entirely, but might re-incorporate it. For one thing, gusts are typically measured as a *horizontal* variation from the mean wind speed. This mostly arises from mechanical turbulence near the ground. The vertical component of such turbulent mixing is well enough handled for our purposes by the parameter "turbulence". And so gusts should be treated, if they are to be, as part of the near-ground mechanical turbulence component. In cloud-induced turbulence, the vertical shear of convection does not induce to a meaningful degree what we would call 'gusts', and so, again, the "turbulence" parameter serves well enough.
What my previous paragraph gets to is that the turbulence by itself does a reasonable job of bucking our plane. Gusts, if to be used, should be present nearer to the surface, where the mechanical turbulence component is active. And just like for mechanical turbulence, gusts in any event would scale as the wind speed.
Now you can see why I feel it's unnecessary to burden the mission maker with more than wind speed and direction. Mechanical turbulence and gusts scale as the wind speed in a rather closely coupled way. No need to violate physical laws here!
As for cloud turbulence, it also can be treated as a reasonably consistent parameter based upon the game's cloud type. Now, one concession I can come up with here is a scaling factor, whereby the cloud turbulence could be made to be lesser or greater than the 'stock' value in code. For example, this could be written to be he mission file weather section as, say, "CloudTurbFactor 0.7", or "CloudTurbFactor 1.4". Respectively, the cloud turbulence would be reduced to 70% or increased to 140% of the coded value.
As you can see, I prefer to base a model upon some semblance of physical laws, utilizing a model (however simplified) that is internally unified and consistent, without odd discrepancies.
Until now I never played with wind and turbulence enabled because of the unrealistic behavior. Now I leave it on all the time!
Anyhoo. This is the current state of things. I don't know of what parts of this kind of work might have been implemented in other mods, outside of that which I do know. Or if any of this is of interest to the Rebels (or Privateers and beyond
). Thoughts?
Author
Topic: I'm working on adapting 4.12 Sun.class to 4.09 (Read 1781 times)
