With which OXP's do you guys rumble the Ooniverse?

[Astrobe]

...More annoying, some textures look good from afar but awful when near the station.

Exactly the reason they are used for secondary planets .

Yeah, but then Extra Stations happened

BTW the default generative texturing has good-looking diffuse/specular lighting effects that we kind of lose with full-blown textures. Too bad that the proc-gen'ed landmasses are too uniform. Maybe if one uses a mixed approach using a texture as a basis and then procedurally altering it... Maybe stamping a bunch of nebulae textures on the base canvas could work. Also, a tropical strip could break the monotony even more. The recipe could be general enough to draw moon textures and gas giant textures.

[pleiadian]

I don't know if this is being used in Oolite's source... if it isn't, maybe it's possible to implement libnoise, a coherent noise generator. Among other things it is capable of procedually generate planetary textures, to the level you define. There are quite some awesome examples, so maybe this is worth considering.

// EDIT: Example 8 is the interesting one.

[Astrobe]

I don't know if this is being used in Oolite's source... if it isn't, maybe it's possible to implement libnoise, a coherent noise generator. Among other things it is capable of procedually generate planetary textures, to the level you define. There are quite some awesome examples, so maybe this is worth considering.

// EDIT: Example 8 is the interesting one.

You mean tutorial 8? Yes, it actually looks very similar to some POV/system redux textures.

Oolite uses Objective-C, though. from what I see interfacing with external C libraries is seamless, but interfacing with C++ can be quite annoying in my experience (the C++ compiler does horrible things to function names).

Oolite may actually use something like that already, but maybe with a low "detail" level in order to save time because it's generated on the fly every time you exit witchspace.

Hmmm... I see an "octave" variable in TextureStore.m, which apparently is linked to the level of detail. The code there seems to be 8 years old, so maybe increasing to it can be worth something and ok with "modern" computers?

[another_commander]

Ten years ago libnoise on planets had been investigated as an option by the guys who where then developers and there had been also some experiments done with it. Back then we had only two variants though (Earth-like and Mars-like) and maybe the lack of variety was one of the reasons libnoise was dropped at the end and we went with what became what we have today.I am sure there are still discussions in the very old posts of this very forum about it, but can't go looking for them right now. Here is what that experiment looked like back at the days of version 1.65 (maybe Tutorial 8 had something to do with it )



Integrating libnoise or other C++ libraries in Oolite's core code is indeed annoying but certainly not impossible (Spidermonkey is another C++ library that we have used for ages), as long as those libarires export their functions without mangling their names in the process.

[Redspear]

I rather like the second one

BTW what happened to the cloud layer that used to cover many of the worlds?
Am I just not exploring enough or has it become much more subtle?

At the risk of leaving this topic altogether, I also rather liked the old hexagonal planet textures of seven or so years ago. I quite fancy some of those for an insect moon (or even a planet).
[Recovering]I do tend to use the default textures for the main planets these days as they have improved significantly from the previous (early post-hexagons) incarnation.

[Astrobe]

Ten years ago libnoise on planets had been investigated as an option by the guys who where then developers and there had been also some experiments done with it.

Yep, found'em. In a thread with a certain title similar to a recent one... Also found out that texturestore.m is not used any more - at least for this purpose. Your Oolite Dev pack for Windows works nicely.

[another_commander]

Yup, we use the OOPlanetTextureGenerator class now for planet textures. By the way, that class supports also an alternative algorithm for texture generation, enabled by defining PERLIN_3D to 1. It creates a bit intense textures, but they do look a bit more complex and interesting than what we are normally used to. Here is Leesti with this algorithm and ambient light set to 0.025:

[Norby]

Cool! I support to set it as default.

[Redspear]

It is indeed cool but I can see why it's not the default... it could really do with some flat bits.

[Astrobe]

Yup, we use the OOPlanetTextureGenerator class now for planet textures. By the way, that class supports also an alternative algorithm for texture generation, enabled by defining PERLIN_3D to 1.

Tried this briefly yesterday but it didn't compile. However, I got something similar by increasing some constant in the current code - perhaps a bit less pretty though.

However, the problem I have with the proc-gen'ed textures is that they are essentially monochrome and therefore lack land features; in particular, there's no trace of civilization. I'm thinking about generating a second layer to add forests and/or cities. I'm also thinking about alterations near the equator.

[Disembodied]

in particular, there's no trace of civilization

This, especially on the night side! City glowmaps - especially if they could be linked to population size (and maybe tech level too, depending on whether you imagine TL1 to be stone age, or current Earth technology, or somewhere in between: personally I favour the stone age end of things, as I think it makes for a more interesting imaginary universe).

[pleiadian]

in particular, there's no trace of civilization

This, especially on the night side! City glowmaps - especially if they could be linked to population size (and maybe tech level too, depending on whether you imagine TL1 to be stone age, or current Earth technology, or somewhere in between: personally I favour the stone age end of things, as I think it makes for a more interesting imaginary universe).

