Sign in to follow this  
ownerpure5

Request to Modders and Programmers

Recommended Posts

Only if someone writes the 16b grayscale image importer for Wurm API and the terrain generator saves to 16b grayscale. 


 


The percent of WURM players that are WURM mapmakers that would use 'World Generator' or any other terrain generator does not merit those non Wurm tools adding code for Wurm API or Wurm .map format.  My point is that you do not need to wait for a WURM code to write a WURM generator because there are many terrain generators that save 16 grayscale heightmaps. (You do need one capable of making an island)

Share this post


Link to post
Share on other sites

. I'm also more interested in math and computing concepts then learning about how specific tools.

 

Then write a 16b grayscale image generator using Python.  I am using Matlab.  Certainly both languages have libraries that support 16b greyscale image saving...My entire point here is that not everyone needs to write Wurm Java code as long as one person writes that 16b grayscale height map image based importer (looks like 16b grayscale PNG, TIFF and RAW are the image formats to support) because that opens up map development to paint programs, terrain generators and other languages.  I have no doubt Warlander could do this importer in his sleep, but I get the impression he is not sleeping so he is passing on doing it.

 

Don't waste time on 8b interpolations - there is a tremendous amount of information missing in that 256 dirt cube that those extra 8b represents.  Just imagine a deed cutout that big, then filling in the blanks not having any of the details.   As soon as you do it you will realize that was a waste of time better spent on figuring out a 16b grayscale.workflow.  Even if you had a very good fractal noisy interpolator to fill in the blanks so that it does not look bowling ball smooth nor unwalkable spiky terrain, you could never import a terraformed terrain (like the roads and building plots in Elder Scroll maps) and recover those details using an 8b image.

 

If you want 16b grayscale map sources - the NOAA site I linked earlier uses GEOTIFF which is TIFF with extra GEO extensions, but the format claims backward compatiblity with any TIFF reader which is most paint programs.  Lots of isles on earth that you can rip.  Or you can save from NOAA a straightforward binary file or text file which should be easy to read in Java extending the simple example Warlander gave learning only enough Java to figure out how to read a straight forward file dump.

 

Here is an Elderscrolls map (ESM) exporter - 16b RAW grayscale format files like many of the terrain generator use.  You probably cannot find anyone that posted the image files because Bethesda likes to crack down on that.  But with the exporter as long as you own the game you can make the image maps for personal use.

 

http://www.oceanlightwave.com/morrowind/TESAnnwyn.html

Edited by yarnevk

Share this post


Link to post
Share on other sites

These 16b "greyscale" images are not actually grey.  They are borrowing the image file format to store data, there are only 256 level of grey.  If you view them with a normal picture viewer they look like this:


Tamriel16th-overview.jpg

Share this post


Link to post
Share on other sites
You could indeed use three 8b color channels to pack in 16b heightmap with a simple binary math transform , that is much more complex workflow because tools have to agree on which color is the high byte and low byte by convention because this is not something indicated in the format itself.  It is why the majority of terrain and game engines use actual single channel 16b grayscale files to avoid those format disagreements of is it 256*Red + Green or 256*Green + Red, or does it mix Blue and Alpha in as well to increase height maps to 24b or even 32b precision.   Or is it 256*Alpha*(Red=Green=Blue) so that it displays in any 8b program as grayscale then the image reader just knows to read the Alpha to get the high byte.     

 

Which is what looks like what happened in your viewer it is confused and is not display the high byte of your terrain.  Real terrain does not cycle from low to high like that, what you are seeing is only the low byte.

 

Of course if you want to write such an RGBA grayscale importer have at it and let me know when you cover all the possible variants without confusing the user who will have no clue exactly which variant they have.

 

That type of map is also not easy to easy edit compared to using a paint and terrain workflow that supports the actual 16b grayscale file formats.

 

From libpng.org

 


PNG grayscale images support the widest range of pixel depths of any image type. Depths of 1, 2, 4, 8, and 16 bits are supported, covering everything from simple black-and-white scans to full-depth medical and raw astronomical images.


 Calibrated astronomical image data is usually stored as 32-bit or 64-bit floating-point values, and some raw data is represented as 32-bit integers. Neither format is directly supported by PNG, although one could, in principle, design an ancillary chunk to hold the proper conversion information. Conversion of data with more than 16 bits of dynamic range would be a lossy transformation, however--at least, barring the abuse of PNG's alpha channel or RGB capabilities.


 

 

