A19e Nitrogen - UNSTABLE

[slight]

Just registered on the forums here to say thank you for making this fantastic tool!

 

I've only just started looking at NitroGen, still going through the random generation options, so I've not tried importing height and biomes from bitmaps yet. Can you verify how you are handling the height maps?I saw this post:

 

The imported hightmap is 8 bit, as it uses the workflow of the normal generator. Having a 16 bit version input is possible, but ...

 

So any squared greyscale PNG will work. (Btw: only the green channel is loaded).

It can be handdrawn or just converted from a real hightmap.

...

 

The final and smoothed output will be a 16 bit hightmap.

 

I think I saw that later versions also support 16 bit raw from photoshop, yeah?

 

About 20 years ago I made height map conversion tools for the Battlezone game engine. I'd like to share an idea with you that came from that. If you're using 24bit RGB PNG as source, you can easily get 3 times the precision (768 levels vs 256) by simply adding the R G and B channels together. If someone wants to work in greyscale, or has an existing 24 bit image that only uses greys, it should be unaffected - each channel adds a third of what green used to add - but if someone wants that extra precision they can define the height map across 3 ranges in the RGB space, eg: black > red > yellow > white or black > blue > magenta > white to get 3 times the precision.

 

Thanks again Damocles, you've made an amazing tool here, really looking forward to getting deeper into it.

--

edit: So I have been messing around a bit more, imported a height from terrain.party and made custom biome maps in photoshop, the whole process from scratch was up and running in less time than it takes to generate a vanilla map... This thing is great!

 

Found a problem with the water but you're probably already aware of it, I still have to read this entire thread.

Edited May 7, 2019 by slight (see edit history)

[Xylvier]

^using a terraingenerator (i dabble with Gaea) for a heightmap sure works hand in hand with this tool, and the recent newest feature makes this even better and more predictable.

 

While it is possible to just run the gen a few times and see, could we please get playerspawn and traders added too for the mask?

 

Also, i was wondering if the random generation of wasteland and burned patches is switched off or ignored once you select to import a heightmap and mask? As the biome border selection seems to be ignored too.

[Damocles]

Just registered on the forums here to say thank you for making this fantastic tool!

 

I've only just started looking at NitroGen, still going through the random generation options, so I've not tried importing height and biomes from bitmaps yet. Can you verify how you are handling the height maps?I saw this post:

 

 

 

I think I saw that later versions also support 16 bit raw from photoshop, yeah?

 

About 20 years ago I made height map conversion tools for the Battlezone game engine. I'd like to share an idea with you that came from that. If you're using 24bit RGB PNG as source, you can easily get 3 times the precision (768 levels vs 256) by simply adding the R G and B channels together. If someone wants to work in greyscale, or has an existing 24 bit image that only uses greys, it should be unaffected - each channel adds a third of what green used to add - but if someone wants that extra precision they can define the height map across 3 ranges in the RGB space, eg: black > red > yellow > white or black > blue > magenta > white to get 3 times the precision.

 

Thanks again Damocles, you've made an amazing tool here, really looking forward to getting deeper into it.

--

edit: So I have been messing around a bit more, imported a height from terrain.party and made custom biome maps in photoshop, the whole process from scratch was up and running in less time than it takes to generate a vanilla map... This thing is great!

 

Found a problem with the water but you're probably already aware of it, I still have to read this entire thread.

 

Hi,

it really comes down to how users are able to find a usable workflow. Creating and managing greyscale images is trivial to do in any graphics program. Such that a usable hightmap and placement-mask for gameplay could be drawn within a few minutes.

 

The best solution regarding quality would be to import a 2-byte channel RAW map directly (like from a Unity terrain or Blender). But that is a very specific workflow, I assume not many people can do or use efficiently.

 

From https://terrain.party/ the user also just gets an 8-bit per channel greyscale image.

 

Your suggestion is interesting to separate the range into 3 channels, but it would then still have to be told to the editor that those need to be combined (to match the internal 0 meter to 255 meter value range). The user would have to mostly work with 2 channels in parallel (from 0 to 84 meters - where most of the terrain would be set, and 85 to 168 meters - for medium hills).

 