Now this is an interesting idea... However some things need to be taken into account: planet size, landmass locations, tech level, and population numbers. For example one of the higher TL planets can have a number population centres (cities), determined by a random number generator. But since that would be a high TL number, the number of cities shouldn't be below, let's say, 20, and not higher than 40. Through the rendering mechanism for planets, I assume one can figure out where the landmasses are. Then, generate a glowmap or transparent texture of some kind which places the cities at certain spots. The trick now is to keep the cities at the same spot for each planet.

An alternative is to have transparent PNG's with pseudo-shining spots pre-rendered once, and "overlay" those on the existing planets. Since there are "only" 2048 planets in the core game, this number of mostly transparent PNG's wouldn't use up too much space.

This is coming from someone who does know a little bit of programming, and these would be the two approaches that come to my mind.

[jackiebean]

Yup, we use the OOPlanetTextureGenerator class now for planet textures. By the way, that class supports also an alternative algorithm for texture generation, enabled by defining PERLIN_3D to 1.

Tried this briefly yesterday but it didn't compile. However, I got something similar by increasing some constant in the current code - perhaps a bit less pretty though.

However, the problem I have with the proc-gen'ed textures is that they are essentially monochrome and therefore lack land features; in particular, there's no trace of civilization. I'm thinking about generating a second layer to add forests and/or cities. I'm also thinking about alterations near the equator.

Bingo. Layers would be the way to go. The trick is would those layers clash with the procedural textures? Or could they cleverly be blended somehow? Planet texturing methods have their pros and cons. procedural methods tend to make everything look like a gas planet of sorts where the texture is distorted differently for each similar planet, layering adds variety and can conceal some of the more glaring problems of procedural planets. Perhaps a cloud layer that is procedural instead? Terrain bump maps would be cool, and put to good use for locating city centers. The danger is that the effect may not go as planned and falling back to static textures with procedural cloud layers may be in order. I dunno. But i know the more static planet textures there are, the harder it is to keep things from becoming bloated. The only big professional game i can think of that had a lot of planets with variety was the mass effect series, although those could get redundant as well but they were not as detailed either as planets you could fly near. I wonder how X3 did theirs?

[Redspear]

A couple of old pics with a procedurally generated base layer (I think), then a 'real' cloud layer and finally oolite's cloud layer on top (the alpha setting I forget). Two different planets but the components are (in essence) the same. Not the finest examples perhaps but adequate and to hand.





Although far from perfect, to my eyes each layer masks in part the imperfections of the other.
The surface is more interesting for the fact that a great deal of it is only hinted at.

Off topic yet?

[Astrobe]

in particular, there's no trace of civilization

This, especially on the night side! City glowmaps - especially if they could be linked to population size (and maybe tech level too, depending on whether you imagine TL1 to be stone age, or current Earth technology, or somewhere in between: personally I favour the stone age end of things, as I think it makes for a more interesting imaginary universe).

Now this is an interesting idea... However some things need to be taken into account: planet size, landmass locations, tech level, and population numbers. For example one of the higher TL planets can have a number population centres (cities), determined by a random number generator. But since that would be a high TL number, the number of cities shouldn't be below, let's say, 20, and not higher than 40. Through the rendering mechanism for planets, I assume one can figure out where the landmasses are. Then, generate a glowmap or transparent texture of some kind which places the cities at certain spots. The trick now is to keep the cities at the same spot for each planet.

An alternative is to have transparent PNG's with pseudo-shining spots pre-rendered once, and "overlay" those on the existing planets. Since there are "only" 2048 planets in the core game, this number of mostly transparent PNG's wouldn't use up too much space.

This is coming from someone who does know a little bit of programming, and these would be the two approaches that come to my mind.

I suggested the night lights thing before. Apparently it needs (one more) shader. That would be a major advertising feature for 1.86 imho, that and the improved atmosphere shader.

Before we think about the size and the places of the city, we gotta find an efficient way to add them in the planetary texturing stuff, which actually already generates two 2048x2048 textures (land and clouds). But I think that in order to get a satisfying result, one would have to switch to 4096x4096 - four times more pixels. Except if one also switches to 2:1 aspect ratio that reduces that to two times more pixels. I'm running this config on an Intel i3 and while one experiences a slight "hiccup" at launch or at witchspace exit, it's definitely worth it. The textures look better near the station.

For cities I believe one has to generate yet another texture to be overlaid on the terrain texture. In my attempts to use the land texture generator, simple methods make cities "hug" the coastlines or the centre of continents. Not very satisfying. And one cannot perform complex computations when it's per-pixel. Certainly more satisfying results could be achieved by overlaying a "cities" texture on top of the land texture. I think that even "tiling" nebula textures or stars textures could work, as oceans and clouds should be enough to "hide the trick" - actually I believe that it could look better that POV textures, which don't benefit from shader magic.
Gotta dive deeper in the OOlite engine and figure out how to do that.