So you can see even the PNG standard is saying you could pack grayscale across RGBA channels, that is 'abuse' not defined by the format itself.  So you can see older formats like BMP that never supported 16b grayscale are indeed possible to have people 'abuse' the format packing it across RGBA, but there is no standard way of doing so. 

Edited by yarnevk

Share this post


Link to post
Share on other sites

Again, they're using the image format (RGBA) for non-image data.  It's just semantics.  If they're not saving all four channels then it's not an image.  A greyscale image is one where the R, G, and B values are the same for each pixel.  Waste of space, especially if it's 16bits per channel.


 


Do you have a source for downloading heightmaps in 16bit greyscale format?  Everything I've found is in standard RGB 8bit format.

Share this post


Link to post
Share on other sites

you can get GeoTIFF from the SRTM project here: http://dwtkns.com/srtm/


I got smrt_12_3 for Mount Rainier in USA, WA. 


 


The problem is most paint-like programs treat it like a normal tiff. I opened it anyway in Paint Shop and used a couple tools to get:


The file is a 16bit, grayscale with 4044 colors.


 


 


 


I'm starting to see the value in that $100 usd for World Machine.


 


 


edit ... Here is another source to get grayscale GeoTIFF.


http://maps.ngdc.noaa.gov/viewers/wcs-client/


Edited by joedobo

Share this post


Link to post
Share on other sites

Again, they're using the image format (RGBA) for non-image data.  It's just semantics.  If they're not saving all four channels then it's not an image.  A greyscale image is one where the R, G, and B values are the same for each pixel.  Waste of space, especially if it's 16bits per channel.

 

Do you have a source for downloading heightmaps in 16bit greyscale format?  Everything I've found is in standard RGB 8bit format.

 

Of course it is a waste of space to make R=G=B spending 24b on a 8b grayscale or even 48b on a 16b grayscale.   That is why TIFF, PNG and RAW directly support true 16b grayscale images as part of their standard formats without repeating it as RGB.  It is why Photoshop can process single gray channel images.   Please go tell B&W photographers they are not making images because they work in grayscale and not color.  Or medical, astronomy, and geographical sciences which have long used 16b monochrome images.  I already pointed out the GEOTIFF sources which should be compatible with any TIFF reader that should discard the GEO additions which only GIS mapping systems would understand.   I also pointed out the ESM exporter that supports RAW as well as terrain tools, image tools and game engines that support at least RAW format.   RAW format is most popular because it is a simple byte array that is easy to read and write, but PNG has the advantage of lossless compression which is important when making large maps.   Please research this yourself I am getting tired of doing google searches for you.

Edited by yarnevk

Share this post


Link to post
Share on other sites

I got smrt_12_3 for Mount Rainier in USA, WA. 

 

The file is a 16bit, grayscale with 4044 colors.

 

 

SRTM data is 1m steps, so you would want to multiply by 10 to get the dirt heights.  But you also want to scale height by the survey grid spacing for realistic slopes (so rise/run of survey is equal to rise/run in Wurm)   A 4m wurm grid 40 dirts high up is 45 degrees with walkable slopes half that.  Of course it is a waste of 16b grayscale to do only 1m resolution, but it will not fit in 8b greyscale, science cannot agree on interpolating even though the format could support .25m steps and still cover Everest.   Mountains are the easy way to make an island - just raise the water level!  But if you are putting a 4km mountain on a 8km map that will be an average 45 deg slope so not very playable so you probably want to lower the scale.

Edited by yarnevk

Share this post


Link to post
Share on other sites

http://www2.jpl.nasa.gov/srtm/


"Previously, SRTM data for regions outside the United States were sampled for public release at 3 arc-seconds, which is 1/1200th of a degree of latitude and longitude, or about 90 meters (295 feet). The new data are being released with a 1 arc-second, or about 30 meters (98 feet), sampling that reveals the full resolution of the original measurements."


 


I hate to waste time on something futile. I'd need to make a tool to take data from GEOTIFF and feed it into WurmAPI. The scales are obviously different between WU and 1 arc-sec maps (especially the 3 arc-sec) here so I'm not sure if it will work. I need to see it but in order see it, it needs to be made ... darn it.


 