Overall, there is a natural limit to the resolution given by the nature of the voxels anyhow. POIs can only have blocks placed in 1 meter increments. The terrain needs to match that around the POIs.

 

The terrain is smoothed over during POI placement and before export. So a high dimension of the imported hightmap (possibly as big as the output maps dimension will be) will have a higher impact on quality than the resolution.

 

------

 

Water: any area at 33 meters and below will get a water-spawner-node. (33 would be the RGB value here). So the main low-land terrain should be at least 35 Meters high.

For imported highmaps from terrain libraries you should adjust the grey-color-range in such a way that oceans/lakes have a grey value of 33 and below, and the land-mass 35 and above.

 

Maybe I can add a water-level to the preview map to visualize that. (Its only an approximation, as the game is ultimately doing the water "flooding")

 

There are two water types: the general water level (33 and below) and small lakes (spawned at different hights, can be disabled).

Edited May 7, 2019 by Damocles (see edit history)

[Damocles]

^using a terraingenerator (i dabble with Gaea) for a heightmap sure works hand in hand with this tool, and the recent newest feature makes this even better and more predictable.

 

While it is possible to just run the gen a few times and see, could we please get playerspawn and traders added too for the mask?

 

Also, i was wondering if the random generation of wasteland and burned patches is switched off or ignored once you select to import a heightmap and mask? As the biome border selection seems to be ignored too.

Edit:

 

I can add more colors to the mask, such as traders and playerspawns.

 

The imported maps dont do much with the biomes (apart from putting snow on high elevation, and using an optional border biome). The patches of wasteland and burned forest are part of the terrain gen, the map importer runs parallel to that and does not apply those procedures.

You would have to paint the precise color in the biomes.png to mark custom biomes in imported aps.

Edited May 7, 2019 by Damocles (see edit history)

[Xylvier]

Edit:

 

I can add more colors to the mask, such as traders and playerspawns.

 

The imported maps don't do much with the biomes (apart from putting snow on high elevation, and using an optional border biome). The patches of wasteland and burned forest are part of the terrain gen, the map importer runs parallel to that and does not apply those procedures.

You would have to paint the precise color in the biomes.png to mark custom biomes in imported aps.

 

Sounds great, more options are always welcome.

 

 

Regarding the options available already though...

Means it's intentionally that only when you use random "genmode", it will generate a border and those optional patches.

While i can understand that you did it that way it should work either way, since it's optional anyway, like user asks for it .. put it in

 

To prevent this i would suggest to, based on users choice of "genmode" deactivate the features that you want to withhold and make the user that way aware that it won't happen.

 

Also, if the biomes.png is written out either way, just not covering any patches or such why not consider the following idea.

Make it easier for all users and put a small block with each of the biome colors (small 50x50 block each) in the image to make sure the right colors are used. By setting them in the outer border they would most likely be overwritten later on anyway

Would need a comment in the Gui-bottomarea to make users aware of as well though.

Not saying that those that draw their biomes.png already can't get it done without, but thinking of newer users

[Xylvier]

For those that used my little parser for the prefablist for NITROGEN:

...

I found some issues with the damn xml files having variations in formatting.

Reworked and re-uploaded.

 

to save you the search, here the link once more:

https://drive.google.com/open?id=1Wfp5I6DqjVZGfSJP9Hq1eZvhFInbvTuC

 

Sorry that i missed that, hope it didn't cause too much trouble

Edited May 22, 2019 by Xylvier (see edit history)

[slight]

Make it easier for all users and put a small block with each of the biome colors (small 50x50 block each) in the image to make sure the right colors are used.

If you use photoshop or compatible, this file might be useful: 7dBiomes.act

 

It's a colour table from a generated biome.png, in photoshop you can load it as swatches to use for painting, and it also allows you to use filters and be a bit sloppy with the edge colours, because once you are done painting biomes, do Image > Mode > Indexed... > Palette: Custom > Load > 7dBiomes.act > OK. Image > Mode > RGB to force every pixel back to one of the 5 biome colours.

