Planetary Systems

Core package

• Current OXZ version 1.7.0
• Uploaded 06 July 2020

Planetary System Texture Pack A...Z

• Current OXZ version 1.6.0
• Uploaded 23 November 2020

This project was started as a tweaked version of Orbits. Good old Orbits (authors Ebi and Kaks‎) had textured planets and improved compatibility with large moons. Planetary Systems is a major modification of the original Orbits - but the original Orbits script, realizing the generation of the solar system and its orbital dynamics, remains as a crucial component of Planetary Systems. So let’s start our presentation from Orbits' script modifications.

System layout and orbital mechanics

The maximum additional number of planets in a system has been raised from 7 to 8.

Like the original Orbits, this script generates a planet subset, selecting planets from the planetinfo.plist on pseudo-random basis: but technically there are 10 variants for every planet class in the planetinfo.plist. Mini-terra, for example, are presented with radii of 2750, 2775, 2800, and 2975 km. The script preudo-randomly selects one from ten variants for every planet class in the generated subset. Ten radius variants for every planet class is not just for visual diversity (it is hard to notice visual difference between 3400 and 3600 km radius without a specially planned experiment!). The main reason is provide more diversity for the initial data, used by PlanetEngine (about PlanetEngine a bit later)

These planets are divided onto classes based on radius:

• Miniterra – Mercury analog
• Venus-like planet or desert Terra-like planet
• Subterra – Mars-like planet
• Superterra aka Super-Earth
• Two gas giants like Jupiter or Saturn without rings
• Ice giant – Neptune analog
• Dwarf terra – Pluto analog

It seems to be similar to our Solar system layout with exception of super-earth, but really Orbits generates wide range of possible layouts. You can see systems with only gas giants except main planet or with only terrestrial planets.

Discriminating borderline between large moon and small planet is raised from 1000 to 2500 km (from 10,000 to 25,000 m in game units). So you can simulate large moons such as Titan or Ganymede.

Original Orbits has fixed orbital period of main planet 300 days (standard year of canonic Lave). Modified script uses orbital period of main planet calculated on base of sun mass and distance (this part of work is provided by AstroLibrary external function in Sun Gear). So you’ll have not only unique planet layout for every system, you’ll have unique value of local year.

Like the original Orbits, Planetary Systems generates more compact systems than our real Solar system. Tionisla for example has almost all our planets except the Neptune analog, but with the following arrangement:

• 0.63 OU – Miniterra
• 1.00 OU – Main planet
• 2.20 OU – Terra
• 3.04 OU – Subterra
• 3.79 OU – Superterra
• 4.77 OU – Gas Giant
• 5.94 OU – Gas Giant
• 6.67 OU – Dwarf Terra

The Planetary Systems script, inherited from Orbits, limits possible layouts. You’ll never have two planets between sun and main planet as in our Solar system, only one is possible. You’ll never have second planet close enough to the habitable zone so you’ll never generate a lovely sci-fi setting with two or more habitable planets in the system. And you’ll never generate systems expanding beyond 9 OU or so.

Planetary Systems like the original Orbits is not intended for simulation of elongated elliptical orbits, high inclination orbits, orbital resonances etc. All planets orbit in the same plane without any dynamic interaction. An extremely simplified model like that of a school astronomy handbook, of course.

It is possible to realize a technically more complex model by upgrading the code, but some crucial parts of the original code are too hard for me to clearly understand and to modify without risk of breaking it. So I focused on more obvious tasks.

PlanetEngine

Planet mass and chemical composition are two initial parameters, determining planet appearance. For moons and terrestrial planets you have such building materials as water ice (density 0.9), rock (density approx 2.5) and iron-nickel alloy (density approx 8.0). So for planets and moons composed mainly from these materials you’ll have mean density between these extreme values. In inner region of Solar system where solar irradiation is enough to sublimate volatiles you have mostly mix of rock and metal with only few volatiles and mean density of terrestrial planets are between 3.940 for Mars and 5.515 for Earth. In outer region of Solar system beyond frost line all three building materials are present so moons of gas and ice giants composed mainly from mix of water ice, rock and metal and mean density is from 0.98 (Tethys, composed mainly from water ice) to 3.53 (extremely dehydrated due to volcanic activity Io). There are also more exotic materials such as dry ice (solid carbon dioxide), nitrogen ice, water-ammonia brine, high pressure water ice modifications etc. But as rule of thumb: more distance from sun – less insolation – lower equilibrium temperature – less sublimation effects – more volatiles – lower mean density.

