Map Editor: Problem with distributions

Hi,
I get different results from "Rebuild Terrain" and "Rebuild Visible". The difference is that "Rebuild Terrain" will not place some of my distributions, often even leaving many areas blank. See this image for an example:

different results from build options:
different results from build options

So to get my Level with all distributions, I could theoretically use "Rebuild Visible" all over the map, wich is, what I'm doing right now. But the Problem there is, that Rebuild Visible creates many little tearings or cracks on the edges of my scene view. This happens everytime I use it, especially in the water, see:
cracks from rebuild visible

Does anybody else expericence the non-placement of distributions by "Rebuild Visible"? Can it be fixed?
Or in general, how do you cope with the differences of build options?
Is there a way to keep "Rebuild Visible" from making cracks?

@Peter_2 afaik Mudrunner-editor Rebuild-visible is flawed, and you should always only use rebuild-terrain
May i ask what editor you are using?

@aMuddyHand said in Map Editor: Problem with distributions:

May i ask what editor you are using?

I use the regular Steam Version. I noticed in the properties of the editor on steam, under "Betas", I can also switch to a beta version of the editor. Might that be worth a try?

@Peter_2 afaik Mudrunner-editor Rebuild-visible is flawed, and you should always only use rebuild-terrain

But without rebuild visible I'd never get those dry trees you can see in the image above, rebuild terrain doesnt render them. I layed out the distribution for those trees, but it's only rendered by rebuild visible, and not by rebuild terrain (they immediately vanished if I run rebuild terrain). So rebuild terrain is flawd as well, right?

I also noticed that rebuild visible seems to be bettter at rendering multiple overlayed distributions. This becomes very apparent to me when I do forests.

last edited by Peter_2

@Peter_2 said in Map Editor: Problem with distributions:

I use the regular Steam Version. I noticed in the properties of the editor on steam, under "Betas", I can also switch to a beta version of the editor. Might that be worth a try?

Try that, yes -Do you about the MudRunner mapBook:
http://www.mudrunnermods.com/spintires-mudrunner-map-making-big-book/
He really knows the editor!

But without rebuild visible I'd never get those dry trees you can see in the image above, rebuild terrain doesnt render them.
Outch! Is that error also in the saved/ build map?

Is the objects also missing in the finished map, opened in mudRunnerGame?

I also noticed that rebuild visible seems to be better at rendering multiple overlayed distributions. This becomes very apparent to me when I do forests.

Again is it 'only' an editor fail, or are the fail also present in the final map?
Of cause these issues could have been addressed in the beta-editor, so try that.
I am so sad that map-building is not possible with the EPIC-engine πŸ˜”

@aMuddyHand said in Map Editor: Problem with distributions:

@Peter_2 said in Map Editor: Problem with distributions:

I use the regular Steam Version. I noticed in the properties of the editor on steam, under "Betas", I can also switch to a beta version of the editor. Might that be worth a try?

Try that, yes

Didn't work, I don't even have a beta key πŸ€¦πŸ»β™‚

Do you about the MudRunner mapBook:
http://www.mudrunnermods.com/spintires-mudrunner-map-making-big-book/
He really knows the editor!

yes, i read it. unfortunately, it doesn't say anything about my problem. but it does say, that rebuild terrain should be used. but it doesn't mention, that rebuild visible and rebuild terrain produce different output.

But without rebuild visible I'd never get those dry trees you can see in the image above, rebuild terrain doesnt render them.
Outch! Is that error also in the saved/ build map?

Is the objects also missing in the finished map, opened in mudRunnerGame?

yes. There will be no trees at that spot ingame, if I build with rebuild visible

I also noticed that rebuild visible seems to be better at rendering multiple overlayed distributions. This becomes very apparent to me when I do forests.

Again is it 'only' an editor fail, or are the fail also present in the final map?

see above. it's ingame.

Of cause these issues could have been addressed in the beta-editor, so try that.

no keyfor it πŸ˜”

Well, I'll see for my next map, to reinstall the editor and then only use rebuild terrain from the beginning. Maybe then, if i'm lucky, the problem will not appear again.

But it can't be helped with my current map, because if the vegetation distributions aren't exactly like I get them with rebuild visible the detailed little roads and some other stuff doesn't work anymore... so I'll probably publish it with the little rippings/tearings rebuild visible produces. It's just cosmetic anyway, but a pity none the less.