[Xylvier]

^thanks will check that out, i have an old version of photoshop, but for those using gimp/paint.net or whatnot, i stick to my suggestion

[slight]

Hi,

it really comes down to how users are able to find a usable workflow. Creating and managing greyscale images is trivial to do in any graphics program. Such that a usable hightmap and placement-mask for gameplay could be drawn within a few minutes.

 

The best solution regarding quality would be to import a 2-byte channel RAW map directly (like from a Unity terrain or Blender). But that is a very specific workflow, I assume not many people can do or use efficiently.

 

From https://terrain.party/ the user also just gets an 8-bit per channel greyscale image.

 

Photoshop can export 16 bit raw output too but it is pretty finicky, you have to know the exact settings the importer expects. PNG is *supposed to* support 16 bit greyscale but whether your bitmap editor of choice supports 16bit PNG export is another question.

 

The height precision thing is not that much of a big deal, it only effects very shallow inclines where you might have 1 meter of height for every 10 or 50 meters. Currently areas like that come out as terraced steps, they're smoothed over but the steps are still noticeable even on roads. As to workflow, say you're using a greyscale map from terrain.party. Those were coming down for me at ~1k square and need to be scaled up, but if you scale up in 8 bit greyscale the shallow inclines will have the 256 terraced steps baked in the bitmap. If you remap the 256 levels to 768 levels using split channels (or convert to 16 bit greyscale) you still have only 256 levels used of the available values at first, but as soon as you scale up or apply smoothing in the image editor, you are working at the higher precision.

 

----

 

EDIT: Good news! (maybe) I just went and checked. terrain.party supplies images as single channel 16 bit greyscale. Photoshop (the old version I use, at least) can edit and save PNGs in that format. RAW files are not needed, it comes down to whether NitroGen can import and read single 16 bit channel PNGs... it gives this message:

 

...\import_HM.png not TYPE_3BYTE_BGR, copy type 11 -> 5

 

It reads the 16 bit file correctly but it outputs as RGB/8. I'm not sure the internal workings, but if you are making the heightmap in NitroGen, it should be pretty easy to support 16 bit PNG.

 

---

 

The point about adding 3 split 8 bit channels is if NitroGen is currently expecting 3 channel greyscale and only reading the green channel, the greyscale maps are completely unaffected and no existing workflow is broken, but 768 level bitmaps become an option for anyone willing to take the extra steps to make them.

 

I went looking to find some example images... black > red > yellow > white used to be pretty common but seems to have fallen out of fashion and hue based topology maps have become the norm. Those give you even more levels (up to 1790 if you use the full range of black > blue > cyan > green > yellow > red > magenta > white) but the problem with hue maps is there is a trade-off between maximising for machine readable levels vs human readability, so multiple use cases have led to many different standards.

 

About the water, the problem I get is missing blocks around the shores, usually in areas with shallow incline. What I think is happening is you sample the height at regular intervals, preview.png suggests it's a 128x64 grid, if the sampled pixel is <33 you spawn water at that pixel. In some cases though the sampled pixel is > 33 but there are other pixels in that block < 33 and these don't get filled, leaving walls of water up to a couple meters high in some places around the shoreline. A simple fix would be to keep track of the lowest pixel in each block, if the grid aligned pixel is > 33 and the lowest is < 33 put a fill at the lowest point instead. That would fix almost all of it, but you'd have to do a bit more to get those edge cases where the sampled pixel happens to separate two bodies of water.

 

Edit: here's a screenshot of the water problem: https://imgur.com/XSvprvB

Edited May 8, 2019 by slight (see edit history)

[Damocles]

About the biome colors: I could render some "palette" pixels in a corner of the biome map optionally. (Im mostly worried about the GUI of the generator getting too complex with too many options), or just include a reference biomes.png for people to pick the correct colors from.

 

 

About 16 bit greyscale: I could import those directly to the POI mapper (skipping the terrain gen, and its 8 bit intermediary output).

I have to see the precise output what photoshop produces or terrain.party supplies though, maybe you upload and can add a link to the file.

 