Situation with planet mass is more complex. Mean density of terrestrial planet depends not only from its bulk composition. More massive planet with same composition will be more dense due to gravitational compression. From a different standpoint, more massive planet in the same region of space can capture more volatiles, thus reducing mean density.

Having sufficient mass, planets can effectively capture hydrogen and helium from primordial nebula, so super-earth with critical mass above 10 Earth mass will develop extremely massive atmosphere and will transform onto ice giant or gas giant. Difference between ice giants like Uranus and Neptune and gas giants as Jupiter and Saturn lies mainly in their inner composition, not in their visual appearance. Uranus for example consists mainly from water, ammonia and methane ices (approx 9.3...13.5 Earth masses) and rocky core (0.5...3.7 Earth masses). Hydrogen and helium in Uranus atmosphere are only 0.5...1.5 Earth mass. Jupiter, for contrast, contains relatively small core – 12...45 Earth mass. Most of Jupiter’s 318 Earth mass consists from metallic, liquid and gaseous forms of hydrogen.

This is real astronomy. In Oolite we have no planet masses nor planet density simulated, so PlanetEngine deals with some retro-engineering: taking planet radius and planet density (calculated as function of insolation and radius) it calculates planet mass. There are really three functions for planet density in PlanetEngine: for terrestrial planet, for ice giants and for gas giants (in case of ice and gas planets located deeply outside frost line insolation is not taken into account, just planet radius). Having planet mass and radius, calculations of surface gravity and escape velocity are trivial tasks. Just one note. PlanetEngine uses planet with 6400 km radius as Earth analog for simplicity, not 6371 km real Earth mean radius (6378 km, mentioned in Sun Gear topic, is Earth equatorial radius), so calculated surface gravity and escape velocity will be slightly different from real values based on precise calculations using gravitational constant G.

Atmosphere parameters are less formalized data on project. Look on our Solar system. Extremely thin and cold Mars atmosphere (6 mbar pressure on “sea level”) is a present result of dissipation of more dense initial atmosphere. Extremely dense and hot Venus atmosphere (93 bar and 735 K on surface level) is a result of limestone degassing caused by runaway greenhouse effect. Extremely oxygen enriched Earth atmosphere (21% oxygen) is result of activity of life on planet. We have no (yet!) exact knowledge of initial atmosphere parameters for these planets nor accurate general model of atmosphere evolution during 4.6 billions years from formation of Solar System. So this part of PlanetEngine is a bit wild and, honestly, oversimplified speculation based on some assumptions.

PlanetEngine calculates atmosphere mass per unit of surface square based on initial atmosphere pool (more planet mass and less insolation – more fraction of volatiles) and rate of dissipation (again more planet mass and less insolation – more atmosphere remains). Atmosphere pressure is calculated as weight of atmosphere mass per surface unit (you can calculate it having only atmosphere mass per surface unit and surface gravity).

Atmosphere temperature calculation is not so simple. Greenhouse effect is roughly calculated based on atmosphere mass per surface unit. Final temperature on surface level is a sum of equilibrium temperature of planet surface without atmosphere and greenhouse offset. This is oversimplified model, not taking into account planet albedo nor atmosphere composition. But it simulates diversity of conditions, generating planets with extremely rarefied cold atmosphere like Mars, dense cold atmospheres like Titan or superdense extremely hot atmosphere like Venus.

Planet Data Interface

That’s enough about the details of PlanetEngine's internal functions. How it will it be manifested in game?
If you have PlanetFall OXP (author Thargoid) or my PlanetLand (OXP with similar functionality, based on PlanetFall) installed, after docking with planet/moon surface port you’ll have access to new F4 screen Planet Data interface. It generates pages with slightly different output for planets and moons.

