plannets.oxp - is it still working?

[pagroove]

And pink oceans?

Good work on the texture generator!

[Hoopy]

yup - oceans can be any colour you like

[Star Gazer]

And pink oceans?

.... ...hey, strawberry blancmange!!

[CaptKev]

Does anyone know how to set 'land_hsb_color' to black?, I've tried "0 0 0 1.0" but it just doesn't seem to work.

[Commander McLane]

Just let me make sure that I've understood everything so far. If my short summary is wrong at any point, please correct me.

We have got two different approaches to texturing planets.

Captn Kev (and contributers) is creating a set of 16 different textures that will be dispersed randomly (or semi-randomly, or pseudo-randomly) over the galaxies. Some small problems still have to be sorted out, like visual interferences with the existing (non-textured) planets.

Hoopy follows a completely different and independent approach of working on procedural textures. So no set of a certain number of pre-defined textures which come in the Textures-folder of the Oolite distribution, but a routine in the code itself that generates a texture from some variables on the fly, practically whenever you enter a system. Also here some small problems still have to be sorted out, like porting the code from C# to objective C, and of course implementing it into the game-code.

In the end we will have either the former or the latter, but not both. Am I right so far?

Personally I'd prefer the procedural approach, for a couple of reasons. (1) It creates a greater variation; in principle each planet would have its own, unique texture. (2) It's in the spirit of the whole, seed-created, Ooniverse. I guess also the values for the texture-triggering variables would be taken from the seed, wouldn't they? (3) It would be the revival of the procedural textures that already existed in 1.65 and 1.68.

Being no coder myself, the following might either be blatantly obvious or stupidly wrong: Shouldn't it be fairly easy to implement Hoopy's procedural textures in the code, by just taking the (currently disabled) existing procedural texture code out and replacing it with the new one?

I have a couple of questions, though: (1) Will the texture for any given planet always be the same? So Lave looks like Lave, whenever I jump into the system? If the governing variables are taken from the seed, this should be the case. And in my opinion it is a must. (2) It should still be possible to overwrite the procedural texture by a design-texture in those systems where an OXP wants to do this. Is this possible? Was this possible with the old procedural textures? EDIT: Hmm, second thought on this: Do we really need that? I have to admit I am not aware of any currently existing OXP that actually textures a main planet. I know only OXPs that add further planets, which may be textured or not. So the requirement should be: For any additional planet that doesn't come with its own .png-texture, a procedural texture should be created according to the planet's seed, which can be defined in planetinfo.plist; which is, by the way, the status quo. Even now you can give each additional planet a seed which is used for defining its features.

[Hoopy]

That seems a fair summary.

It should be possible to have both at once though - procedural generation as a default but any planet could be overidden by an OXP.

The procedural texture is generated from a 'seed' number and a load of parameters.

The seed basically determins the altitude of the land accross the planet.

The parameters determine things like the colours used, size of the ice caps, sea level, how bumpy it all is etc.

If you look on my flickr page you can see that each image lists the seed that was used to make it. Most of them use a seed of 281 and so look pretty similar.

So we could just give every planet a seed of
planet Number + galaxy number * 256
then they'd all be different.

The parameters would then ideally be set (in some way) by the famous fibonacci planet parameters and we should be able to get ocean worlds having lots of ocean, pink worlds being pink etc.

One other thing to note is that it takes a few tenths of a second to create the procedural texture whereas using a prexisting one is instant. I guess we could store the textures for each planet as you visit them the delay would only happen the first time...?

[another_commander]

Being no coder myself, the following might either be blatantly obvious or stupidly wrong: Shouldn't it be fairly easy to implement Hoopy's procedural textures in the code, by just taking the (currently disabled) existing procedural texture code out and replacing it with the new one?

That will be difficult to answer until we get a chance to look at the actual Hoopy's code. It could be very simple, or excessively complicated. Generally, things that appear really simple are the ones that have the biggest difficulty implementing at the end.

[Hoopy]

I can post the code somewhere if anybody wants to play with it.

Basically it fills a 2x2 grid with random numbers and then uses bicubic interpolation to smooth that out onto an array of heights of the size we want to generate eg 256x256.

Then it repeats with a 4x4 grid but scales the numbers (to 70% works quite well) before smoothing and adding them.

And repeats until it's adding a 128x128 grid.