Then the user would have full control (and full responsibility) about the precise hightmap, as smoothing should be skipped here.

 

----

 

The water should theoretically flood everything evenly, even with a single water-spawner.

The edge case you see at shallow shores is actually a problem with the games internal water-spreading calculation. Looks like it regards shallow terrain voxels as fully blocked in some cases.

 

While the generator spawns the spawners in a regular grid (checking if the near area is below water level), it should theoretically still flood everything evenly. Maybe the floodfill is blocking itself with too many water spawners...

 

If you want to test around, erase all water spawners from the xml apart from a single one in the middle of the lake (the lake with the observed problems) and see if it fills everything evenly. In theory a single spawner should fill the complete lake, as it only stops at the edge of the map.

(the spawners for large lakes are after the <!-- comment in the xml)

Edited May 8, 2019 by Damocles (see edit history)

[slight]

OK I ill check out water spawners a bit more. The only place I'm putting water and seeing problems is on water that extends to the edges of the map, my map has a coastline as the southern border. I noticed today a tiny spot of landlocked water next to the coastline that broke my theory of what could be causing it. Also I am messing with non standard map sizes (5120) so that might be causing issues.

 

Here's the 16 bit greyscale PNGs : Idaho.rar

I was watching some you tube videos, using NitroGen is actually the first I have looked at 7DTD editing. I didnt realise... you can just put a 16 bit TGA in the map folder and the game will generate a raw file and heightmap from it on launch.

[Damocles]

I have not tried that TGA import, but the problem would still be to match the POIs to the hightmap and flatten the terrain as needed. So a tga import is of limited use for an actual map.

[Damocles]

OK I ill check out water spawners a bit more. The only place I'm putting water and seeing problems is on water that extends to the edges of the map, my map has a coastline as the southern border. I noticed today a tiny spot of landlocked water next to the coastline that broke my theory of what could be causing it. Also I am messing with non standard map sizes (5120) so that might be causing issues.

 

Here's the 16 bit greyscale PNGs : Idaho.rar

I was watching some you tube videos, using NitroGen is actually the first I have looked at 7DTD editing. I didnt realise... you can just put a 16 bit TGA in the map folder and the game will generate a raw file and heightmap from it on launch.

 

Ok, this 16 bit png format (8TYPE_USHORT_GRAY) seems to be imported by Java without an issue, it just needs to be converted to the float map directly then.

I can add an import for that when I have some time.

[slight]

It just occurred to me that if the height in game is mapped to a 256 meter range and the source is either 8 or 16 bit, you could possibly round (or floor) the pixel values to the nearest meter in photoshop or whatever by converting a 16 bit grey image to 8 bit and back again, then with the 8 bit layer underneath the 16 bit layer in photoshop, erase the city and POI areas from the 16 bit layer to snap it to the nearest meter. Soft alpha values around the removed areas would smooth the transitions across a few meters.

 

BTW I really like your height weighted A* approach with the roads, it generates nice winding roads that are great for motorbikes, it seems a waste that you don't put dirt roads leading up to all the hillbilly and mountain lodge POIs though, as the mountainous terrain would make the best roads.

[Damocles]

Its mostly a visual thing to not have too many roads. The map could end up looking like a huge spiderweb with too many roads.

 

The fact that roads seldomly go up mountains is naturally due to the roads actively avoiding harsh terrain if possible. They will try to find the easiest and flattest terrain to traverse, like going through a valley.

 

I can test how it looks when the roads go up so SOME mountain POIs, to have more of those mountain-passes.

[slight]

Yeah, I get not wanting roads everywhere. It's sparked my interest, so I might write some height weighted A* roads in Unity myself, but with a different method. Rather than connecting each node to 2 or 3 neighbour nodes, which can make redundant paths as well as leave two halves entirely disconnected, I'd pick one node to be the primary, eg. the biggest city, then connect every appropriate POI to that, but... any pixel previously set as road are re-weighted to extremely low cost (or just terminate the search) so every new road feeds into the nearest existing road, rather than seeking a specific neighbour POI, so you'd get a branching pattern spreading out from the "main" city. Maybe if a node finds another unconnected node while looking for the connected group, it can add a road there too...

