Author Topic: Heightmap Generator  (Read 9444 times)

yeah i'm pretty sure that was a terrain-specific feature, and since reading pixel colors takes a super long time for a whole image and ts can't read binary data, i think the only practical solution would be to convert images into a compatible text format. or have an external server process the data and send it back
I definitely want to look into writing a program to convert between text and image-based heightmaps. I'm not sure how difficult that would be though.

So... What is this supposed to be used for? I've re-read the description several times
and from what i can tell, all this addon does is generate a fancy image, and doesn't
do anything else.

Now, i'm sure these images can be useful to some people, but this addon is pretty
much useless to anyone who isn't a coding wizard, mainly because it doesn't add
anything to the actual game, no bricks, no events (VCE included), no emitters,
no in-game functionality, nothing.

If anything, this would've been better off as a standalone application, there was no
need to make an addon out of it.

it could be useful if you want to generate a map, but more importantly, the fact that these things are working entirely within blockland shows that further add-ons which build upon this functionality can be made. terrain generators are nothing new (even if easily used ones are harder to come by), but the idea of being able to import/export heightmaps entirely within blockland has exciting potential if it can be effectively put to use. most people aren't going to actually use this for anything, but it shows progress in procedural generation that is meaningful. it's also a useful interface for being able to test and experiment with generation before executing the drawn-out process of actually building it out with bricks
Ott-san's response pretty much summed up what it can be used for. One of the reasons I posted this was to gauge the usefulness for this type of add-on. Most users probably won't get much use out of it other than being able to experiment with and learn about procedural noise. However, heightmaps can be used for countless things, especially in regards to generating landscapes. Also, I'm hoping to add support for importing heightmaps to PTG and possibly another add-on, which will make this tool very useful in the near future.

If someone can write a program to convert between text and image-based heightmaps, it could also lead to countless possibilities both within and outside of Blockland - such as being able to use noise to create print textures for bricks.

how hard is it to implement new noise generators? for instance, i've written a working 2D simplex noise generator in blockland in the past, but how much additional code would be necessary to implement it here?
Most of the GUI options only affect what is input or output from the algorithms, so it should be fairly easy to add support for Simplex Noise and other types of noise. I might not be able to get all of the features to work (like the options for incrementation, smoothing, etc.), but everything should be easy to incorporate - it might only require adding one additional function per new noise type.

Most of the GUI options only affect what is input or output from the algorithms, so it should be fairly easy to add support for Simplex Noise and other types of noise. I might not be able to get all of the features to work (like the options for incrementation, smoothing, etc.), but everything should be easy to incorporate - it might only require adding one additional function per new noise type.
nice. since simplex produces noise very similar to perlin, you can pretty much use all the same kinds operations as with perlin to generate terrain. the code is old and could probably be improved, but for my implementation, i just used common perlin generator processes and it worked pretty well

How would the height map text display?

nice. since simplex produces noise very similar to perlin, you can pretty much use all the same kinds operations as with perlin to generate terrain. the code is old and could probably be improved, but for my implementation, i just used common perlin generator processes and it worked pretty well
Great, I'll look into adding Simplex Noise. First I need to figure out how it works though lol.

How would the height map text display?
When saved, it sets the grid size at the top line, then leaves an empty line and adds the height values (as float values between 0 and 1) below that - relative to the grid size:
Code: [Select]
16 x 16
 
0.308571 0.205714 0.205714 0.171429 0.342857 0.4 0.285714 0.32 0.331429 0.228571 0.297143 0.285714 0.125714 0.171429 0.251429 0.182857
0.365714 0.194286 0.217143 0.297143 0.377143 0.434286 0.388571 0.342857 0.32 0.217143 0.137143 0.171429 0.182857 0.205714 0.308571 0.297143
...


i could probably write a heightmap to brick converter at some point if one doesnt exist

i could probably write a heightmap to brick converter at some point if one doesnt exist
That would be great. Also, support for text-based heightmaps could easily be added to Simplex Gen in the near future, if it would be a useful feature.

How good would it be to use .tsv or .csv files by any chance?

If someone can write a program to convert image maps to text-based maps (or the other way around), it could prove to be very useful. I might look into this myself; it would be a good reason to learn a raw scripting language - like Python, c# or c++. This would also allow for recreating old terrain maps with bricks.
I definitely want to look into writing a program to convert between text and image-based heightmaps. I'm not sure how difficult that would be though.
just saw this, it doesn't sound too difficult
you just want a program to read an input file (.png?), and output its color as text (.csv? or just numbers separated by spaces?)

