Planet textures using libnoise

An area for discussing new ideas and additions to Oolite.

Moderators: another_commander, winston

dajt
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 365
Joined: Tue Aug 17, 2004 7:05 am
Location: Orange, NSW, Australia
Contact:

Planet textures using libnoise

Post by dajt »

Hi all,

I thought I'd play with planet texturing and have hacked up a demo using libnoise to generate the texture (link below to screenshot).

Lave

There are some major problems with this at present, the worst being that libnoise is C++ and the GCC used by GNUstep will not link against a C++ library. Also, libnoise as it comes only compiles down to a static library, not a DLL, and I don't know enough about MinGW or C++ to know how to sort this out, if it ends up being important.

At the moment, the hack passed the Random_Seed values to an external libnoise based program which generates a texture image file, whose name is then inserted into the planetinfo dictionary texture entry (don't anyone tell me how awful this is, I already know ;)

The program doesn't yet generate different images based on the Random_Seed values. I have to experiment with libnoise to find out what parameters can be changed to modify the heightmaps generated so different continents appear. I already know how to change the colour scale, so that is "just" a matter of coming up with a way of mapping the random values to colour ranges so they look good.

I've been looking and GCC 4.1 can do Objective-C++, so if I can build that on Windows and swap out the entire GNUstep compiler/runtime system, this would be an option, but is not likely to happen.

An alternative is to keep writing to disk and have some least-recently-used algorithm keep cleaning the cache out so we don't end up with all planet's textures on disk. For example, you're not likely to need images for planets in other galaxies.
Last edited by dajt on Fri Jul 28, 2006 7:45 am, edited 1 time in total.
Regards,
David Taylor.

User avatar
Rxke
Retired Assassin
Retired Assassin
Posts: 1743
Joined: Thu Aug 12, 2004 4:54 pm
Location: Belgium

Post by Rxke »

On my computer, the screenshot is too dim to really tell what's different from Oolite's default planet-texturing...

What would be the advantages? More detail?

dajt
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 365
Joined: Tue Aug 17, 2004 7:05 am
Location: Orange, NSW, Australia
Contact:

Post by dajt »

Rxke wrote:What would be the advantages? More detail?
Look at the examples on the libnoise pages...
Regards,
David Taylor.

User avatar
Rxke
Retired Assassin
Retired Assassin
Posts: 1743
Joined: Thu Aug 12, 2004 4:54 pm
Location: Belgium

Post by Rxke »

Ah :oops: of course, RTFM, eh? :lol:

Hmmm... Perlin noise and fractalisation *drools*

User avatar
drew
---- E L I T E ----
---- E L I T E ----
Posts: 2186
Joined: Fri May 19, 2006 9:29 am
Location: In front of a laptop writing a book.
Contact:

Post by drew »

That looks ..er.. hoopy! Wouldn't mind seeing a planet with those kinds of detail. Very nice.

Cheers,

Drew.
Author of the Oolite Saga, the officially licensed Elite: Reclamation and Elite Dangerous: Premonition
WebsiteFacebookTwitter

User avatar
aegidian
Master and Commander
Master and Commander
Posts: 1152
Joined: Thu May 20, 2004 10:46 pm
Location: London UK
Contact:

Post by aegidian »

Cool idea. If nothing else looking at the source and implementing some simple Perlin noise generators for textures (essentially doing tutorial 2) is feasible.

Moving to GCC 4 would also be a good idea, it's used to build the Mac binaries already, so it's really just a case of how well it sits with SDL and GNUstep.
"The planet Rear is scourged by well-intentioned OXZs."

Oolite models and gear? click here!

dajt
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 365
Joined: Tue Aug 17, 2004 7:05 am
Location: Orange, NSW, Australia
Contact:

Post by dajt »

I've downloaded the GCC 4.1 source and I'll see if it builds under the current GNUstep compiler.

I don't think recompiling GNUstep or SDL would be a problem with it, but hopefully we won't have to.
Regards,
David Taylor.

User avatar
Wolfwood
---- E L I T E ----
---- E L I T E ----
Posts: 734
Joined: Wed Mar 29, 2006 9:53 am
Location: Finland
Contact:

Post by Wolfwood »

Aah! Those examples are _pretty_! Me wants!

Then, all we need is planetary landings, or at least atmospheric flight... And ships marked down with various stats according to their atmospheric flight capabilities... and...

As they say in Finland "hunger grows while you eat"...
Author of Tales from the Frontier - official Elite 4 anthology.
Author of Marcan Rayger adventures - unofficial fan-fic novellas set in the Frontier universe.

User avatar
aegidian
Master and Commander
Master and Commander
Posts: 1152
Joined: Thu May 20, 2004 10:46 pm
Location: London UK
Contact:

Post by aegidian »

Plus:

I'm pretty hacky with some code - look at the the way the 'blur' texture is handled for example - it should be possible to inject the noise directly into a texture using something similar.
"The planet Rear is scourged by well-intentioned OXZs."

Oolite models and gear? click here!

dajt
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 365
Joined: Tue Aug 17, 2004 7:05 am
Location: Orange, NSW, Australia
Contact:

Post by dajt »

GCC 4.1 wouldn't build with the toolchain that comes with GNUstep, so that was a bad start. I'll try compiling GCC 4.1 under MinGW current over the weekend, but I can't say I'm optimistic about it.

I did get Obj-C calling a C++ lib while doing the unicode stuff (FTGL is a C++ library), but I've lost the little project used to create the C wrapper and can no longer remember how I did it... I may have posted some useful information to the oolite-dev list, but my ISP has removed all my older messages.

Anyway, I changed the generator program to create a seed based on the given Random_Seed so all the planets have different geography now, but the colours are all wrong - rust red and dark greens, etc. Not sure what's going on there - that isn't what is in the generated texture.

I'm going to spend some time trying to get the textures rendering with the correct colours on a sphere in a simple program, and if I can get that to go I'll have a go at a cloud layer.

Then I can revisit the Oolite code and try to see where the weird colouring is coming from.
Regards,
David Taylor.

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Building gcc 4.1 is nontrivial. I tried for the command-line version of Dry Dock. Still haven’t got anywhere with that. (In the latest attemt, booting my old iMac from an xubuntu livecd, it goes to sleep around when X should be starting up and won’t wake up. Whee.)

No version of gcc should have a problem linking a project which has C++ files and ObjC files that don’t interact directly. To bridge them, you do something like this (warning, Mac OS-like coding conventions):

Code: Select all

// FooBridge.h

#ifdef __cplusplus
class Foo;
typedef Foo *FooRef;
extern "C" {
#else
typedef struct Foo *FooRef;
#endif

FooRef CreateFoo(void);
void DeleteFoo(FooRef inFoo);

void FooSetThing(FooRef inFoo, int inThing);
int FooGetThing(FooRef inFoo);

#ifdef __cplusplus
}
#endif


// FooBridge.cp

#include "FooBridge.h"
#include "Foo.h"


FooRef CreateFoo(void)
{
    return new(nothrow) Foo;
}


void DeleteFoo(FooRef inFoo)
{
    if (inFoo) delete inFoo;
}


void FooSetThing(FooRef inFoo, int inThing)
{
    if (inFoo) inFoo->SetThing(inThing);
}


int FooGetThing(FooRef inFoo)
{
    int result = 0;
    if (inFoo) result = inFoo->GetThing();
    return result;
}
FooBridge.h can then be used from any C or Objective-C file.

magamo
Competent
Competent
Posts: 45
Joined: Sat Feb 25, 2006 7:07 pm

Post by magamo »

My question about this one: What kind of performance hit would we be looking at to procedurally generate this on the fly? Would it be trivial to add in LODs and perhaps a switch to use the current system? (At the very least until atmospheric flight/planetary landings are in the works, when having that type of detail would be an absolute necessity)

I ask because I'm running Oolite on a PIII/850 (It was a 600 until yesterday!) and at 640x480, it runs smooth as silk (until something big blows up)

User avatar
aegidian
Master and Commander
Master and Commander
Posts: 1152
Joined: Thu May 20, 2004 10:46 pm
Location: London UK
Contact:

Post by aegidian »

magamo wrote:My question about this one: What kind of performance hit would we be looking at to procedurally generate this on the fly?
Prolly no more than the current hit when we generate a planet (which are currently coloured - rather than textured - procedurally).
"The planet Rear is scourged by well-intentioned OXZs."

Oolite models and gear? click here!

dajt
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 365
Joined: Tue Aug 17, 2004 7:05 am
Location: Orange, NSW, Australia
Contact:

Post by dajt »

Ahruman,

I'm pretty sure I had simpler code than that for linking to FTGL... Perhaps coming back to me now...

I think I was able to do it because FTGL is a DLL, then writing a little C library that called it. Because the C++ was in a DLL, the GNUstep version of the linker didn't have to try and understand it.

The C++ DLL and C library stub was compiled using a different installation of mingw, which did have the C++ compiler/runtime in it.

The GNUstep compiler/runtime only has support for C and Obj-C - which is why it can't link to the static libnoise library, which is C++.

So perhaps I can make a "custom" DLL out of libnoise, not exposing any of the actual libnoise code but just C stubs that call it.
Regards,
David Taylor.

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

The only alternative I can think of to wrapping like this is to use the mangled symbols directly, which is possible but horrible (and I really don’t feel like going into it). Building the wrapper into a DLL sounds feasible. The fact that the GNUstep compiler flavour doesn’t support C++ sounds perverse and dogmatic, but maybe that’s just me; building gcc with both ObjC and C++ support shouldn’t be much harder than building it with just one of the two (and is different from supporting ObjC++).

Post Reply