Oolite Bulletins

Coming soon...

Till now atmospheres have been blue. I wanted to improve this a bit, so that planets with atmospheres other than blue could be generated. I recently realized that for years we've had a property in planetinfo that was being consistently ignored: air_color. No matter what you set it to, entering a planet's atmosphere would always turn the sky blue, going towards a teal / greensish tint the deeper in the atmosphere one went.

This has been fixed. air_color now produces the right color for the sky. Not only that, it is used as the atmosphere scatter color when the planet is viewed from space. You will finally be able to generate Mars, Jupiter and other planets. Just set this key in your planetinfo.plist to the color of your choice and you are good to go. Not only that, you can change it via Javascript too using the system.info.air_color property, which will allow real-time change of the sky color.

Here are some examples:

Mars (using air_color of "1.0 0.2 0.0")





Jupiter with various color atmospheres (black, orange, magenta, blue)





Committing tonight if all goes well.

... and we are not even done yet. In a fast-approaching new build, setting the amount of air color that will be mixed in the overall atmosphere color will be user and script settable. The new key will be air_color_mix_ratio and is a float clamped between 0.0 and 1.0. With this, you get absolute control on how the atmosphere appears, since air_color and air_color_mix_ratio are parameters which are passed directly to shaders. Real-time changes of this parameter are possible using system.info.air_color_mix_ratio = <number which will be clamped between 0.0 and 1.0>.

For example, using this new key, the Mars atmosphere which appeared kind of white-ish in the earlier screenie, can now take a more realistic appearance and be something like this:



Same air_color as before, air_color_mix_ratio is set to 0.9 in planetinfo.plist.

I came to the realization that system.info may not be the best place to put the controls for the atmosphere colors. So, there goes commit 2d1bcb2 to fix that.

Taken straight from the commit message: Atmosphere color parameters can now be also controlled from the JS Planet object. This enables script control over atmospheres of OXP added planets. The two new properties are airColor and airColorMixRatio. The system.info.airColor and .airColorMixRatio remain but control only the main system planet.

Examples of usage:

About atmosphere and planetary surface rendering: right now, the surface goes dark (as if it's night) and the sky somewhat light (not quite as if it's day) as you get near the surface irrespective of it being night or day at that surface point.

It's not really a big deal, since you have to make planet fall to see it.

another_commander wrote: ↑Thu Jul 23, 2020 7:07 pm

Taken straight from the commit message: Atmosphere color parameters can now be also controlled from the JS Planet object. This enables script control over atmospheres of OXP added planets. The two new properties are airColor and airColorMixRatio. The system.info.airColor and .airColorMixRatio remain but control only the main system planet.

JS in-game planet properties vs. planetinfo settings follows the usual layers prioritization?

What about additional planets specified in the plist? JS only?

Milo wrote: ↑Thu Jul 23, 2020 7:54 pm

JS in-game planet properties vs. planetinfo settings follows the usual layers prioritization?

Layer prioritization should work, but I have not tested it. Normally I would not expect these particular settings to be required to be layered, though.

What about additional planets specified in the plist? JS only?

Both plist and JS work for additional planets.

I'm thinking of the scenario that one OXP added a planet via plist (or JS) and wants to enforce its settings over another OXP that might be applying blanket changes unaware that the first OXP has something specific in mind for that system.

My guess is that standard OXP prioritization will apply and one OXP will win over the other if there is a direct conflict, depending on which was run last. For no direct conflicts, blanket changes (usually applied at the "universal" section of planetinfo) come before specific planet ones.

another_commander wrote: ↑Wed Jul 22, 2020 2:30 pm

Here are some examples:

Nice. Good work that man!

The planet customization continues to improve. In the next nightly, we have the terminator_threshold_vector shipdata key and the equivalent JSPlanet terminatorThresholdVector property. This gives us control over the color of the planet's terminator. By default the terminator is a reddish orange color, as you are well aware.

The way this property works is not entirely straightforward, but this is what we had in the planet and atmosphere shaders so we continue to use it in the same way, only now it is externally controlled rather than hardcoded in the shaders. This property is of type Vector, so you can pass it from shipdata as terminator_threshold_vector = "<x> <y> <z>" or from a scipt like system.mainPlanet.terminatorThresholdVector = [x, y, z].

The x, y and z values work as follows:
The game will take the cosine of the angle between the surface normal for each pixel and the light vector and do a smooth interpolation from 0.0 to each of the x, y and z values. Any such angle cosine less than 0.0 is clamped to 0.0 and any cosine higher than the x (and y and z accordingly) will be clamped to 1.0. For any cosine values in between 0.0 and x (and y and z accordingly), a smooth step hermite function is applied in order to get the color gradient you see as the terminator. OK, I don't expect to have explained it in an understandable way (sorry for that), but what this means in broad practical terms, is that the vector described with the x, y and z values corresponds more or less (emphasis on the more and the less) to the inverse of the color you want the terminator to be. So, for the default value of [x, y, z] == [0.105, 0.18, 0.28] we have x being the smallest value, therefore it will represent the dominant terminator color. Similarly in the example, the z component is the highest value and will correspond to the weakest component of the terminator color - hence the reddish appearance. For Reorte, in this build we have applied as a demo a blue terminator and we achieve that by passing as [x, y, z] the vector [0.28, 0.18, 0.105]. Now the z component is the smallest value and the x is the biggest, therefore we end up with a blue terminator color. The higher the numbers we use, the wider the terminator becomes.

Examples of the feature in action, with the settings used for each one:

Default terminator ("0.105 0.18 0.28")


terminator_threshold_vector = "0.28 0.18 0.105"


terminator_threshold_vector = "0.33 0.05 0.105"


terminator_threshold_vector = "0.05 0.1 0.9"


terminator_threshold_vector = "0.05 0.7 0.9"

It looks quite strange at the equatorial light/dark line of demarcation because the color abruptly vanishes at the dark transition line. I'd expect the dark to still carry some hint of the color too.

How does the terminator look with a core planet?

@Milo: This is no different to what we've had until now. The only thing that has changed is that the terminator vector is now a user defined parameter and before it was hardcoded. The appearance is exactly as before, with only the color changing. Also, note the color bleeding very slightly in the dark side of the central ice mass.

@Cody: Core planets look as usual. Here are a few:
Xevera:


Bemaera:


Lave:


But for Reorte, things have changed a bit for demo purposes:


Note that I am using somewhat elevated brightness settings for planets (sun radiance 5.0, exposure 2.0).

Thanks to the dev team for Oolite 1.90 - shame I can't play it.

Cody wrote: ↑Sun Aug 30, 2020 11:52 am

Thanks to the dev team for Oolite 1.90 - shame I can't play it.

Redirecting system, weapons and engines power
to extra-charge positive energy
for your complete and fast recovery, amigo!

<!-- Getafix is going back into silent running. -->