Accessed through the F4 page on landing

Planet Data Sheet for planet ports

• ORBITAL DATA
• Orbit radius in OU
• Orbit period in days
• PHYSICAL DATA
• Radius, km
• Mean density, g/cm^3
• Mass, TU – Terran Units
• Escape velocity, km/s
• Surface gravity, g
• Atmosphere pressure, bar
• Surface temperature, K

Output for the Moon Data Sheet is almost the same, but orbit radius is displayed in host planet radius units, not in OU.

There are two tricks in the case of super-earths, ice giants and gas giants.

Gas giants have no surface in common sense. Gas deeply below cloud layers smoothly reaches state of supercritical fluid. So Planet Data Sheet page takes 1 bar atmosphere pressure level as reference point in case of gas and ice giants.

Non-linear scale is implemented to large planets (super-earths, ice and gas giants). Being only 172,500 m radius in game really, largest gas giant is displayed in Planet Data Sheet page as gas giant of 72,500 km radius instead 17,250 km of default planet scale. Planet mass, escape velocity and surface gravity is displayed scaled too. This non-linear scale is used for display purposes only. Any calculation are based on internal scale. This is forced decision. Honest simulation of planet with 72,500 km radius (slightly more than Jupiter’s 71,500 km equatorial radius) will create too wide zone of mass-lock. Starting from surface port on Cobra Mk III, you’ll need 34.5 min on full throttle to leave mass-lock zone. Honest displaying of real 17,250 km radius of Jupiter analog will lead to too low mass of planet: having density 1.325 like real Jupiter its analog will have only 4.7 mass in Earth units, not real 318!

There is also bias in small planet parameters. Mercury and Pluto analogs in Planetary Systems are larger than prototypes. Initially it was implemented as simple way to avoid confusion between small planets and large moons.

There are two parameters, extremely important for a good sci-fi setting and completely missing in the PlanetEngine so far.

Planet axial rotation period (local day)

Typical value of rotation_speed parameter in planetinfo.plist included in game is between 0 and 0.005 radians/s. Having a rotation_speed of 0.0045 and a radius of 4116 km (the case of the vanilla Lave), you’ll have a rotation period only 23 min 16 s and linear rotation velocity on an equator of 18.5 km/s! Such a planet in reality will be ripped asunder by the centrifugal forces. Of course, this is a setting just for visual appearance. It seems a nice idea to give player opportunity to observe almost all the planet during the short trip from the witchpoint to the main station. But if you have PlanetFall and descend to low altitude, things seem to be wrong – the planet rotation looks too fast comparing with ship speed.

Setting rotation_speed to honest value 0.0001 or so (rotation period 17 hours 45 mins) will solve this problem, but at the cost of visual appearances – it is problematic to note subtle changes in planet details visibility during few minutes of flight. I have no idea how best to solve this conflict.

Planet axis tilt

This parameter is crucial for climate modeling. But in Oolite planet orientation seems to work unpredictably – despite the same orientation declared for all additional planets in planetinfo.plist some of them are almost upright, some are lying on their sides. I have no idea how to fix it. Honestly.

Smart selection of planet texture

Initially Planetary Systems has a predetermined set of textures for every planet class such as a Martian texture set for analogs of Mars, Venusian for analogs of Venus and so on. A Mercury analog orbit is always created between the sun and the orbit of the main planet, so it is safe to give Mercury analog texture of heavy cratered dry world such real Mercury or Moon. Terra-like planet in absence of Mercury analog will be be inside main planet orbit and looks like Venus, but if Mercury analog is present, Terra-like planet will be placed outside main planet orbit and looks like snowball Earth. Pluto analog is extreme case: in rare events of absence of other additional planets it occupies place of Mercury and looks like dry hot airless world, not icy cold airless one. These variations were implemented in next iteration of [b]Planetary Systems[/b].

