Map Auto-Smoothing

[Steeveeo]

Well, after some trial and error with ODLWinter, I got my general map working.

The only problem is that, because heightmaps are generated from on a per-pixel basis, and 16-bit pngs refused to import properly, the entire map is really rough and the pixels really apparent sometimes (little square plateaus). Now, I could spend the time to run the height tool in Blend mode over the entire map, but the map is pretty much huge, so that is basically out of the question.

Is there a tool I have missed that can take a granulated map like this and smooth it out down to gentle hills instead of legos? (Preferably one that has a changeable strength/threshold/factor/whatever so that I can keep SOME roughness, just not squares ).

Thanks in advance!

[OvermindDL1]

That is because you are doing it in 8-bit, you *have* to use 16-bit grayscale png's if you want it to be smooth, 16-bit png's mean squat, they will still be 8-bit grayscale, it needs to be 16-bit grayscale.  Most image editing programs are crap when it comes to things that high quality, find a good one.

The issue with 8-bit grayscale is that it only allow for 256 'levels', whereas 16-bit grayscale allows for 65536 levels, which happens to be *exactly* what BZ2 uses for terrain, 65536 levels, hence when you use a 256 level version you are missing lots of data between the various level, 255 less per level to be exact, that is a lot.  The original winter only supported 8-bit, the only difference with mine is that it supports 16-bit (and I have added a few more things since...).  When importing an 8-bit grayscale file though, it will do it's best to scale it, meaning  that if you are not going to use all of those levels (you are not, the map would be freakishly tall, mountains so high you could not fathom it) then you tell it where the bottom of your 8-bit file is (generally 1000 or more is good, if you do it at zero then you cannot lower your map below that point, so more then 1000 is good as it gives you leeway in-case you wanted to edit your map any), as well as what the tallest point in your 8-bit grayscale image is and it will interpolate in-between, so, for example, if you only used 256 levels in your terrain (unlikely, although most maps generally do not use more then a few thousand so this still gives you vastly more data to work with) then it would be a perfect match.

If you post up (or email me) your png file you are working with, I can tell you instantly whether it is 16-bit, or 16-bit grayscale (16-bit's worth of colors is worthless for a terrain map, need 16-bit's worth of grayscale for a terrain map ).
Generated by OvermindDL1's Signature Auto-Add Script via GreaseMonkey

[Steeveeo]

I was using Photoshop...

I saved as 16-bit, and it refused to import to ODLWinter, tried switching modes (from grayscale to RGB), no effect, it refused to accept my 16-bit stuff.

Hence why I said this:

The only problem is that, because heightmaps are generated from on a per-pixel basis, and 16-bit pngs refused to import properly, the entire map is really rough and the pixels really apparent sometimes (little square plateaus).

NOTE: No I did not switch between modes on the exported PNG, I did it on the PSD (hitting undo if I had already changed modes).

(And I really didnt need the 90 page disertation on the difference between 8-bit and 16-bit, kinda already knew that )


Anyway, since I've already made progress on the map way past the initial heightmap, I do no want to have to regenerate the terrain and have to do it all over again, so I need some sort of auto-smoother, otherwise my map may just stick to being majorly rough...

[Nielk1]

Did you actually read it Steeveeo? The whole thing about 16 bit PNG != 16 bit gray-scale PNG was important.

[Steeveeo]

Did you actually read it Steeveeo? The whole thing about 16 bit PNG != 16 bit gray-scale PNG was important.

Did you read what I said?

No matter WHAT 16-bit mode I use (grayscale, RGB, CMYK, w/e), it does not import into ODLWinter!

[Nielk1]

Try another editor?

[mrtwosheds]

Try .bmp then (works for me), a simple blur function usually smooths things out nicely.

[Feared_1]

Try .bmp then (works for me), a simple blur function usually smooths things out nicely.

Why use PNG when there are other, easier, solutions?

[Nielk1]

Steeveeo told be BMP files cannot be 16 bit, I thought he was wrong but, eh.

[Steeveeo]

Steeveeo told be BMP files cannot be 16 bit, I thought he was wrong but, eh.

Photoshop wouldnt allow an already 16-bit mode set image to be saved as BMP, had to be an 8-bit for it to work.

[OvermindDL1]

BMP does not support 16-bit, there are 'unofficial' versions that do, but I do not support those.  And last I saw, Photoshop did not support 16-bit grayscale png's... although that was a few versions ago...

Edit:  Just checked.  Photoshop has "limited 16bps support", which does not include grayscale at all.  There is a plugin for PS called something like "SuperPNG" that adds 16bps color support, but I do not know about grayscale support.  I am pretty sure ImageMagick supports basn0g16 (png 16-bit grayscale in other words, the technical term for it) just fine.  I think my app also supported 16-bit grayscale tiff's whether the open box says it can or not (try forcing it, do not use any compression in the tiff to be on the safe-side though)...
Generated by OvermindDL1's Signature Auto-Add Script via GreaseMonkey

[BNG Da BZ Fool]

Is ODLWinter any easier to use over the original Winter? I made a few .trn files, but must not understand how it works as I got mixed results when I load the .bzn file into the map editor. Most of them where I ended up with huge canyon like terrain and vast flat areas, but very little in the way any kind of sloping terrain. It just seems easier to do it all with the tools already included with the map editor itself.

[GreenHeart]

The ODLWinter is better & has more support since bz2 uses 16 bit images not 8bit so techinally the orginal winter program downgraded things.  Also ODLWinter has a 3D render view that is close enough to give you an idea of what it will be in bz2 but not totally on target with the height.

[OvermindDL1]

Yea, never did figure out the exact height scaling value that BZ2 uses, it is not the same scale that the X and Y axis are, but yea, as stated, it is close enough for a quick idea.
Generated by OvermindDL1's Signature Auto-Add Script via GreaseMonkey

[BNG Da BZ Fool]

Can I dl it at OM's forum?