Request to Modders and Programmers

[ownerpure5 322]

Can a generous soul please make a basic wurm online world generator that could be used by the vast majority who have literally no skills in Java script/coding. pls

[Warlander 2,730]

+1 for standardized map generator, but I do realize that this would be a time-consuming project, so personally I am only able to give some help.

[whereami 564]

Sorry, but I believe that a great deal of most coder's efforts and resources right after release, will be focused on getting the mandatory green gremlin suits back from pre-2012.

All things aside you could probably take the time to learn the ~15 lines of DOS code you would need to convert a map from a DeedPlanner dump into a map once those things are all released and live.

Edited October 6, 2015 by whereami

[yarnevk 257]

Rather than waiting for map generators which will take some time to get wurmified, maybe a programmer can get on importing a greyscale bitmap so that any authoring tool be it terrain, paint or photo can be used.  Of course that means they are not working on a wurmified generator in the meantime, but I think that will benefit more people.

 

whereami why the snide comment?  The only way to use the API is to learn to program.  How about you publish those 15 lines of DOS code on Steam WU map mod forum since it is so easy?

 

Warlander said DeedPlanner is not suitable for working at server map scale, it was written for deed scale and will likely blow up even if it was conceivable someone wanted to paint a terrain tile by tile.

 

Is nobody planning to explore the existing creative and adventure islands the game ships with first before they run off modding - even if nothing more than to say it really needs a better map?

Edited October 6, 2015 by yarnevk

[Mordraug 2,542]

If it's a choice between a civilian map generator and a more stable WU, I'll wait.

 

Still willing to pay for said generator once it's ready, that said *hint hint*

[encode 13]

Im working on a generator where you only need to give a greyscale heightmap, then it will generate the world with the settings you want.

Working right now in generation of deserts forests etc

For example, this is a heightmap of Tamriel(TES) in the current generator:

(Open spoiler)

[Warlander 2,730]

I think you need to tweak heights a little, there are sudden jumps in steepness everywhere.

[encode 13]

Yes, have much to tweak.

[yarnevk 257]

Yes, have much to tweak.

Elder Scrolls ripping the map from Morrowind for fun is on my todo list, already have the rip code from old Unity project, and I pretty sure it exists in greyscale heightmap form elsewhere.  Would be fun to rebuild in Wurm all the forts and towns.  Actually discovered that the OpenMorrowind code was wrong from another modders post buried in archive history (related to tiles vs. grids if I recall) but they did not listen because he was not on the team.  Very interesting map format.

 

@Warlander too steep?    Wurmian mountains always have been unrealistically unclimbable (unless you are an unridden cow or spider) steep!  Although it does raise a game design issue, Elder Scrolls maps are designed with unrealistic mountain barriers that you cannot climb to funnel you down the properly winding quest paths to make the open world seem bigger than it actually was,  of course I broke that flying around as a vampire.  I always thought the Wurmian steep cliffs was to provide road building and surface mining challenges...

 

Oh wait I see contour cliffs in the map dump?  did you use an 8b grey scale rather than 16b?

 

Is Wurm height API measured in 16b int dirt (0.1m?), maybe that is cause of wrong scale.   Anyways where did you get a Tamriel map rip did someone piece together ESO zones?  Or is that from the old Tamriel Morrowind mod project?

 

Also if one does not plant flora from such a grayscale heightmap import does the game seeding algorithm take over and grow it at server birth based on the tile type (trees/bushes on grass)

Edited October 7, 2015 by yarnevk

[whereami 564]

I was only disappointed that people are wanting to reap rewards yet clearly state they're willing to put in no effort to get them. To me this is another random beg-for-help thread about a subject that has long since been covered in another topic.

