First row of pixels (Square mode)

First row of pixels (Square mode)

Return to topic list

Tue Jun 20 19:25:26 2017   by   Codie Morgan
High. I am only using it to generate textures as Square.

(I have tested this on both the web app as well as via the wrapper GUI I have created for planet.exe in C#).

When generating Square texture and using perfect divisible by two dimensions (eg: 512X256) the first row of pixels in generated image is always white.

The only way to avoid a first row of white pixels seems to be to generate with a non-divisible-by-two height (odd number).

I consider this to be a bug - thus I am reporting this here.

I am using this tool to create height textures for  a game on the fly - but "on the fly" is no longer applicable if I have to manually either fix the first row manually or resize a non DivisableByTwo image into a divisible by two result (required for MipMaps to be generated successfully).

Also - it would be interesting/useful if the tool could also output Tangent Space Normal Bump Maps as a secondary output file (not important as this is calculated directly in my shader).
Wed Jun 21 09:53:40 2017   by   Torben
It does indeed sound like a bug.  I will look into it.
Mon Jul 17 08:32:15 2017   by   CorinaMarie
Hiya, Torben.

Lovely program! It's just perfect for creating grayscale height maps for rendering in SimCity 4. Sample here if you are curious: (I now tweak the initial altitude setting of your program to make sea level match up with what the game expects rather than adjust the gamma like I did in that sample. Also I was only using your online version at the time.)

I have run into a similar situation as Codie Morgan inasmuch as the top row will be all white in some cases. Oddly, mine's not when the Height % 2 = 0. Here's sample tests:

Planet.Exe -X -pq -s 0.14937910 -m 2.0 -i -0.053 -C greyscale.col -w 1025 -h 1025 -o MapGray1.bmp
Planet.Exe -X -pq -s 0.14937910 -m 2.0 -i -0.053 -C greyscale.col -w 1025 -h 1024 -o MapGray2.bmp
Planet.Exe -X -pq -s 0.14937910 -m 2.0 -i -0.053 -C greyscale.col -w 1024 -h 1025 -o MapGray3.bmp
Planet.Exe -X -pq -s 0.14937910 -m 2.0 -i -0.053 -C greyscale.col -w 1024 -h 1024 -o MapGray4.bmp

Maps 1, 3 & 4 show the white row and map 2 does not.

Looking at the code in the squarep() section there is: for (j = 0; j < Height; j++) and then the other stuff it does while in that loop. I don't know the language but it seems like we are doing stuff until j is not less than the height which might exit the loop one iteration too soon. However, if this were the problem I'd expect the white row to happen regardless of the height specified.

So, as you can see I'm confuzzled by it and I prolly don't know what I'm talking about codewise, but if you could look into it I'd love to learn what the culprit is and how it can be fixed.

Sat Aug 5 04:08:14 2017   by   CorinaMarie
Hiya. It's me again. I've had some time to learn about C and here's my most recent discovery. If I change this line in the squarep() section:

y = (2.0*(j-k)-Height)/Width/scale*PI;


y = (2.0*(j-k)-Height+1)/Width/scale*PI;

then running the same test as above maps 1, 2 & 4 do not have the blank white (background color) top row, but map 3 still does.

Since my needs are for perfectly square maps, this removes the quirk for me. Ofc, it's still not the perfect overall solution. Prolly need an IF check for Width < Height and then don't add the +1. And/or check if it's only when Width is one less than Height?

Fri Jan 26 14:28:00 2018   by   Torben
I have now fixed this error.  Note that a 10241025 map at magnification 2 will still give a blank top row.  This is because the distance from pole to pole is only 1024 pixels, so the top line of pixels is outside the map, similar to how half the lines are outside the map if you make a 10241024 map with magnification 1.

I also fixed an error in the sinusoidal projection that made zooming useless.

Return to topic list

New message:
Posted by:

Type the values of the dice shown below:

Return to topic list