http://earthexplorer.usgs.gov/ seems to give better data then http://maps.ngdc.noaa.gov/viewers/wcs-client/. The latter was giving me corrupt files.


 


 


Edited by joedobo

Share this post


Link to post
Share on other sites

Yes I did gets lots of corruption from NOAA when I downloaded the gigs of data of hires world tiles from the ftp site, even once they downloaded lots of data gaps, noise, and spikes from the survey itself - at the time I was also on lousy DSL so it took forever.  USGS is from more traditional topographic map surveys and not space scans, but that means contour lines have been interpolated onto a grid.


 


If it is a 1m height step on 30 meter grid then that can scale down to .13m on 4m grid or about 1 dirt per grid.  So you would want to scale down a 60km map to the 8km map (2k tiles) I think. You probably do want to scale down the grid simply because the exact real world makes for boring gameplay outside of flight simulators, then scale the height until you get only a few unclimbable cliffs, but most if it is at least climbable (60dirt tile slope?) or walkable (20dirt tile slope?) .  


 


Even though I did fractal interpolation/extrapolation to get around the 1m rounding as well as below the 30/90m and had terrain tiling figured out how to do earth at scale, I found it incredibly boring to walk around in without massively increasing my avatar speed.  The earth is actually rather smooth 8km out of 40000km and includes a lot of places like kansas that is as flat as can be.   Not fun to hike or horseback.  So rather than work with the most detailed earth maps I am going to scale down continents simply because that will be more interesting to play on I think.


 


Surely there is a java image library that reads 16b grayscale TIFF, it does not need to be GEOTIFF itself since those extensions can be ignored.  As long as the reader gives you the 16b array then it is straightforward to use the example API code.


Edited by yarnevk

Share this post


Link to post
Share on other sites

here is a pic of the top of MntRainier. It has problems because I don't have photoshop. That program is one of the few if not only image software you can easily work with 16bit grayscale images. I'm very much at the mercy of what Paint.net wants to do. When I uploaded it to imgur.com some more image alteration probably happended.


 


 



hGCBMe3.png



With this 1024x0124 map you can clearly see the steps in color changes. Doesn't that mean it will be just a obvious when converted to a game map? I think it would be cool to take GeoTiff files and feed them right into a tool which makes WU maps. If its not going to work, i might as well do move on.


 


Yes there are Java tools to open Tiff files. I'm betting they are made to open the file as an image. I doubt there is a Java code made already that can open a tiff files, convert it in a WU meaningful way, and feed that data in the WurmAPI  in proper order.


Share this post


Link to post
Share on other sites

Try the GIMP dev release, it claims 16b support in 2.9 that is not in 2.8 stable release.  If that does not work yet then GIMP recommends to try  http://www.cinepaint.org/ and https://krita.org/


 


That does look like something converted it to 8b in the workflow somewhere.  That will be very obvious 256 dirt cliff contours.  " Indeed it is the paint program that lost the shades - from their web site. "Higher color depths can be loaded, but Paint.NET can only represent 8 bits per channel internally."


 


All you need is a java image code that returns an array then you just loop thru it just like the API does when setting the heights.


 


Here is a Java image processing library 


http://imagej.nih.gov/ij/


 


Data Types: 8-bit grayscale or indexed color, 16-bit unsigned integer, 32-bit floating-point and RGB color. File Formats: Open and save all supported data types as TIFF (uncompressed) or as raw data. Open and save GIF, JPEG, BMP, PNG, PGM, FITS and ASCII. Open DICOM. Open TIFFs, GIFs, JPEGs, DICOMs and raw data using a URL. Open and save many other formats using plugins.


Edited by yarnevk

Share this post


Link to post
Share on other sites

ImageJ does work well. One negative is that 16bit unsigned images are all black in MS preview, paint.net and Imgur. I had to convert it to 16 signed to get the one below and I'm not sure if it changed anything. It's just for sharing a rough idea anyway. The information in the geotiff is 262- 4384 grey scale range. 


 


This is map looks better and has less noticeable steps. I'm able to import these heightmap into L3DT.  



rxHjSXm.png



Share this post


Link to post
Share on other sites

Well you need to do math anyways to set your own sea level to turn the mountain into an island, can do it same step as signed/unsigned add.  I don't recall what signage the standard image formats are supposed to support.


 


The good thing it is open source app so you can fiddle with your images in it, then just merge the image loader in with the WURM API code.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this