Planet textures using libnoise

Post by **dajt** » Fri Jul 28, 2006 7:29 am

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.

Rxke · Post by **Rxke** » Fri Jul 28, 2006 7:42 am

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?

Post by **dajt** » Fri Jul 28, 2006 7:46 am

Rxke wrote:
What would be the advantages? More detail?

Look at the examples on the libnoise pages...

Rxke · Post by **Rxke** » Fri Jul 28, 2006 7:49 am

Ah

of course, RTFM, eh?

Hmmm... Perlin noise and fractalisation *drools*

drew · Post by **drew** » Fri Jul 28, 2006 9:05 am

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

Cheers,

Drew.

aegidian · Post by **aegidian** » Fri Jul 28, 2006 9:33 am

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.

Post by **dajt** » Fri Jul 28, 2006 9:40 am

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.

Wolfwood · Post by **Wolfwood** » Fri Jul 28, 2006 9:48 am

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"...

aegidian · Post by **aegidian** » Fri Jul 28, 2006 10:05 am

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.

Post by **dajt** » Fri Jul 28, 2006 11:53 am

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.

JensAyton · Post by **JensAyton** » Fri Jul 28, 2006 2:06 pm

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 · Post by **magamo** » Fri Jul 28, 2006 3:48 pm

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)

aegidian · Post by **aegidian** » Fri Jul 28, 2006 6:38 pm

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).

Post by **dajt** » Fri Jul 28, 2006 9:15 pm

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.

JensAyton · Post by **JensAyton** » Sat Jul 29, 2006 12:04 am

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++).