Oolite Bulletins

Leesti is Moon 8k

Latest version: 0.3.0
Uploaded 15.01.2021

Leesti is Moon LSM 8k

Latest version: 0.3.0
Uploaded 15.01.2021

Well, now we have ability to simulate in fictional Ooniverse real planets with rendered terrain using high quality maps of Solar System planets. Ironically, the nearest to our Earth celestial body was omitted in cool demo OXPz created by another_commander. Let’s fix it. Moon is beautiful and interesting world.

Leesti is Moon 8k was created using Tionisla is Mars 8k as guideline.
The diffuse map used is a reprocessed version of a texture originally from CGI Moon Kit by NASA's Scientific Visualization Studio.
Link to CGI Moon Kit https://svs.gsfc.nasa.gov/4720
The normal map used is a reprocessed version of Moon normal map originally from Celestia Motherlode (http://celestiamotherlode.net/catalog/moon.php). Creator of original texture is John van Vliet from the Celestia community.
Link to original normal map http://www.celestiamotherlode.net/creat ... mal_L4.zip

Changes made to original normal map include the addition of an alpha channel, a swap of red and green channels and inversion of green channel (thanks to another_commander for these valuable details of normal map processing).
And of course, thanks to another_commander for invaluable help to create and test this OXP!

Leesti is Moon 8k has huge textures so it can be too hard for low end graphic cards to render it properly. I’ll assemble 4k lite version if it will be such demand.

May be you are far beyond Old Worlds now. No problem. Create new pilot, jump to Leesti and enjoy planet look.

Leesti is Moon LSM 8k

This is special edition of Leesti is Moon 8k with marked soft landing sites of human unmanned probes and piloted spacecrafts.

Soviet Luna stations (marked with Cyrillic "Л" letter with number):

Luna-9
Luna-13
Luna-16
Luna-17
Luna-20
Luna-21
Luna-24

US Surveyor probes (marked as S1...S7):

Surveyor 1
Surveyor 3
Surveyor 5
Surveyor 6
Surveyor 7

US Apollo Lunar Modules (marked as A11...A17):

Apollo 11
Apollo 12
Apollo 14
Apollo 15
Apollo 16
Apollo 17

Chinese Chang'e stations (marked as C3...C5):

Chang'e 3
Chang'e 4
Chang'e 5

Impact sites and crash landing sites are not included, so Soviet Luna-2 station, making first historical Moon impact, is not presented.
Apollo 12 LM was landed perfectly near Surveyor 3, so both landing sites marked by single cross.
Positions of Lunokhod 1 (Luna-17) and Lunokhod 2 (Luna-21) are not marked.

Both version of Leesti is Moon are available in download manager, so if you download and install both version, Moon texture with markers will override unmarked texture. You can try this feature and just delete unnecessary pack to save space. But if you want to have both versions, I think best option would be to download LSM version from oolite.org and install it in AddOns folder manually - you can remove it ad reinstall in any time without losing original archive.

Looks very nice, well done. Just a couple of observations:

1. Was it a conscious decision to keep the atmosphere? The air color is set to full black so it is not immediately obvious that an atmosphere is there, but you can remove it altogether by setting the has_atmosphere = NO; in shipdata.

2. There seems to be some polar distortion present in the texture (image shown is with the atmosphere removed):



But overall, it looks really good:

(without atmosphere)





(and with atmosphere, as released):

Yes, I was overlooked simple decision to completely remove atmosphere. Thank you!
Can you explain terminator_threshold_vector parameter? I can't find info in Planetinfo.plist page. Seems it is declared as fixed value terminator_threshold_vector = "0.105 0.18 0.28"; for all 2048 systems.

stranger wrote: ↑Sun Sep 13, 2020 2:23 pm

Can you explain terminator_threshold_vector parameter? I can't find info in Planetinfo.plist page. Seems it is declared as fixed value terminator_threshold_vector = "0.105 0.18 0.28"; for all 2048 systems.

You asked the $1M question but I'm glad you did. Okay, let's see how I can explain this.

Terminator threshold is a 3D vector. It contains the cosine values of the angle between light and surface normal (let's call this LN for the rest of this post), each corresponding to an rgb color component, beyond which daylight-night shadow starts being generated to form the terminator. In the case of your Moon, this triplet is set to [0,0,0], so there is a distinct, hard terminator as the daylight side goes all the way to 90 degrees (cos90deg = 0) for all three r,g,b values, before light stops being rendered. You can soften this effect if you want, by setting it to something like [0.2, 0.2, 0.2], which is what I did for Jupiter. This tells the shader to start applying darkness gradually once the cosine of LN starts going below 0.2 (i.e. LN less than 78.5 deg) for each of its r, g and b components. This creates a softer gray terminator, but you can apply some color by varying the cosines of each rgb component, which is what is done for almost all planets in the default shipdata.plist. So, [0.105, 0.18, 0.28] defines a terminator where the red component starts getting darker after the cosine of LN has reached a value of 0.105, the green component starts getting darker after cos(LN) becomes less than 0.18 and the blue component starts getting darker after cos(LN) becomes less than 0.28. Because the red component will start getting darker quite a bit later than the others, since it is the smallest of the three cosine values (so the angle it refers to will be closer to 90 degrees than the other two), it will be the prevalent color and that is why you see a reddish terminator in most of the default planets. If you check Reorte though, you will find that it has a different terminator threshold triplet, with the blue component being the smallest of the three. With the same logic as above, you will find that Reorte appears as having a blue terminator, which is also what you will see in the Tionisla is Mars OXP.

A reasonable question would be "why so complicated?". The answer is that this is how it was done forever in our shaders and I simply did not feel mentally ready to change the implementation to make reference to actual rgb colors (although, now that I write about it, it is possible that there could be a relatively painless way to do it but oh well...). Just kept what we had been using before for legacy reasons and took that a step further. It could be a good exercise to implement terminator color as rgb values rather than angle cosines, but it is what it is for 1.90 and the foreseeable future.

Does this make some sense? Do I win the million dollars? If not, let me know if there are specific questions and I'll try to answer them.

Edit: Also keep in mind that when no atmosphere is used, the terminator threshold is hardcoded in the shaders as [0.08, 0.08, 0.08]. That is because without atmosphere the shader internal macro OOSTD_HARSH_MISTRESS is defined to 1.

Thank you! I get idea. Need some practice to use it, but your explanation is clear!

Version 0.2.0
Set has_atmosphere = NO;
This change removes residual atmosphere haze, visible near Moon limb in previous version. And it removes air friction too! Cool!

@another_commander
Has you plans in future Oolite releases to implement numeric value of atmosphere density instead Boollean has_atmosphere = YES || NO? It may be set to 1.0 by default. Seems it will be nice feature to adjust atmosphere visual effects and air friction.
And has you plans to implement has_atmosphere for additional planets too? Of course, small planets like Mercury can be declared as moons, lacking atmosphere, but it will be nice to has this option. It will simplify fine adjusting of planetary systems.
In any case I'm very impressed with progress in 1.90 release. Nice work!

stranger wrote: ↑Mon Sep 14, 2020 2:09 am

@another_commander
Has you plans in future Oolite releases to implement numeric value of atmosphere density instead Boollean has_atmosphere = YES || NO? It may be set to 1.0 by default. Seems it will be nice feature to adjust atmosphere visual effects and air friction.

Not an immediate plan, but I have also thought of this adjustment and also visual adjustments on the atmosphere, depending on thickness. You can already do this by changing certain hardcoded values on the atmosphere shader, but the idea is that this hardcoded stuff will become uniforms, with their values passed to the shader by the program.

And has you plans to implement has_atmosphere for additional planets too? Of course, small planets like Mercury can be declared as moons, lacking atmosphere, but it will be nice to has this option. It will simplify fine adjusting of planetary systems.

Pretty sure that this is already possible if you use system.addMoon("name") instead of system.addPlanet("name"). The main differences between additional planets and moons are the existence of atmosphere and clouds. It is something that can be considered, but probably not very high priority.

In any case I'm very impressed with progress in 1.90 release. Nice work!

o7

Cool! That Moon needs an Eagle Transporter flying over it.

Cody wrote: ↑Mon Sep 14, 2020 5:38 pm

That Moon needs an Eagle Transporter flying over it.

Hmm... Maybe special edition with marked locations of historical landing sites?

Leesti is Moon LSM 8k is released. It is special edition of Leesti is Moon with marked soft landing sites of human unmanned probes and piloted spacecrafts.
See initial post for more details.

@another_commander
Is it possible to declare normal maps of planets and moons in script? Trying to do it. Diffuse map was OK, normal map was failed to load.

stranger wrote: ↑Thu Sep 17, 2020 4:21 am

@another_commander
Is it possible to declare normal maps of planets and moons in script? Trying to do it. Diffuse map was OK, normal map was failed to load.

No, it is not. Quite unfortunate, because I just realized myself that the diffuse map can be changed by script.

Sadly. My plans to update my Planetary Systems will be delayed.
Well, let's exploit amazing possibility to improve look of some main planets!

Something has been bothering me about this OXP so I had a more detailed look at its textures and I realized that there is a problem: the diffuse map texture clearly carries lighting information, i.e. many craters seem to be lit from a specific direction in the texture. This is a big no-no for diffuse maps under the new lighting model. The planet shader should decide how the object is lit, not the texture, which should be completely devoid of any lighting information (same goes for ship textures, btw, they should be devoid of light information and leave that entirely to the standard fragment shader).

So I found a different set of textures from NASA, namely the CGI Moon Kit by NASA's Scientific Visualization Studio. The kit contains a diffuse and a displacement map, which I had to convert to a normal map so that Oolite could process it. A red/green channel swap later, and the results are here:

Hardly any polar distortion because both textures have the polar correction embedded. This is looking directly down the pole, which is in the middle of the terminator:


And a few more generic moon pics:









I have uploaded the new moon textures here (64.8MB, link valid for one week from the date of this post): https://we.tl/t-wTO8pnSiKf

Thank you!
I understand the issue. Seems I was not patient enough to search for more suitable resource I'll reassemble OXP using your textures.
Regarding copyright. Almost all work, and all most critical part of work, is yours, and I feel I have no right to declare myself as author. Co-authorship maybe, another_commander & stranger?