File Input Questions

Bug Reports
#1

Hello all,

I recently started using WM2, and have been trying to get a high resolution terrain created for use in Unity. I plan on using it solefy for a demo video, so I decided to just try and output the terrain found in the splat map creation project. My end goal is to create an 8x8 set of tiled terrains at 2049 x 2049 resolution each, which as you can probably imagine, will take a day or two. With that in mind, I decided to try and split the creation process into several steps.

The first step was to save the heightfield output after the first erosion and thermal weathering devices to a .r16 file, which was a simple matter.

The next step was to run that file through the second erosion device, and then save the three outputs (primary heightfield, wear map, and deposition map) to their own files. This is where I’m facing a problem. I have the three files, but when I try to bring the wear and deposition maps back into the chain via File Input devices, they don’t look like the same maps that were outputted (the maps shown when you click on the Height Output device). Instead of a black/whitish image, a brownish image with spikes is shown, and when I use these inputs to create an overlay, the overlay terrain does not look like it should.

I saved the deposition and wear maps as .r16 files. Is that the correct format for these type of maps, or does it matter? I saw something about doing a y-projection on a wear map input, but I have no idea what that is. The provided images show the device chain and wear map output/input in the 3d-view. Please, any help would be greatly appreciated!

On a side note: I also tried outputting a ARGB splatmap as a bitmap, and then tried to bring it back in via a File Input in order to use it to make a tiled build, however it did not work. If I have a ARGB bitmap, can I just link it to a Bitmap output for use in tiled build? Or do I need to take the bitmap input and split it into A and RGB (via channel splitter), then route those into a new bitmap output (running the RGB into a channel combiner first, seems redundant?)? If so, how do I get the alpha from the bitmap? Thanks!

#2

Hi there,

World Machine “knows” that mask outputs are generally not used as terrains, and so it displays them as greyscale masks. If you re-import them, you have to flag those devices directly to display as a mask. To do so:

Select your file input device
Right click and choose “Set Device Display Hint”->“Mask”

In any case it should behave the same when used – the display hint is purely for visualization. R16 should be a fine format for storing masks.

Unfortunately, the file input device doesn’t currently import the Alpha channel. This is an oversight that is going to be on my next feature sprint list – you will then be able to get the alpha from the extents mask output, however currently there is no way to do this.

#3

Thank you for the quick response! I set the mask to hint and it is now displaying correctly in the overview when the file input is selected, but now I can see for sure there is something off. When imported back into WM, the wear and deposition maps have significantly less white in the image. I’ve attached screenshots showing the wear map output vs input, as well as images showing what the terrain looks like in 3D view when using file inputs for the wear/deposition map, vs what it looks like when using the normal chain without file input devices.

Thanks again for the help!

#4

There should be no difference between the output and the same file loaded back in. Are you 100% certain that you’re outputting your masks directly, without any additional processing? The one loaded from a file looks like it has been equalized with an Equalizer device before being exported. Double check that the files are not from some earlier world, and that they are being created and exported correctly.

Last ditch, post your world file here!

Cheers

#5

Yes, both the wear and deposition maps are run through separate equalizer and clamp devices before being outputted. I didn’t think that would be a problem. They’re run through the same devices in the normal Splatmap_Converter chain. Both the equalizer and clamp devices output heightfields, so I was under the impression I was just “saving the chain” with the output device and picking up where I left off from with the file input devices.

Also, I’m pretty sure I originally tried to output the wear and deposition maps directly (without running them through the equalizer and camp devices), and then run the file inputs through those devices. I can’t remember exactly what the result was, and I hadn’t set the hint to mask at that point, but I don’t think it worked correctly.

I am going to do some test with lower resolution to see if I can figure out what’s going on. In the mean time, I am providing the .tmd, just be aware, the resolution is currently set to 16385!

#6

Here is another tmd better showing the issue. There are two groups in this tmd, the bottom group is the normal chain found in Splat_Converter.tmd, while the top chain uses file inputs.

There are very slight differences between the two methods, as can be seen when you click on the overview device for each group. Obviously I am doing something wrong with the file input method. Any thoughts?

Thanks again for the quick help. It goes a long way to making me feel confident in my purchase of WM2 Pro, and will definitely encourage me to recommend your product to others!

#7

In the latest device network posted, I can provide a few pointers that will provide perfect reproduction across the file boundary:

  1. The first thing to be aware of is that the results of a low res preview, and a high res final build rescaled down to low res, can be different.

A big part of the problem stems from this – the preview will show a difference that is not, in fact, there, if you look at the final full resolution results. This is an easy thing to get tripped up over, the safe solution is to always inspect and compare the final build results in the 3D view, not the preview.

In terms of making your preview life simpler, there is no way around this unfortunately. Imagine the erosion device – you will surely get different results from a 128px heightfield eroded, where the streams represent some large number of meters of worldspace, than the same world eroded at 8192px where the streams are very narrow (much narrower than can even be represented at 128px), and then averaged down to 128px. They will be similar, but definitely not identical, especially after Equalization which amplifies differences.

The good news is that this is only a preview issue and does not effect the final results!

  1. The way it was setup was to Equalize after the file was exported – unfortunately, the natural erosion outputs are full of very low-amplitude results and 16bit RAW doesn’t have enough definition to capture them adequately. The solution is to either Equalize before export (preferred) or use 32bit raw output.

After fixing #2, and inspecting the results at full resolution, there is no difference between the all-natural device chain and the one that exported and re-imported (although the preview window will make it appear so!)

EDIT: Added more details…

#8

I got it to display the same results as well after moving the equalizer. Thank you so much for the help!

#9

raeltyalSex@craftsy.site

#10