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: http://community.simtropolis.com/files/file/31831-mons-lacus-map/ (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.

-Cori
 
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;

to

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?

-Cori
 

Return to topic list



New message:
Topic:
Posted by:

Type the values of the dice shown below:

Return to topic list