OK… I have tried all setup/file options I could find but I can not manage to pipe in a 16bit height field into WM, modify parts of it and then output it so that the unchanged parts of the height field have the exact same value as they did in the original source data.
Theoretically I assume it would work if I could set the Terrain Altitude Scaling to the maximum height value for a 16bit height field (64K) and then tell the file input to use the natural (file) elevations. Unfortunately the Terrain Latitude Scaling tops out at somewhere around 10K.
OK… slight progress. I am able to retain the original values now by setting the file input to ‘Natural (file) elevations’ and then the exported image is in the same colour space as the source data, however, the representation in WM itself is screwed up then as it sees the displacement as being far more subtle than it really is. This is not a huge problem apart from the fact that because it thinks there is very little height data in the file now all the sliders are not granular enough to actually work with the data. For example, I am feeding a Advanced Perlin generator into the terrain and in order to match it up nicely I need to set the Elevation center of the Perlin to somewhere around 200m, however, the slider will only jump between 133 or 267m and even inputing a specific value into the number field does not allow me to set it to any other height in between those values.
Any ideas? This has to be possible and people that actually work with real world data that needs to line up with real world data after processing must have encountered this so there must be a way to do this… unless nobody here actually works with real datasets…
You could modify your setup to look like the following:
[FI]--[S]-- your stuff --[inv(S)]--[FO]
were FI = File Input, FO=File Output.
The idea is to modify the scale, everything works on. S is some kind of transform and inv(S) is just the inverse transform. This transformation should change your heightfield into something you’re more comfortable working with.
For example use the following set up:
S is a Combiner in set to “root” with FI as the first input and a constant of full height as the second input and the “strength” of the combiner set to 0.5.
This will take the square root of the FI.
inv(S) is a Combiner set to “multiply” with full strength and both of it’s inputs come from your stuff.
What this does is it takes the loaded file, takes the square root of it - which causes all the low values to grow. The invS-Combiner multiplies the result of your network with itself - undoing the square root stuff you did at the beginning.
I have the exact same problem all the time.
What I do is very simple. I keep a copy of the original terrain pre WM. I set WM so that I can see all the elevations. I modify in WM. I export from WM. I use Wilbur to set the elevation range to the original file. Obviously I have to make sure that the minimum is not altered. Well fortunately for me, all my data has bathymetry which I’m yet to model, so I always have a minimum intact post WM.
What happens if the file output from WM is too large for a non tiling app? Well, I’ve encountered that problem yet but I’m sure I will soon. I also use L3DT and Global Mapper. L3DT can take a 20K single. Both it and GM have tiling capabilities. Use either L3DT plugin to read WM output tiles, or use hfz format (tiling, compression options) since both L3DT and Global Mapper support this…thanks to our great collaborative work on the new format at the Terrain Summit!! Bring back the TS!