Now textures for terrestrial planets selected using not planet positions per se but surface temperature and atmosphere pressure, calculated by PlanetEngine. So we have more possible variants in planet appearance: it may looks like Mars with polar ice caps or without ones, like cold windy rocky desert or hot sandy desert, like snowball Earth or volcanic world. I hope it will be fun to explore these variations.

There are five variants of every type of texture (60 in sum), selected for every system pseudo-randomly.

Dependencies

This OXP uses AstroLibrary functions in Sun Gear OXP to calculate properties of system planets and moons. So Sun Gear OXP is obligatory. Habitable Main Planets OXP is highly recommended to provide more reliable data for main planet. This is no way to match calculated atmosphere density and surface temperature for planet of 3000 km radius, for example, with vanilla game classification of such world as agricultural/tropical paradise. :-)

Known issues

• Interaction of Planetary Systems with planets added by other OXPs can cause inflation of system far beyond planned size. Diso.oxp with 4 additional planets is a good example of such a system.

• Planetary Systems is incompatible with Additional Planets SR due to the same reason.

• Like the original Orbits, Planetary Systems needs some time to generate a solar system, so problems with the positioning of moons, stations and ships added by third party OXPs or system populators can appear. See more details discussed in this post from Dec 23, 2018

• A specific case of incompatibility is the Market Cooldown OXZ (author Spara). It uses the sum of station distances to the witchpoint and the sun as a unique key for port identification. This method works in static deterministic system, but fails in dynamic systems with a changing psw triangle.

• Planetary Systems in combination with Sun Gear generates really vast solar systems. Having a planet with radius 6400 km and the sun at a distance of 695 planet radii, planets on the outer 7.5 OU edge of the system will be at a distance of 333,600,000 m in game units – slightly less than distance between Earth and Moon in reality. This takes 8 hours 16 minutes for a Cobra Mk III to fly on a Torus drive, so you need special instruments for the exploration of such distant planets such as Norby’s Torus To Sun or my own warp drive, implemented in Hard Way. Navigation in such vast systems is almost impossible without the ASC (Advanced Space Compass) upgrade. These considerations, however, are implemented only for intra-system navigation: the distance between the main planet and the witchpoint remains unaffected, and so therefore so does inter-system navigation.

• Orbits: Although the two OXZ's will allow you to play with both installed, the two scripts are not compatible and playing with both OXZs installed will slow down the game. Oolite is also likely to crash with an out of memory error when populating a system.

This is because Planetary Systems contains a tweaked copy of the Orbits script. Both OXZs will therefore instruct Oolite to move planets and moons to the positions each script has specified. As the two OXZs are telling Oolite to do different things, the completion conditions are never met. This can cause the game to become stuck in a loop until it runs out of memory and crashes.

OXP structure

To provide easy updating all planet textures have been repacked as separate texture packs.

• Planetary Systems.oxp - core package.
• Planetary Systems Texture Pack A.oxp - Ice Deserts
• Planetary Systems Texture Pack B.oxp - Cold Deserts
• Planetary Systems Texture Pack C.oxp - Sand Deserts
• Planetary Systems Texture Pack D.oxp - Volcanic Deserts
• Planetary Systems Texture Pack E.oxp - Cold Mars Analogs
• Planetary Systems Texture Pack F.oxp - Hot Mars Analogs
• Planetary Systems Texture Pack G.oxp - Gas and Ice Giants
• Planetary Systems Texture Pack H.oxp - Miscellaneous (Mercury, Pluto, Venus analogs and super-earths).

The original planet textures were reprocessed. Reprocessing included converting the JPG file format into PNG, rescaling the image size to standard aspect for lat-long maps 2:1 with size 2 * 2^n width and 2^n height, using color saturation and lights/shadows level correction filters.
Texture size 4096x2048 was used as a compromise between file size and visual quality, but due to the shortage of high-res texture files, medium-res 2048x1024 textures were also used to complete the texture sets.

Future Plans

Stranger posted this on the Roolite forum in 2020 (English translation through Google Translate) in response to Another_commander's improvements to Oolite v.1.90 (Aug 2020).

