Planettool 0.4.2 released

[Cmd. Cheyd]

Cmd. Cheyd quietly waits and prays for the Windows version... Or a Photoshop script... Or Plug-in... Or...

[JensAyton]

Cmd. Cheyd quietly waits and prays for the Windows version... Or a Photoshop script... Or Plug-in... Or...

What I said above is absolutely true: I wrote the graphical version because it was easier than writing a comprehensible guide to installing and using command a line tool. It took a few hours of coding on Sunday evening, and another hour or so of polishing spread out over several days. The Windows and Linux programmers in the audience are welcome to take this as a challenge. I’ve already made it easier for them by refactoring the core code (which is vanilla C) to be more embeddable. ;-)

In the mean time, here’s some slightly better documentation.

[another_commander]

Planettool 0.4.2 for Windows (command-line interface only) is now available from GURPO.

[Getafix]

Planettool 0.4.2 for Linux x86 and x86_64 (command-line interface only) is now available from GURPO.

[Griff]

does the texture size power of two rule apply to cube maps? i've used this program to convert some 1024x512 'latlong' maps and the resulting cube map comes out as 512 x 3072. Do i need to resize this now to 512x2048 or will Oolite/openGl deal with this map as 6 512x512 tiles?

[JensAyton]

does the texture size power of two rule apply to cube maps? i've used this program to convert some 1024x512 'latlong' maps and the resulting cube map comes out as 512 x 3072. Do i need to resize this now to 512x2048 or will Oolite/openGl deal with this map as 6 512x512 tiles?

Each face of the cube must be a power-of-two square, so the height will always be 1.5 times a power of two.

[JensAyton]

This week’s XKCD What If? corresponds to -R 0 0 -90. Here it is (click for biggerness):

[Cody]

London sits in a steamy jungle straddling the equator, with a climate generally resembling Manila's. The food is still bland, the Thames is full of piranha, and it's the only place on Earth where tigers apologize as they attack you.

<chortles>

[submersible]

I've been meaning to look at the source for planettool to see if I can devise a normal map generator for cube maps. I noticed that the Oolite planet texture generator builds a normal map by sampling a noise map (lat-long) . For me - building a useful normal map for use on a spherical object from latlong or cube maps has been devilishly hard with current tools. The GIMP normal map extension is OK - but it is planar centric.

[JensAyton]

I've been meaning to look at the source for planettool to see if I can devise a normal map generator for cube maps. I noticed that the Oolite planet texture generator builds a normal map by sampling a noise map (lat-long) . For me - building a useful normal map for use on a spherical object from latlong or cube maps has been devilishly hard with current tools. The GIMP normal map extension is OK - but it is planar centric.

The architecture isn’t very well suited to that. You could quite easily make a filter (a “source”, in planettool terms, that reads from another source, like MatrixTransformer does), but the renderers (“sinks”) perform Gaussian weighted filtering that doesn’t necessarily make sense for normals.

That said, here’s what you need to know to try it:

• All rendering is done in linear floating-point RGB, and written as (slightly fake) sRGB. The gamma remapping isn’t desirable for normal maps, so you’d want to change the driver (main.c) such that normal-mapping modes produce linear output. This involves passing kFPMGammaLinear instead of kFPMGammaSRGB to FPMWritePNG.
• The basic operation of the tool works by connecting a pixel “source” to a pixel “sink”. Two of the existing sources, MatrixTransformer and CosineBlurFilter, wrap other sources and apply effects. This should be the template for your normal mapper.
• To read a gradient, you’ll want to sample from some offset in each direction, which will look something like this:

Code: Select all

FPMColor HeightMapToNormalMapFilter(Coordinates where, RenderFlags flags, void *context)
{
    HeightMapToNormalMapFilterContext *cx = context;
    
    // Read input coordinates, possibly converting from vector to latitude/longitude.
    float lat, lon;
    CoordsGetLatLongRad(where, &lat, &lon);
    
    // Offset coordinates northward by some angle, presumably specified at command
    // line and defaulted to something sensible based on size.
    Coordinates northOffsetCoords = MakeCoordsLatLongRad(lat + cx->offset, lon);
    FPColor northSample = cx->source(northOffsetCoords, flags, cx->sourceContext);
    
    // Three more samples here...
    
    // ...Then calculate normal from gradients.
}

[Cmd. Cheyd]

Any chance of getting the bug I reported last year (or was it the year before that?) fixed?

[JensAyton]

Any chance of getting the bug I reported last year (or was it the year before that?) fixed?

Which one would that be? There aren’t any tickets for planettool in the bug tracker.

[Cmd. Cheyd]

https://bb.oolite.space/viewtopic.php?f=3&t=8361

And as the post said, I did submit it via Berlios...

[JensAyton]

Ah, I didn’t find it in the tracker because it was fixed over a year ago. :-) We should probably post a new release soon, but I have some other things to fix first.

[submersible]

Just while I think of it - is there any hope for fixing this known issue...

While it can read from cube maps, it fails at the edges of faces and produces artefacts. This does not affect writing cube maps.

I'm noticing this going from a cube to a cubex