if you let me know what the input and output are/should be, I can create something quickly in java
(ie, if it's a black, white, yellow pixel as input, should it output as "0 255 170" on a line?)
« Last Edit: July 04, 2017, 12:21:00 PM by phflack »

reading a png or other compressed format would require a ton of specific byte reading and other bullstuff. the best bet would probably be an uncompressed bitmap reader

reading a png or other compressed format would require a ton of specific byte reading and other bullstuff. the best bet would probably be an uncompressed bitmap reader
no its the same as reading dsos you nerd lol
you read the file header then you read by chunks, reading by the length specified in the 4 bytes at the start of each chunk, then comparing the data that you read with the crc thats included in the format
its not hard lmao why do you want to use a uncompressed bitmap when its equally as difficult to read
https://en.wikipedia.org/wiki/Portable_Network_Graphics#File_header

How good would it be to use .tsv or .csv files by any chance?
I'm not too familiar with those types of files, does the engine support them?

just saw this, it doesn't sound too difficult
you just want a program to read an input file (.png?), and output its color as text (.csv? or just numbers separated by spaces?)

if you let me know what the input and output are/should be, I can create something quickly in java
(ie, if it's a black, white, yellow pixel as input, should it output as "0 255 170" on a line?)
Yes, it would need to read an image and export it as float values (between 0 and 1) within a text file; the value itself would be based on the greyscale value (i.e. 128 128 128 255 would be 0.5, or 128 / 255). Here is an example of how the heightmap generator saves a heightmap (it saves the grid size first at the top of the file):

Code: [Select]
16 x 16
 
0.308571 0.205714 0.205714 0.171429 0.342857 0.4 0.285714 0.32 0.331429 0.228571 0.297143 0.285714 0.125714 0.171429 0.251429 0.182857
0.365714 0.194286 0.217143 0.297143 0.377143 0.434286 0.388571 0.342857 0.32 0.217143 0.137143 0.171429 0.182857 0.205714 0.308571 0.297143
...

It would also be useful if the script can convert a .txt heightmap save into an image, relative to the grid size for the image. It would basically just take one of those float values, multiply it by 255 and use the result for the RGB value (i.e. 0.1 would result in 25 25 25 255, 0.5 would be 128 128 128 255, and 1 would be 255 255 255 255).

no its the same as reading dsos you nerd lol
you read the file header then you read by chunks, reading by the length specified in the 4 bytes at the start of each chunk, then comparing the data that you read with the crc thats included in the format
its not hard lmao why do you want to use a uncompressed bitmap when its equally as difficult to read
https://en.wikipedia.org/wiki/Portable_Network_Graphics#File_header
i dont know what any of this means. laymans terms

no its the same as reading dsos you nerd lol
you read the file header then you read by chunks, reading by the length specified in the 4 bytes at the start of each chunk, then comparing the data that you read with the crc thats included in the format
its not hard lmao why do you want to use a uncompressed bitmap when its equally as difficult to read
https://en.wikipedia.org/wiki/Portable_Network_Graphics#File_header

no you just use a library to read a png like everyone else

no you just use a library to read a png like everyone else
forget no id rather make my own library for that stuff lol

I'm not too familiar with those types of files, does the engine support them?
Yes, it would need to read an image and export it as float values (between 0 and 1) within a text file; the value itself would be based on the greyscale value (i.e. 128 128 128 255 would be 0.5, or 128 / 255). Here is an example of how the heightmap generator saves a heightmap (it saves the grid size first at the top of the file):

Code: [Select]
16 x 16
 
0.308571 0.205714 0.205714 0.171429 0.342857 0.4 0.285714 0.32 0.331429 0.228571 0.297143 0.285714 0.125714 0.171429 0.251429 0.182857
0.365714 0.194286 0.217143 0.297143 0.377143 0.434286 0.388571 0.342857 0.32 0.217143 0.137143 0.171429 0.182857 0.205714 0.308571 0.297143
...

It would also be useful if the script can convert a .txt heightmap save into an image, relative to the grid size for the image. It would basically just take one of those float values, multiply it by 255 and use the result for the RGB value (i.e. 0.1 would result in 25 25 25 255, 0.5 would be 128 128 128 255, and 1 would be 255 255 255 255).
the engine doesnt technically support it but the files are really simple to write out so just write your own library to write it out following the file format
« Last Edit: July 05, 2017, 12:19:51 AM by Metario »