Background - Stranger's FPO/Famous Planets Overhaul (v.1.3 is circa 2018, the original was 2013) contains some 100 or so high quality textures for the Famous Planets with the original music. His System Makeup (v.2.6 is circa 2019, the original was 2013) takes the same textures and uses them for all the planets but loses the ability to use the music and possibly the FP planet descriptions. PlanetLand is Stranger's enhanced version of our PlanetFall. PlanetEngine is part of this Planetary Systems .oxp and is detailed above. This is presumably all available through Roolite. These textures are realistic and big: 2.5Mb - 15Mb each. The resulting oxp's are massive. Two individual examples of his recently rejigged FPO's (with both diffuse and specular maps - and custom 4096 x 2048 textures (2020, 15-17Mb) are already on the Expansions Manager: FPO Lave & FPO Zaonce.

I think it’s worth explaining why the hell I’m doing something on the sly there and what I generally need to be prepared for. Usually I prefer to demonstrate the results, rather than talk about my brilliant plans in an exciting way. But here, it seems, the occasion to clearly state their plans for the foreseeable future is ripe.

A revolution is an interesting but an uncomfortable time. New solutions provide new opportunities, but do not get along easily with the old ones. Leaving everything as it is and gradually redoing everything piece by piece is reasonable, but not always possible.

Oolite v.1.90 introduced new impressive features. Now you can make worlds of marvelous beauty by hand assembling them with mirrored ponds, relief and atmospheric haze, and they are no longer not just balls which are pasted over with matte photo wallpapers. So why not slowly replace my obsolete System Makeup textures on this new basis?

But the fact is that the new textures consist of two layers - a diffuse map (the same photo wallpapers) and a normal map, in which there is just information about the relief and the mirror ponds. And alas, Oolite v.1.90 can read this normal map only if it is registered in the planetinfo.plist. Through the javascript, alas, this is not possible. That is, this wonderfully smart mechanism for choosing the appearance of the planet, taking into account the mice and frogs living on it, does not, alas, work with the new textures.

Okay, but can you refuse to define the textures through a script, registering these texture maps in the planetinfo.plist and then gradually upgrade it, replacing the outdated manual textures with the new ones under the same names?

One can. But there are now two more problems which emerge.

First, there are 96 textures in the System Makeup package. This, of course, is already 16 times more than in the old System Redux, from which the evolution of the package once began. But the full Universe includes 2048 systems, and it would be best if all the main planets of these systems should have a unique appearance. Planets can be similar almost to the point of indistinguishability, but yet still not be identical in the smallest detail. Okay, we have a hundred more famous planets with unique textures, but in fact, for the most part, textures from System Makeup are used for famous planets. That is, most planets in each sector/galaxy are identical copies, and if we take the Universum as a whole, then a randomly selected planet has a couple of dozen identical copies. And the probability of having two planets with the same appearance within a 7 LY radius, whatever your common sense tells you, is much higher than negligible. Simply put, such twins will be met with much more often than you think.

And secondly, even if I'm not a lone modder, but a company commander of military designers who could be ordered to produce 2048 unique textures, the minimum acceptable 2K texture in terms of visual quality weighs in at about 3...3.5 MB, and with a normal map at 4...5 MB. That is, a package of unique textures of minimum quality will weigh 8...10 GB. For a commercial game, this is an irrelevant question, but for Oolite, with its limitation of up to 150 MB/.oxp, this is an obscene size. And that's why Povray Planets has no chance to appear in the OXZ format. On the other hand, the procedural generator built into the game creates 2048 unique planets, and all the information about the game world in the root planetinfo.plist - and weighs in at only 2.7 MB! If you create a planetinfo.plist, which will contain information just about the appearance of the main planets, then you can fit it into a mere megabyte, or even less.

I think the idea is clear. Entrust the generation of the majority of the unique planets to a procedural generator and slowly engage in a hand-made assembly of unique textures.

Alas, until recently, the results of the procedural generator, to put it delicately, did not quite meet expectations. Not that the results of the procedural generator were hopelessly bad - in some ways, the procedurally generated planets even outperformed the manually assembled planets. Mirror ponds at least. Well, still a pseudo-relief, albeit primitive, like sandpaper. But alas, hard lighting in the Extra Details mode completely killed the feeling of volume. Instead of balls, acid-etched disks were obtained. Yes, even in the Shaders Enabled mode, not everything is perfect either. But I tend to put up with a filed terminator line, just to see balls, rather than flat disks. So with each release, I wondered how things were going with the planets, sighed reproachfully and returned to my balls covered with photo wallpapers.

In Oolite v.1.90, the visual quality barrier has finally been jumped, and on both sides. Unique handmade textures with terrain and mirrored ponds - I already talked about this at the very beginning, but procedurally generated textures now look pretty good in the potential. Psychedelic purple oceans and turquoise continents could be changed to something more like water and green before, but now the ability to control the color of the atmosphere has been added to this. And again, the lighting model has become noticeably better, so now when comparing procedurally generated planets with hand-assembled planets, the former feeling of rejection no longer arises: well, how can you incorporate all this in one go?

Alas, the procedural generator is still limited in its capabilities. You can make a desert planet - a supercontinent with isolated inland seas. And you can make an ocean planet with archipelagos of islands. But nothing like our Earth can be done - instead of several large continents and oceans, the procedural generator is trying to make a maze out of the land and the sea. A procedural generator can make something like green lowlands and glacier-covered highlands, but that's about it. No belt zonation, no vast inland deserts, no remarkable relief details like mountain ranges and vast plains, canyons, a network of riverbeds. In this regard, handmade textures are still unbeatable, and if a network of giant canyons is mentioned in the description of the planet, you can indeed make these canyons. Procedural clouds are quite different from the real cloud pattern with tropical cyclone spirals, jet streams and large-scale circulation cells. But once again, alas, it is difficult, if not impossible, to make real volumetric clouds in Oolite. I tried to experiment with relief clouds. Something similar to cloud ripples is obtained only in a narrow zone near the terminator line, and the closer to the terminator, the worse. The oolith does not understand that the clouds are not mountains, and casts unnaturally hard shadows on the clouds. So from a distance, all these funnels of tropical cyclones over the ocean look beautiful, but when viewed from close-up, the artificiality is obvious. True volumetric clouds are difficult, if not impossible, to make in Oolite. But still, the mirror oceans and terrain are a good reason to take on the Famous Planets at a new level.

There is one serious problem with the reworking of the Famous Planets. Oolite 1.90, as I said, can only read new normal maps from planetinfo.plist, which means that System Makeup will cover not only new procedurally generated planets, but also new Famous Planets through its script. System Makeup must be disabled. But in turn , PlanetLand calls an external System Makeup script to select the landscapes of the planets. You need to at least transfer the script to PlanetLand , and for good, thoroughly redo the PlanetLand script itself- it was written a long time ago and does not use any information from PlanetEngine. And besides, the PlanetLand script does not meet the strict requirements for safe variable names.

The Famous Planets Overhaul will also have to be disabled, as it also assigns its own textures through a script and will overhaul these new Famous Planets.

In view of the foregoing, the next update of the SW Universum is logically divided into three stages.

I. Creation of planetinfo.plist with newly defined appearance parameters for all 2048 major planets.

Cosmetic correction of the colour of the oceans and continents will not be limited. Large planets better hold not only the atmosphere, but also water. And isn’t it logical to assume that a tiny planet-ocean the size of Mars is unlikely (except perhaps a water-ammonia ocean under a thick layer of ice), but that among large planets this would be quite a common option?

And since PlanetEngine can calculate atmospheric pressure and temperature on the surface of the planet, isn't it logical to use this data to select suitable colors - forest, steppe, desert, tundra, snow, Martian and even the lunar surfaces? And what about the variety of shades of ocean water - from the gloomy gray of the Arctic oceans to the azure of the tropical? And isn't it logical that the climate of the planet determines the degree of development of the polar caps and the density of clouds?

Wait a minute, the thoughtful reader will object. PlanetEngine is a script, right? And what about planetinfo.plist?

And besides. You don't think I'm going to edit 2048 entries manually, do you? I'm too lazy for that. To generate a large planetinfo.plist I use the FileMaker DB. And the PlanetEngine, which is implemented in Sun Gear and Planetary Systems in JavaScript, is based on an algorithm that I wrote and debugged in FileMaker.

In fact, the first stage of work has already been done. And in order not to produce entities beyond necessity, I included all the new information in an update to the already existing Habitable Main Planets package . Now this package not only redefines the population radii of the main planets of the Universum, but also gives them a more believable appearance.

The solution turned out to be safe. The updated Habitable Main Planets package does not technically conflict with either System Makeup or the Famous Planets Overhaul. You can use these packs for now - just in this case you will not see the new appearance of the planets. And so I freed my hands for unhurried work on the next stage of the project.

II. Modification of already existing packages.

First of all, we are talking about PlanetLand. Here again, work is planned in three stages.
1. Quickly patch an existing package so that it can work autonomously from System Makeup, and again, free one's hands for further leisurely work on the package.
2. Clean up the garbage code and bring the variable names in line with the standard.
3. Rewrite the script that determines the choice of landscapes, this time using the information provided by the PlanetEngine.

The first part of the work has already been done, at the moment there is an intermediate version of PlanetLand 2.6 . At first glance, it works, but just in case, I have left in the archive the previous version of PlanetLand 2.5. I simply do not have enough time to test intermediate versions - I will test the final edition before release. I do not intend to continue to support System Makeup. This package played its role and now has its place in the museum. Habitable Main Planets now makes pretty decent looking planets from System Makeup which you can safely refuse. Fortunately, apart from PlanetLand, there are no other packages in my Universum that somehow depend on System Makeup.

Planetary Systems and Moons also urgently need to be redone, but this is not the most urgent work at the moment. In the new lighting model, the planets are too light, the brightness curves must be bent down. Upgrading these packages for the new features is still difficult - they determine the textures of planets and moons through scripts. In the case of Moons, one can enter the desired texture maps in the planetinfo.plist and, in principle, this should work. With Planetary Systems the situation is more complicated - this package uses a smart texture selection mechanism. I would still hope that in the next release the game will start to support assigning a normal map through javascript.

III. Unique handmade textures.

This time, I do not intend to repeat my epic feat - to cover all the Famous Planets with unique textures. This rework will only affect planets with notable visual features. There will no longer be a single Famous Planets Overhaul package . Most of the textures in the System Makeup and Famous Planets Overhaul packs was in 2K format (2048 x 1024). I intend to move to 4K. I would go to 8K too, but unfortunately, I am limited by the resolution of the source files for texture assembly. The old 2K Lave texture was 3.3 MB. The new 4K Lave texture with normal map weighs in at 15 MB. It should be expected that the rest of the textures will grow proportionally, so I intend to release updated Famous Planets in separate packages, as I have already done with Lave.

To see the new Lave, and in the future, other new Famous Planets, the Famous Planets Overhaul package will have to be turned off. Alas, in doing so, you lose not only the old unique textures, but also the descriptions made for several additional planets in the set. I'm thinking of preparing a version of the Famous Planets Addenda package that will only have textual information that is missing in the Famous Planets package version 2.7. Unfortunately, the whole set of new Famous Planets will not be ready soon - this laborious work is not done quickly. In the meantime, a recommendation for an advanced user: you can disable and re-enable the old Famous Planets Overhaul package without deleting it from the AddOns folder:

Famous Planets Overhaul.oxp → Famous Planets Overhaul.oxp OFF

Thank you for your understanding.

Credits

• Orbits main script - Ebi, Kaks.
• Textures - Celestia Motherlode and freebitmaps.blogspot.com.
• See more detailed texture credits in Texture Pack Readme documents.

Links

• BB Discussion Thread
• Strangers World

Famous Planets Override (FPO)

Stranger has an alternative, highly detailed, set of planetary textures available. These can be used in conjunction with the Povray Planets set.

• Famous Planets Overhaul c. 100 detailed Planetary textures for Galaxy 1
• FPO Lave - more detailed than that in the above set
• FPO Zaonce - different and more detailed than that in the above set