Progress

General discussion for players of Oolite.

Moderators: winston, another_commander

another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6683
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

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")
Image

Image


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

Committing tonight if all goes well.
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6683
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

... 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:

Image

Same air_color as before, air_color_mix_ratio is set to 0.9 in planetinfo.plist.
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6683
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

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:

Code: Select all

system.mainPlanet.airColor = "blueColor";
system.mainPlanet.airColorMixRatio = 0.8;
dybal
---- E L I T E ----
---- E L I T E ----
Posts: 499
Joined: Mon Feb 10, 2020 12:47 pm

Re: Progress

Post by dybal »

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.
User avatar
Milo
---- E L I T E ----
---- E L I T E ----
Posts: 462
Joined: Mon Sep 17, 2018 5:01 pm

Re: Progress

Post by Milo »

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?
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6683
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

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.
User avatar
Milo
---- E L I T E ----
---- E L I T E ----
Posts: 462
Joined: Mon Sep 17, 2018 5:01 pm

Re: Progress

Post by Milo »

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.
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6683
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

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.
User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 2687
Joined: Thu Jun 20, 2013 10:22 pm
Location: On the moon Thought, orbiting the planet Ignorance.

Re: Progress

Post by Redspear »

another_commander wrote: Wed Jul 22, 2020 2:30 pm
Here are some examples:
Nice. Good work that man! 8)
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6683
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

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")
Image

terminator_threshold_vector = "0.28 0.18 0.105"
Image

terminator_threshold_vector = "0.33 0.05 0.105"
Image

terminator_threshold_vector = "0.05 0.1 0.9"
Image

terminator_threshold_vector = "0.05 0.7 0.9"
Image
User avatar
Milo
---- E L I T E ----
---- E L I T E ----
Posts: 462
Joined: Mon Sep 17, 2018 5:01 pm

Re: Progress

Post by Milo »

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.
User avatar
Cody
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
Posts: 16081
Joined: Sat Jul 04, 2009 9:31 pm
Location: The Lizard's Claw
Contact:

Re: Progress

Post by Cody »

How does the terminator look with a core planet?
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6683
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

@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:
Image

Bemaera:
Image

Lave:
Image

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

Note that I am using somewhat elevated brightness settings for planets (sun radiance 5.0, exposure 2.0).
User avatar
Cody
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
Posts: 16081
Joined: Sat Jul 04, 2009 9:31 pm
Location: The Lizard's Claw
Contact:

Re: Progress

Post by Cody »

Thanks to the dev team for Oolite 1.90 - shame I can't play it.
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
User avatar
Getafix
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 979
Joined: Tue Apr 01, 2008 12:55 pm
Location: A small ice asteroid, orbiting Oresrati in Galaxy 8 (a.k.a. northwest Armorica).
Contact:

Re: Progress

Post by Getafix »

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! :wink:

<!-- Getafix is going back into silent running. -->
"Any sufficiently advanced information is indistinguishable from noise." [Newman, Lachmann, Moore]
Post Reply