[mrsquish]

Hey mate,

 

Trying to get Nitrogen to work on a Server Core VM, with only the dedicated server installed. Managed to get Java installed, had to change your batch files to point directly to java.exe. App runs, can't edit the output folder and clicking the open button throws and exception (no explorer.exe installed on Server Core). When I try and generate, it complains that it can't load resources and says the working directory looks wrong.

 

Can you please point me in the right direction. Also, would be good if the output folder text box wasn't locked so I could edit it.

 

Cheers.

[Damocles]

You need to navigate via console to the nitrogen main directory and start the bat there locally. Java needs to find the resource folder in its working (active) directory. Thats usually the one the jar is started from.

 

The world folder is the created inside the output folder with the maps name.

The open command is just a convenience function to find the generated folder, using the explorer command.

[Damocles]

Yeah, I get not wanting roads everywhere. It's sparked my interest, so I might write some height weighted A* roads in Unity myself, but with a different method. Rather than connecting each node to 2 or 3 neighbour nodes, which can make redundant paths as well as leave two halves entirely disconnected, I'd pick one node to be the primary, eg. the biggest city, then connect every appropriate POI to that, but... any pixel previously set as road are re-weighted to extremely low cost (or just terminate the search) so every new road feeds into the nearest existing road, rather than seeking a specific neighbour POI, so you'd get a branching pattern spreading out from the "main" city. Maybe if a node finds another unconnected node while looking for the connected group, it can add a road there too...

 

That would work too, as long as you always search towards the nearest next node (town). Not sure if that might end up looking like a snake then, not generating branching/crossing roads, but one long winded road.

 

I have made a galaxy map (like in EvE) once with a similar distribution pattern, balancing out connections and dead ends to keep it interesting, while assuring that every system is connected to the grid.

Edited May 9, 2019 by Damocles (see edit history)

[slight]

Thinking out loud on roads a bit more, say there is a single 8 bit channel for the road, maybe grab the unused blue of the splatmap temporarily... each time a road is created it does a ++ to road pixels on this channel, values in those pixels divide the default weight when placing additional roads, so the more a road gets re-used, the lower the weight, the more likely it will get used again... this would create single pixel wide paths with a byte range of values, then the road intensity in the splatmap can be a function of those values, where 1 is a barely visible dirt track, and the highest values make wide asphalt freeways.

 

I don't think Unity is the best platform to make this in, it doesn't natively support TGA or 16bit images etc.

[rebelone]

Hi, is Nitrogen compatible with the latest 17.3 exp or is RWG changed too much?

[Damocles]

Hi, is Nitrogen compatible with the latest 17.3 exp or is RWG changed too much?

Worked fine when I tested it. Its independent of the build-in RWG.

 

I have to check if there are new POIs that can be added to the list, or changed dimensions.

[rebelone]

Worked fine when I tested it. Its independent of the build-in RWG.

 

I have to check if there are new POIs that can be added to the list, or changed dimensions.

 

OK thanks for your reply, and your great tool!

[zootal]

Hi, is Nitrogen compatible with the latest 17.3 exp or is RWG changed too much?

 

I'm running a NitroGen 16K map on 17.3, and it works fine. So far...

[Damocles]

Thinking out loud on roads a bit more, say there is a single 8 bit channel for the road, maybe grab the unused blue of the splatmap temporarily... each time a road is created it does a ++ to road pixels on this channel, values in those pixels divide the default weight when placing additional roads, so the more a road gets re-used, the lower the weight, the more likely it will get used again... this would create single pixel wide paths with a byte range of values, then the road intensity in the splatmap can be a function of those values, where 1 is a barely visible dirt track, and the highest values make wide asphalt freeways.

 

I don't think Unity is the best platform to make this in, it doesn't natively support TGA or 16bit images etc.

 

Its quite trivial to write your own 16 importer in Unity for raw arrays like the terrain here. Not sure about its import options for 16 bit greyscale pngs. Java can handle many different png formats. But im sure there is some C# library that can also do that.