-
If you have a mod, tool or prefab, please use the Resources section. Click Mods at the top of the forums.
A19e Nitrogen - UNSTABLE
- Thread starter Damocles
- Start date
- Status
Damocles
New member
The topic was more about the prefabs details.
What I mean with tricky is less how the bridge has a smooth surface-terrain transition, and has more to to with matching roads to bridges (of fixed length) in a random map with random areas to bridge over.
Here there needs to be logic to:
-detect where a bridge should be placed
-have the road connect to both ends of the bridge
-create landfill for areas wider than the bridge
-have everything work in a straight line, as bridges can only be turned 90 degrees.
-place the bridge POI precisely and adjust the terrain as needed (so the ends of the bridge dont hang in the air)
Im also not super sure if the game will try to fill the area under the bridge POI automatically with terrain, as this would render bridges pretty useless.
Damocles
New member
NEW VERSION (same download link) v 0.253
Can use city and town spawers for the mask (to define make your own town and city layout)
within the mask you can set 3 predefined colors
#1 solid Red: RGB 255,0,0 (full alpha 255) -> City Spawner
#2 solid Green: RGB 0,255,0 (full alpha 255) -> Town Spawner
#3 solid Yellow: RGB 255,255,0 (full alpha 255) -> help color (ignored)
wherever you set a city or town color PIXEL, a city or town is preferred to spawn there
the generator will (from top-left to bottom right) scan for pixels and spawn a city or town ad long as there are more to spawn,
(if you set more pixels than the number of cities, it will just ignore the spawners, in this case set the number of cities to spawn higher)
If it can not find a pixel it will spawn a city or town on a random suitable location as before.
beware: only use SINGLE PIXELS, as each pixel defines a spawner!
To make editing the mask easier you can set a yellow help color around those pixels, to make them easier to find.
The help color is regarded as passable area (not blocking POI spawns)
There is an example mask in the resource directory showcasing the city and town spawners.
Can use city and town spawers for the mask (to define make your own town and city layout)
within the mask you can set 3 predefined colors
#1 solid Red: RGB 255,0,0 (full alpha 255) -> City Spawner
#2 solid Green: RGB 0,255,0 (full alpha 255) -> Town Spawner
#3 solid Yellow: RGB 255,255,0 (full alpha 255) -> help color (ignored)
wherever you set a city or town color PIXEL, a city or town is preferred to spawn there
the generator will (from top-left to bottom right) scan for pixels and spawn a city or town ad long as there are more to spawn,
(if you set more pixels than the number of cities, it will just ignore the spawners, in this case set the number of cities to spawn higher)
If it can not find a pixel it will spawn a city or town on a random suitable location as before.
beware: only use SINGLE PIXELS, as each pixel defines a spawner!
To make editing the mask easier you can set a yellow help color around those pixels, to make them easier to find.
The help color is regarded as passable area (not blocking POI spawns)
There is an example mask in the resource directory showcasing the city and town spawners.
Last edited by a moderator:
mr.devolver
New member
If detection is an issue, how about letting user manually place the mark so that Nitrogen would know where to put the bridge? Would that make it easier to start?
Also, I mentioned that thread because the bridge the OP showed in the screenshots looked like they could be repeated to make the actual bridge longer if needed and they do seem to have pillars for better stability, so making them longer shouldn't be an issue.
Damocles
New member
Lets see, I will add some logic eventually.
Currently, you could add the bridge POIs manually by editing the prefabs.xml
something like
<decoration type="model" name="bridge_asphalt1" position="654,41,-247" rotation="1" />
where the second parameter in position is the hight (wich you probably need to run some tests to find the correct one)
those are the bridge POIs currently in vanilla:
//bridge_10x10_end_01,BRIDGE,2,-1,10,18,10,
//bridge_10x10_tile_01,BRIDGE,2,-1,10,18,10,
//bridge_asphalt1,BRIDGE,2,0,39,11,11,
//bridge_asphalt_broken,BRIDGE,2,0,39,16,11,
//bridge_concrete1,BRIDGE,2,0,39,11,11,
//bridge_wood1,BRIDGE,2,0,39,11,9,
//bridge_wood2,BRIDGE,2,0,32,10,7,
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:
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.
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.
Last edited by a moderator:
^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.
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
New member
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).
Last edited by a moderator:
Damocles
New member
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.
Last edited by a moderator:
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
For those that used my little parser for the prefablist for NITROGEN:
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 :sulkiness:
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 :sulkiness:
Last edited by a moderator:
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.
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
Last edited by a moderator:
Damocles
New member
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)
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)
Last edited by a moderator:
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.
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.
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.
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
New member
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.
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.
- Status