Then that array is converted to an image by assiging rgb values to each pixel based on the height (low is sea, then rock then ice) and latitude (around the equator the 'rock' is greeny-yellow for vegetation, around the poles it's all ice).

This last bit of the code is messy at the moment and needs converting into something that's a bit intuitive instead of a load of random equations to work out the palettes. I think defining a few colours for each of a few latitudes and using the cubic interpolation stuff will do the job much better.

[Commander McLane]

@ Hoopy: In Oolite a seed always consists of six numbers, not only one. You may take advantage of that if it comes to taking more variables from the seed.

BTW: I never have understood why there are six seed numbers in Oolite. I always thought the seed in Elite works like a Fibonacci sequence: f(n) = f(n-1) + f(n-2), and then modulo 256. But for that sequence you need only two values in the seed (the first two ones, n=1 and n=2). So why six in Oolite's seeds, which themselves aren't following the Fibonacci sequence? E.g. the seed for Galaxy 1 is: 74, 90, 72, 2, 83, 183. 74 + 90 is not 72. 90 + 72 is not 2. 72 + 2 is not 83. And 2 + 83 is not 183. So what would be the next number in the sequence? I have no idea, but it should be somehow determined by the existing sequence.

Or is it in thruth three seeds, for three different Fibonacci sequences? So the next values for the first sequence would be: 74, 90, 164, 254, 162, 160, 66, 226 etc.? And the second one: 72, 2, 74, 76, 150, 226, 120, 90 etc.? And the third one: 83, 183, 10, 193, 203, 140, 87, 227 etc.?

Or still somehow completely different?

Just out of pure interest: Could someone enlighten me how the seed actually works?

[Hoopy]

sorry - some confusion over the meaning of the word seed here.

In the texture generator the seed can by any 32bit integer (so there are 4 billion of them).

Oolite's seed for generating galaxies and planets is entirely separate.

I think the oolite it chooses a pair of numbers ot start from then uses the sequence to generate some more. So it doesn't always go 1,1,2,3,5,8 etc.

[TGHC]

It could be very simple, or excessively complicated. Generally, things that appear really simple are the ones that have the biggest difficulty implementing at the end.

Following the Greek tradition of philosophy I see!

[Commander McLane]

I think the oolite it chooses a pair of numbers ot start from then uses the sequence to generate some more. So it doesn't always go 1,1,2,3,5,8 etc.

As I wrote above, it does not apparently choose a pair of numbers, but six numbers, like for instance 74, 90, 72, 2, 83, 183 for Galaxy 1 (just look into any save-file from Galaxy 1, and you'll find it in the entry galaxy_seed). That's what my question was about. Perhaps I should post it again in a seperate thread, in order to catch everybody's attention.

The interesting thing for you is that these numbers (galaxy or system seed, I don't know) somehow govern the appearance of planets as well. Things like percent_land, cloud_rgb_colors and whatever you find in Planetinfo.plist is determined by the seed for all game-generated (= main) planets.

As far as scripted planets are concerned, there is the key seed, which can be inserted into the planet's entry. If it is there, this seed will be used instead of the default one in order to determine colours, cloudiness, land-and-water-ratio etc. Here's an example from Ghosts_from_the_past.oxp:

Code: Select all

    "ghosts_Bixein_planet_A" = {
        "atmosphere_rotational_velocity" = "0.04"; 
        orientation = "0.9659 0.2588 0 0"; 
        "percent_cloud" = 30; 
        "polar_color_factor" = "2.5"; 
        position = "3800000 0 -500000"; 
        radius = 5000; 
        "rotational_velocity" = "0.03"; 
        seed = "135 24 167 107 179 232"; 
        texture = "ghosts_planet_A.png"; 
    }; 

In this specific case the seed doesn't influence the planet's appearance very much, because the texture overrides any engine-generated colour-scheme.

But the bottom line for your procedural textures is: Every engine-generated and engine-coloured (original) planet already uses either the system- or a custom-seed. Procedurally generated textures could easily use the same seed(s) as well.

[Hoopy]

sorry, i see what you mean.

It's worthy of being it's own topic and then it should catch the eye of someone with the source code handy so they can tell us.

[Commander McLane]

Please have a look at the edited post again, there is also a suggestion as far as using the seed for procedural textures is concerned. You may have missed it, because I edited the post while you were writing your reply.

[Hoopy]

You're right - i could (should) use the same seed to define the texture. Makes sense if we're going to use the results of that seed to determine the colour, sea level etc.