last edited by Peter_2

Try this:
Make a dummy map
Then add the problem trees to that test-map, but this time do not use rebuild visible, but instead use rebuild terrain. Even though you cant see the newly added object, just save the map!
Then open that in a new game. It may be that you cant see everything in a distribution as you make them, but they may be in the final map, but only if you use rebuild terrain
Afash understood the Big-book, rebuild visible should never be used, at all.
That tiny testmap can answer whether or not those trees can be used in the distribution.
If it fail again, then try adding the trees to a distribution of either their own, or with some different objects. It may be that the distribution you have tried to make, conflicts with the chosen objects. He writes something about plants and stones, that cant be in the same distribution. It could be the same for your tree-stumps.

I suspect that "Rebuild Terrain" is following a subtle rule that prevents the trees from being distributed, whereas the sloppy "Rebuild visible" happens to produce the trees that you want even though doing so isn't technically correct. E.g. from the BBMMM: "By default, plants are not distributed in water, on a road, or in mud. [...] You may occasionally see plants being drawn in water, on a road, or in mud even when these checkboxes are not checked. This often occurs because the editor has drawn the distribution quickly and sloppily. To fix it, choose 'Rebuild Terrain' from the context menu."
From your screenshots,. it doesn't look like water or roads should be the problem, but mud might be.

Also, "Plants are never distributed [...] on a material that excludes the plant." Try changing the ground materials to see if one of them is preventing your trees.

BTW, the official source for the Big Book of MudRunner Map Making is on Steam.

@aMuddyHand Did a dummy map and experimented a little bit...

@Chris-Nelson said in Map Editor: Problem with distributions:

I suspect that "Rebuild Terrain" is following a subtle rule that prevents the trees from being distributed, whereas the sloppy "Rebuild visible" happens to produce the trees that you want even though doing so isn't technically correct. E.g. from the BBMMM: "By default, plants are not distributed in water, on a road, or in mud. [...] You may occasionally see plants being drawn in water, on a road, or in mud even when these checkboxes are not checked.

THIS is it. Basically my confusion came from 1.) rebuild visible set's "ignore mud/water/overlays" to TRUE for EVERY distribution. rebuild terrain obeys to the way you actually set these settings. And 2.) I didn't really know about the "ignore mud/water/overlays" settings for dists in the first place, or least didn't mind them, until now. Turns out they are the solution to my problem.

So now I set almost all "ignore mud/water/overlays" settings to true for all distributions, and that way, I now get the same build results with rebuild terrain as with rebuild visible. Just a few odd trees and bushed here and there, but that was basically it.

Problem solved!

Thanks guys. I super happy, finally I can map the way I want. πŸ˜„

last edited by Peter_2

@Peter_2 said in Map Editor: Problem with distributions:

finally I can map the way I want. πŸ˜„

How about the topology? Do you use geo-identical satellite data?
You can get something like this:
alt text
It is not very difficult.
That is what i wanted to do, if only i could map with EPIC's release, but cant
Here is a different geo-identical
alt text
That is from Botniska bugten in Sweden

@aMuddyHand said in Map Editor: Problem with distributions:

How about the topology? Do you use geo-identical satellite data?

Yes , I experimented with editing the _height.dds file the other day. It kind of works, but I couldn't get the value range right, for Mudrunner Editor to correctly represent the topology. I couldn't get a good heightmap image yet. The image I used has been shaded, so the values have to much contrast, and then you get lots of "heightmap packing overflow" errors in the editor.

But the workflow is working, see:

base image for height.dds
07a5cb27-28b5-4350-a701-7712f7544f0a-grafik.png

Result in Editor:

5d14b613-8628-4232-a720-a05ad5d5a3c1-grafik.png

37bc1c99-4ab7-479f-8f4f-79216690d317-grafik.png

As you can see, everything is a little too spikey. I'd have to test with real digital surface model from a TLS laserscanning data to get it right.
Another tricky part would be, to ensure no heightmap overflows can occur in the map editor.

But, in general, it can be done.

last edited by Peter_2