I know of a number of excellent terrain generators which export in a multitude of formats; all we're waiting for is the game to actually be released so someone can create a conversion tool. If you want something you can start playing with right away, google TerraGen. It's freeware (don't pay money for it) and it's an excellent piece of software indeed.

Edited October 7, 2015 by whereami

[Budda 2,673]

I was only disappointed that people are wanting to reap rewards yet clearly state they're willing to put in no effort to get them. To me this is another random beg-for-help thread about a subject that has long since been covered in another topic.

I know of a number of excellent terrain generators which export in a multitude of formats; all we're waiting for is the game to actually be released so someone can create a conversion tool. If you want something you can start playing with right away, google TerraGen. It's freeware (don't pay money for it) and it's an excellent piece of software indeed.

 

The game doesn't need to be released for a conversion tool to be created, that's literally the reason for the API that was just put out this week.

[joedobo 1,187]

I was playing around with L3DT. I just need to generate a heightmap that I like and i'll use Paint.Net for tile types.

 

Rather than waiting for map generators which will take some time to get wurmified, maybe a programmer can get on importing a greyscale bitmap so that any authoring tool be it terrain, paint or photo can be used.  Of course that means they are not working on a wurmified generator in the meantime, but I think that will benefit more people.

 

whereami why the snide comment?  The only way to use the API is to learn to program.  How about you publish those 15 lines of DOS code on Steam WU map mod forum since it is so easy?

 

Warlander said DeedPlanner is not suitable for working at server map scale, it was written for deed scale and will likely blow up even if it was conceivable someone wanted to paint a terrain tile by tile.

 

Is nobody planning to explore the existing creative and adventure islands the game ships with first before they run off modding - even if nothing more than to say it really needs a better map?

 

You'll need more than just a heightmap. Don't forget about tile types, Trees (age and grass height), flowers on grass.

 

BMP is a well documented file format and you can easily parse it in binary to match each pixel with a x.y coord. The simple example Warlander gave us has a nested for-loop to address every x.y location. Further, for each x.y we need tile elevation (heightmap) and tile type plus any additional data for those types (tree's have age, grass can have flowers).

 

One way to make the tile type map would be another BMP that is viewed top down. it would have limited colors and each color is a tile type. Keep in mind the WO map dumps have some projection transformation (the lighting an darkking to show elevation). A simple top down map would have few colors (grass, tree, rock, dirt, gravel, steppe, tundra, tar...etc.)

 

Using these two BMP files it should be possible feed relevant elevation and tile types into WurmAPI. It's easier to find a simple heightmap generator and paint some things in Paint.net. Programs like World Machine have extra features that aren't needed here.

 

This is my plan (how I'd do it if I was using Python). Sadly I'm not good with Java so it will be awhile before I can turn the plan into a tool.

 

 

Warlander, questions

1. Is 1000 the maximum terrain height (to avoid serve crashing)?

2. Are 10 tiles the minimum water area needed on each boarder? How deep do these tiles need to be, I see you did dirt at -100 and rock at -200

3. Is -200 the minimum terrain depth?

 

 

[Warlander 2,730]

I was playing around with L3DT. I just need to generate a heightmap that I like and i'll use Paint.Net for tile types.

You'll need more than just a heightmap. Don't forget about tile types, Trees (age and grass height), flowers on grass.

BMP is a well documented file format and you can easily parse it in binary to match each pixel with a x.y coord. The simple example Warlander gave us has a nested for-loop to address every x.y location. Further, for each x.y we need tile elevation (heightmap) and tile type plus any additional data for those types (tree's have age, grass can have flowers).

One way to make the tile type map would be another BMP that is viewed top down. it would have limited colors and each color is a tile type. Keep in mind the WO map dumps have some projection transformation (the lighting an darkking to show elevation). A simple top down map would have few colors (grass, tree, rock, dirt, gravel, steppe, tundra, tar...etc.)

Using these two BMP files it should be possible feed relevant elevation and tile types into WurmAPI. It's easier to find a simple heightmap generator and paint some things in Paint.net. Programs like World Machine have extra features that aren't needed here.

This is my plan (how I'd do it if I was using Python). Sadly I'm not good with Java so it will be awhile before I can turn the plan into a tool.

Warlander, questions

1. Is 1000 the maximum terrain height (to avoid serve crashing)?

2. Are 10 tiles the minimum water area needed on each boarder? How deep do these tiles need to be, I see you did dirt at -100 and rock at -200

3. Is -200 the minimum terrain depth?

1. I had problems with values close to signed 16 bit boundary values - very close to them server is just crashing, when you are too close to them it can block your movement and terrain is unterraformowable.

2. Not sure about distance, but depth can be any as long as tile is under water.

3. There are no limitations when it comes to minimal values that must appear on map (except negative ones for map edge naturally).

[yarnevk 257]

Joedobo you would still want to use greyscale for flora and texture layers - the number would map directly to the enum or fold in the ages and expand the enum.   If you use RGB colors shown on dump maps then you are tripling the file size to cover over 16 million possible values for those layers which is excessive.    Even if the enum ever exceeded 256 values you could just switch up to 16b.  

 

Of course painting in color is easier to visualize if you don't mind the wasted file space, but you need a very restricted palette so only the handful of colors that corresponds to flora./terrain are used.  Older file format are palette based so that could work if the newer formats and paint programs still support palettes..  The first dozen palettes can be for trees, next handful for bushes. Age can be folded in by using darker colors.

 

I think better way to go is use an RGB file as three grayscale layers to make file management simple.  R for surface type, G for trees, B for bush ids - then you have one layer file   If Ores are added then you can expand it to a RGBA file.   Just start the enums at 1 rather than 0 so that 0 means nothing there.

 

Terrain has to be 16b grayscale because the number of heights exceeds 256.  @Warlander is that 1000 >dirt< height limit?  What are the depth limits for the biggest boats to pass and sea creatures to spawn?

 

.png is a better file format than .bmp smaller file sizes with lossless compression, surely there must be Java code for returning byte and word arrays and handle those parsing details, and making code more easily ported to other formats like .tiff

 

@Warlander is if the textures are painted but the flora is not defined, can the default Wurm seeding algorithm take over - or does it require existing plants to seed.

 

Understand about langugages I have forgotten more than I remember , I prefer to work in Matlab and export images rather than using Java - images give you something to archive and share maps it just needs settled what the file conventions are.

Edited October 7, 2015 by yarnevk

[Ricowan 199]

The height values for each point on the map range from -32,768 to 32,767.  This is a "short", or a "signed 16bit" number.  Warlander is warning that we should not use heights near the upper and lower range.

 

Greyscale images can be scaled to this range, but you'll see lots of stepping since there are only 256 possible greyscale values.  You'll need to use the full 64k colors in a 16bit image if you want to represent the full range.

 

This is why an application that generates the map, as well as saves it as Wurm world .map files, is the better way to go.   Or at the very least, an app that reads in a greyscale image but then interpolates the heights to smooth them out some.

Edited October 7, 2015 by Ricowan

[yarnevk 257]

Both TIFF and PNG support 16b greyscale so why compromise a detailed erosion map by stepping it down to 8b BMP then interpolating back to 16b loosing all the erosion information (or Wurmian Terraforming).  While you may not see the stepping looking at an image, on a map it becomes 256 high dirt steppes every dozen tiles or interpolated slopes lacking detail (imagine Minecraft with 25x bigger blocks...) So a standard 16b grayscale file is a much better map interchange source , and enables any modern painter (GIMP >2.10 has 16b and even 32b HDR painting, Photoshop already had it, and pretty much every camera uses a RAW image variant that can convert to standard formats) .  Most terrain generator that output TIFF or PNG have long supported 16b because 8b defeats the purpose of these tools.   The idea of grayscale heightmaps is if users can know nothing about Wurm nor Java as long as someone writes a grayscale 16b image reader into the API.

 

Surface and Flora mapping can use 8b because there are not that many choices even if you fold in flora age. (i.e. #7 could mean "Walnut Tree, Old').   That is more difficult in external terrain tools because they do have to have some way to configure biome maps to match Wurm enums.  In paint programs it is easy, just literally paint by number.  But that is why I ask if that info is missing does Wurm server init run the Rolf algorithms to add it or will you get nothing but dirt.

 

The entire point of using the API is that the database map file is private and subject to format change - otherwise they could have documented the .map format and provide no code API..  

 

1000 max height did not make sense for a 16b number.  Maybe he means within 1000 of max is broken so keep to 31767 dirts max? That is much more reasonable just over 3km mountains on an 8km size map.

Edited October 7, 2015 by yarnevk

[Ricowan 199]

I was referring to the idea that surface and flora maps could be combined into one image.  That won't work if you're using all 64k colors for the height values.

 

I'm note sure where the 1000 max height came from, I don't think it was Warlander.  The only time I see 1000 in the API code is in the map dump routines, where the values need to be scaled to create an image.

 

I don't think the .map files are private and subject to change.  They look to be simple disk versions of a 2 dimensional array.  That's it.  The API helps with creating and modifying the files and it helps ensure that incorrect values aren't stored there.

[yarnevk 257]

I was not suggesting surface and flora maps be combined with height maps.   I was suggesting an 8b RGBA map for biomes which is bushes, trees, surfaces and ores.  AlthoughI think bushes/trees can be collapsed into on channel then surfaces and ores for 8b RGB . Then two 16b greyscale map for dirt and another one for rock (or one 16b RG file and save the B channel for whenever rivers/lakes beyond sea level are supported).  The advantage of using 16b greyscale images is existing terrain workflows support those images I think PNG being more popular than TIFF, and the PNG lossless compression will work great for the 8b RGB biome maps.

Edited October 7, 2015 by yarnevk

[joedobo 1,187]

Joedobo you would still want to use greyscale for flora and texture layers - the number would map directly to the enum or fold in the ages and expand the enum.   If you use RGB colors shown on dump maps then you are tripling the file size to cover over 16 million possible values for those layers which is excessive.    Even if the enum ever exceeded 256 values you could just switch up to 16b.  

I'll likely switch to PNG now. 

 

1. tree ages...Id use a simple RNG algorithm in the code. It would be too difficult to hand paint a 15 shade variation (there are 15 tree age stagnes) for each pixel/tree tile.

2. Flowers...I'd use a simple RNG algorithm that converts some grass tiles to flowers. I wonder if the server randomly converts grass tiles to flowers during its life cycle or if flower tiles have a set location that is generated at map creation. I know that reed tiles will revert to reed from dirt if left alone. This leads me to believe there is a certain level of fix state originating from the first map generation.

3. tree types is an important point. There would be 20 different colors just for trees. 

 

I don't see more than 40 different colors for all possible tile types.

 

 

The height values for each point on the map range from -32,768 to 32,767.  This is a "short", or a "signed 16bit" number.  Warlander is warning that we should not use heights near the upper and lower range.

 

Greyscale images can be scaled to this range, but you'll see lots of stepping since there are only 256 possible greyscale values.  You'll need to use the full 64k colors in a 16bit image if you want to represent the full range.

 

This is why an application that generates the map, as well as saves it as Wurm world .map files, is the better way to go.   Or at the very least, an app that reads in a greyscale image but then interpolates the heights to smooth them out some.

*sheds a tear* This is a major problem. I'm only finding grayscale height maps. Trying to figure out and write my own interpolation algorithms is yet another hurdle.

 

 

I was referring to the idea that surface and flora maps could be combined into one image.  That won't work if you're using all 64k colors for the height values.

 

I'm note sure where the 1000 max height came from, I don't think it was Warlander.  The only time I see 1000 in the API code is in the map dump routines, where the values need to be scaled to create an image.

 

I don't think the .map files are private and subject to change.  They look to be simple disk versions of a 2 dimensional array.  That's it.  The API helps with creating and modifying the files and it helps ensure that incorrect values aren't stored there.

Correct. the 1000 came from the API.

[joedobo 1,187]

 The advantage of using 16b greyscale images is existing terrain workflows support those images..

Where are you finding a grayscale image that has more than 256 colors (8bit).  Are there really grayscale images with 65,536 colors (16 bit)?

[yarnevk 257]

joedobo

 

Terrain generators have standardized on using 16b grayscale, borrowing the use of those format in photography.  This is not a problem and you can find supporting communities exist already discussing what generators and editors do support it.   Not only do you not want to write an 8/16b interpolation algorithm, you would not like the result.  You just need to make sure your random map downloads you get have not been converted to 8b grayscale (older GIMP used to do this, newer GIMP supports it)

 

Wurm is not the first game engine with 16b terrain import, Unreal and Unity have long been doing it. 

 

Quoting Unreal support

 

Heightmap Format

For heightmaps, the .raw/.r16 is 16-bits per sample, litle-endian, unsigned values, one per vertex, with no header or other data. That is, two bytes per vertex in PC byte order. So for a 127x127 case you'll need 32258 bytes. To save a heightmap from Photoshop, change the image mode to 16-bit grayscale. Then choose the RAW file format and select 1 channel, 16 bits per pixel, and PC byte order.

 

Quoting Unity support

Working with Heightmaps

As noted above, the height tools are reminiscent of painting tools available in image editors. In fact, the terrain is implemented using a texture behind the scenes and so the tools are ultimately acting as texture painting tools.

The height of each point on the terrain is represented as a value in a rectangular array. This array can be represented using a grayscale image known as a heightmap. It is sometimes useful to work on a heightmap image in an external editor, such as Photoshop, or obtain existing geographical heightmaps for use in your game. Unity provides the option to import and export heightmaps for a terrain; if you click on the Settings tool (the rightmost button in the toolbar) you will find buttons labelledImport RAW and Export RAW. These allow the heightmap to be read from or written to the standard RAW format, which is a 16-bit grayscale format compatible with most image and landscape editors.

 

quoting World Machine terrain generator support

within world machine

1. 
   

   Place a Height Output device into your world. Wire the terrain you wish export into the device's input.

   
   

   You can also export a colormap by placing a Bitmap Output and connecting it appropriately.

   
   
   
2. 
   

   Choose your export formats within the File Output device. You should use the RAW16 format.

   
   
   
3. 
   

   Determine your resolution. As noted in this document, Unreal Engine has some unique requirements for resolution of your heightfield.

   
   
   
4. 
   

   Build your world and export all files. The "Export Terrain files..." option from the File Menu provides a central location to do both.

   
   
   

 

 

Quoting matlab support

imwrite(A,filename) writes image data A to the file specified by filename, inferring the file format from the extension. imwrite creates the new file in your current folder. The bit depth of the output image depends on the data type of A and the file format. For most formats:

• 
  

  If A is of data type uint16 and the output file format supports 16-bit data (JPEG, PNG, and TIFF), then imwriteoutputs 16-bit values

  
  
  
• 
  

   

  
  
  

Quoting gimp support

 

When can we see 16-bit per channel support (or better)?

For some industries, especially photography, 24-bit colour depths (8 bits per channel) are a real barrier to entry. Once again, it's GEGL to the rescue. Work on integrating GEGL into GIMP began after 2.4 was released, and will span across several stable releases. This work will be completed in GIMP 3.0, which will have full support for high bit depths. If you need such support now and can't wait, cinepaint and Krita support 16 bits per channel now.

The current development branch, GIMP 2.9.x, supports higher bit depths than the 2.8 and older 8-Bit-per-component...

Edited October 7, 2015 by yarnevk

[joedobo 1,187]

I'm interesting in the number of unique colors. Can a greyscale image have more then 256 unique colors?

[yarnevk 257]

A 16b grayscale map is 2^16 (over sixty five thousand) shades of gray, and shades of gray are technically a color.  Each shade of gray at a pixel directly maps to a height in game (might need to do a unsigned to signed conversion or row/col twist or little/big endian byte swap - any image reader code will take care of those format details)

 

Again search any terrain engine or game engine forum for learning about grayscale heightmap workflows, all of this information exists.  I am not proposing anything new here.

 

You do not do height maps with 8b RGB formats if that is what you are asking.  You would do biome maps with 8b RGB layers though - GIMP certainly lets you draw on each of the RGB layers directly - you could assign Green #16 to old oak tree and Red #1 to Grass and Blue #99 to Gold Ore.  Combined into an RGB image format you have a described a tile with old oak tree on grass with gold ore underneath (once API supports ore) all described as one colormap.    Visually as a color image it would look like a messed up Tie-Dye T-shirt which is why you switch your paint program to work directly on the color layers.

 

This is very similar to how Unity does texture mapping R is amount of texture #1, G is amount of texture #2, B is amount of texture #3 - with their purpose being describing how to blend textures in shaders (which Wurm does not do)   So you do something similar and use the RGB channels to instead describe the object number on or under the surface texture.  It is not painting by color, it is painting by color intensity on RGB color layers to represent enumerated textures or objects.  A paint program is probably the best way to get the biomes on a map right now, since biome generators are going to need knowledge of Wurm biomes.

Edited October 7, 2015 by yarnevk

[Acurapassion 54]

Will World Machine not work with Wurm?

Edited October 7, 2015 by Acurapassion

[joedobo 1,187]

@ yarnevk  Thanks for taking the time to try and explain things. To be honest i'm still confused. I think it because I know nothing about Unity, World Machine or any other terrain render / game engine. I also don't have the money to buy them so i'm not going to mess around reading about them. I'm also more interested in math and computing concepts then learning about how specific tools.

 

I'm going to try and find some heightmaps that have 65k unique colors (16bit). I'll also look at interpolation algorithms with goal of building them into a tool which converts 256 color greyscale heightmaps (from what I've seen these seem to be the standard) to a range that will work in wurm ( -200 to about 32k).