Sunday, December 7, 2014

An added random thought on perlin noise and heightmap design

Even if say gray scale encoding on 32 bit for color with 8 bits per channel RGB,  you technically have an image that is nearly 8 bits in resolution for heightmap (if you know any thing about RGB for greyscale, you find that any greyscale color variation is given by the same value per channel which effectively reduces channel resolution from 24 bits to 8 bits and then alpha channel doesn't extend the range of color value points but merely re scales the entire range so one can neglect this for greyscale images in terms of effectively improving image resolution), or incrementally speaking you have a variation of some 256 possible height positions which outside of smoothing methods when loading a height map is likely going to be appear having more obvious step discontinuities from pixel to pixel if your overall maximum height ceiling includes a variation range well beyond 256 discrete values.  Often why I've seen even with more sophisticated terrain management systems loading 8 bit images that look highly pixelated.  There maybe some clever code algorithms that take a non greyscale image and use a color processing algorithm on the other hand for provisioning heightmap data, for instance, one channel representing a given range modulus band of possible heightmap values say within 256 values and so forth, or not so different from say a 16 bit raw encoding process but using a given color channel to do this.  You'd just need to provision the read write coding on this and figure out the modulus arithmetic to extend to say 16 bit or 24 bit data ranges.

Thus I'd likely recommend something like 16 bit raw or of a preferred image format if you need save this image data to a grey scale height map.

Otherwise, if you can access (as I've posted previously) a given terrain management system, likely you can modify heightmap data directly without having need to translate this specifically to grey scale heightmap for loading.  


Coming back to some thoughts above:

here's a simple encode/decode recipe for a 32 bit rgba image.

Given that each pixel can be represented by 256 different values per channel means that potentially a representation per pixel has up to 256^4 or 4,294,967,296 different values this means that one could have potentially on any given loaded terrain over 4 billion height map values, or easily this should smoothly represent a desired terrain by use of the encoding/decoding process.  So here goes the explanation for encoding:

Each channel is given in such process a corresponding modulus representation to a given power.

Thus in one example encoding scheme,

The R ed channel is given to representing n from 0...255
The G reen channel represents positions 0...255*(256)
The B lue channel represents positions 0...255*(256^2)
and finally
The Alpha channel represents positions 0...255*(256^3)

The encoding process then looks like this:

R+G+B+A represents the given numeric position from 0...4,294,967,295
Example:
Represent in RGBA
4,194,940,295
Thus we divide by the Alpha channel 256^3 which gives 250.037926137 we take the floor of this value A = 250 and hold the remainder .037926137

hold the remainder y.

next we take y = .037926137 and multiply by 256 which gives 9.709091072 take the floor B = 9 and hold the remainder which is .709091072

multiply this remainder by 256 which gives 181.527314432 take the floor G = 181 and hold the remainder which .527314432

multiply this remainder by 256 which gives 134.992494592 take the floor/roundup which is R = 135


And the decoding

So (134,181,9,250) then is given by

135+256*181+256^2*9+256^3*250 = 4,194,940,295 as we can see the number is returned.

Obviously if you want insanely high precision data encoding/reading processes this could be, for instance, a way to go!

Here's an example encode rendering


No comments:

Post a Comment

Oblivion

 Between the fascination of an upcoming pandemic ridden college football season, Taylor Swift, and Kim Kardashian, wildfires, crazier weathe...