@Peter_2 The heightmap has to much contrast, and that causes those spikes
The difference is significant. Here is too much contrast:
alt text
And here the contrast has been eliminated:
alt text
I have one here you could try.
That is a dds in 10801080, that means that the image is 10811081. That pixel is needed to avoid tearing in Havoc-engine
![0_1613063266910_terrain 1081.dds](Uploading 100%)
Look like it wont let me upload .dds..
terrain 1081.zip
Works with the image zipped i think
Can the editor use that .dds ?
it may be that it need an other color-depth, even for gray-scale. I do not know why Focus' own _Height files are corrupted .dds-files, that is so odd..

@aMuddyHand said in Map Editor: Problem with distributions:

terrain 1081.zip

When I open this in Gimp, I get this 1084x1084 graphic + its mipmaps
236d5eef-1d94-46b4-b61b-626738adfc67-grafik.png

Tha graphic has 3 channels with different RGB data. The Problem is, Mudrunner Editor only uses one channel (red) to read height data. So I can't put this dds in a map when it's like this (I tried, it results in the error "unsupported format*).

I was able to resize the channel to the next best map size, that is supported by the editor, which is 1105x1105 and then just use one of the channels, which produces this:
55b0b1b7-8635-42e0-99c0-1661688ac4a1-grafik.png

...and finally with some contrast stretching and gaussian blurring:
1f52b9a0-262c-4bdc-8bda-51aa04573fc0-grafik.png
But this is missing detail, since it's just one of the 3 original channels.

This little experiment actually taught me a lot. You need to stretch the image histogram to really get the appropriate heights into the map, which makes sense.
And gassian blur can reduce the heightmap overflow errors, but obviously it removes detail in the process...

@aMuddyHand said in Map Editor: Problem with distributions:

I do not know why Focus' own _Height files are corrupted .dds-files, that is so odd..

They are not corrupted. The program(s) you use to open them, probably do not support R16F DDS format.
From the BBOMM under "Hand Edit the DDS Height Bitmap":
"The MudRunner Editor stores the terrain height in _height.dds in R16F format. DDS isn't natively supported by many image tools, and R16F isn't well supported even by some DDS tools."
The Book also describes a way to convert them to PNG, to be able to edit them in gimp. The Mudrunner editor itself can then be used to convert your PNG back to a R16F DDS. I do it like that all the time, since gimp too can't read or write R16F DDS. It works.

last edited by Peter_2

@Peter_2 said in Map Editor: Problem with distributions:

The Problem is, Mudrunner Editor only uses one channel (red) to read height data. So I can't put this dds in a map when it's like this (I tried, it results in the error "unsupported format*).
That was not good, but what you wrote later makes it fine again

contrast stretching and gaussian blurring:
1f52b9a0-262c-4bdc-8bda-51aa04573fc0-grafik.png
But this is missing detail, since it's just one of the 3 original channels.

Yes it does not look good.

You need to stretch the image histogram to really get the appropriate heights into the map
gassian blur can reduce the heightmap overflow errors, but obviously it removes detail in the process...

Important to know!

They are not corrupted. The program(s) you use to open them, probably do not support R16F DDS format.

It was irfanView, it usually shows all images formats

MudRunner Editor stores the terrain height in _height.dds in R16F format. DDS isn't natively supported by many image tools, and R16F isn't well supported even by some DDS tools."*

Very important info!

The Book also describes a way to convert them to PNG, to be able to edit them in gimp. The Mudrunner editor itself can then be used to convert your PNG back to a R16F DDS. I do it like that all the time, since gimp too can't read or write R16F DDS. It works.

That is a super observation! Then it is possible to use pure png-data, and that is so much better, maybe that will deliver a useable detail-level
'Here' is the terrain-data in merged channels and in png
[0_1613138065584_terrain_channelMerged.zip](Uploading 100%)
Well i cant upload here "too big -error"
Have to use a fileshare, so DO scan for virus!
https://www.sendspace.com/filegroup/lOYHMCoqn1xl1cB9b0H8ow
I include a zipped image, in case..

@aMuddyHand said in Map Editor: Problem with distributions:

It was irfanView, it usually shows all images formats

Well, usually. I use IrfanView too. It can read 8bit and 16bit DDS files, if you install the additional plugins. This is for example the case for the level dds files (like level_mylevel.dds) from mudrunner editor. But it can't read R16F DDS, which is e.g. the "_height.dds" file.

That is a super observation! Then it is possible to use pure png-data, and that is so much better, maybe that will deliver a useable detail-level
'Here' is the terrain-data in merged channels and in png
https://www.sendspace.com/filegroup/lOYHMCoqn1xl1cB9b0H8ow

Your image is a 1-channel greyscale 16-bit PNG. I think in this image, you merged all channels to one channel? But the image actually needs 3 channels, of which the red one contains the height data. It has to be 3-channel RGB 16-bit PNG.

Also, your image is very dark.
1b1009c3-4bde-4961-ae3f-616749dde3ef-grafik.png

If it's just relatively dark values like that, the map will be very flat. lighter pixel mean higher altitude in the map.

In order to have actual height in mudrunner, the channel should probably look more like this:
b931ab11-eb02-40fa-afe6-8bbb381d2e82-grafik.png
I created this by contrast/histogram streching your greyscale channel.

So I think, alongside the channel issue, there may also be another error in your conversion process. Dunno.

If I use above stretched image as _height.dds, I get this, which is still kind of spikey.

e8a4fece-a354-4c58-9692-d9fd1ae977af-grafik.png

last edited by Peter_2

@Peter_2 said in Map Editor: Problem with distributions:

If I use above stretched image as _height.dds, I get this, which is still kind of spikey.

Yes its spiky because you enhanced brightness. How does my dark image look as terrain, have tried?
In Havoc, and Irrlicht (c++ game engine) The dark image is what is to be used, if a smooth topology should be the result.
Anything over ~v150(rgb) would be everest πŸ™‚

@aMuddyHand said in Map Editor: Problem with distributions:

How does my dark image look as terrain, have tried?

Yes I tried. It looked similar to the flat one I posted earlier.

@aMuddyHand said in Map Editor: Problem with distributions:

n Havoc, and Irrlicht (c++ game engine) The dark image is what is to be used, if a smooth topology should be the result.
Anything over ~v150(rgb) would be everest

I guess theres not much we can do about it, then. We'd need to start from the same raw geodata, to get matching results.

@Peter_2 said in Map Editor: Problem with distributions:

@aMuddyHand said in Map Editor: Problem with distributions:

How does my dark image look as terrain, have tried?

Yes I tried. It looked similar to the flat one I posted earlier.

Oh c*** that is really nit good! Well it 'kind' of swipes my grief about not being able to map, because i wanted to map geo-identically. Now it looks like Focus-map-engine cant πŸ˜•

I guess theres not much we can do about it, then. We'd need to start from the same raw geodata, to get matching results.

Maybe NASA datasets will be better. They are however not as plentiful as the ASTRA-sat-data..
This dataset has more height differences. It is Sweden @ StorsjΓΆn
I have greatly reduced the area so there should only be ~ 4 km2, witch is the smallest area available for ASTRA-data
[0_1613317848875_StrorSjoenTraesk terrain.zip](Uploading 100%)
but still to large for this site
need sendspace https://www.sendspace.com/file/s5l4jy

If this also looks uninteresting, then Focus-nap-editor cant use ASTRA-data πŸ˜•

last edited by aMuddyHand

@Peter_2 said in Map Editor: Problem with distributions:

@aMuddyHand said in Map Editor: Problem with distributions:

How about the topology? Do you use geo-identical satellite data?

Yes , I experimented with editing the _height.dds file the other day. It kind of works, but I couldn't get the value range right, for Mudrunner Editor to correctly represent the topology. I couldn't get a good heightmap image yet. The image I used has been shaded, so the values have to much contrast, and then you get lots of "heightmap packing overflow" errors in the editor.

But the workflow is working, see:

base image for height.dds
07a5cb27-28b5-4350-a701-7712f7544f0a-grafik.png

Result in Editor:

5d14b613-8628-4232-a720-a05ad5d5a3c1-grafik.png

37bc1c99-4ab7-479f-8f4f-79216690d317-grafik.png

As you can see, everything is a little too spikey. I'd have to test with real digital surface model from a TLS laserscanning data to get it right.
Another tricky part would be, to ensure no heightmap overflows can occur in the map editor.

But, in general, it can be done.

I experimented with this editor too, but I couldn't achieve even this quality of the heightmap image.
So it seems like a great result to me. Some of my works turned out to be more successful. In parallel with this, I was writing a work about editors and I needed to attach this work as an example. https://www.topwritersreview.com/reviews/justdomyhomework/ this is a review of the site that helped me with this. Because I know even less about writing than about this, and such difficulties often arise.

last edited by RichardHoward