I just replied in the Yahoo list, but I try not to do a simple copy / paste.
In my opinion World Machine now does the terrain output correctly, no bug, no issue. Just in another way how we experienced it before in older WM versions. Following the terrain specification, it now does use the full 16 bit. So, I am in doubt if an optional checkbox is a good idea. It would mean a loss of accuracy.
So, letās have a look how the height values are calculated. First important value is Base Height. Second is Height Scale. Following a row of many 16 bit values. Example:
Base Height = 100 (terrain units, not meters)
Height Scale = 30
āManyā 16 bit integers: Range from -32768 ā¦ 32767
For those who are interested to analyze terrain file information, I recommend to download TerrainScout. No, this is not hidden advertisement.
When you open that terrain in Terragen, there will be shown a height range of 70 ā¦ 130 ( = 100 - 30 ā¦ 100 + 30). Terragen always finds a combination of Base Height and Height Scale, whereas World Machine always uses Base Height = 0. Thatās the reason for the discussion here.
Btw, Terragen itself also uses negative values (try generate + canyonize), there is no rule that āforbidsā that.
Apologies to Stephen, it was not my intention to cause such trouble.
well, hmmm 3 days ago, my terrains didnt have any issues, and didnt have any loss of accuracy, and then stephen releases this version of WM with extra accuracyā¦
thats all fine, but my terrains looked fine without the precision, so yes, an optional check box is still a good idea, its not like the terrains were in absolute need of this extra bit of precision, or matt and stephen would have been using this information years ago.
It may not be visible at once - but one more used ābitā (=1/8 byte) means a doubled accuracy.
Still I believe, if it is possible to set the terrain height in tg it is also possible to automatically set it in wm.
Time for WM v1.251 :twisted: - just kidding. Every day I find more wishes from users, that have been fulfilled in 1.25 Even āmyā bugs :mrgreen:
Well I only just noticed the negative values last night. I personally am more than delighted to have this extra option available to me in Terragen. Thanks Stephen excellent.
You can easily avoid the āproblemā by clamping your result from 0.5 to 1.
The terrain will have the height set in WM and begin at 0m.
There shouldnāt be much loss of precision, because wm is working with 32bit. By clamping as described, you reduce it to 31bit which is still more than necessary, because a .ter file canāt have more than 16bit anyway.
Although I do agree that this should be optional or at least made consistent with previous WM versions, Iād like again to make it clear that the full 16 bit range was always supported by TG, and TGās native terrains have always (as far as I know) occupied this full range. This is not āextraā precision. It is in fact World Machine finally becoming fully compliant with the .ter file specification. The only reason it is strange is actually because of the way the .ter format is constructed, using signed values, with the full 16 bit range from -32767 to +32676 (or therabouts), rather than 0 to 65535.
I believe it can be corrected for by WM itself and the behavior should be made consistent with previous versions in the next WM update, but only for compatibility and consistency reasons. I donāt think thereās a real reason that this is a problem aside from user expectation. If no previous WM version had existed to define an expected behavior, this would not be a big deal. After all TG itself tends to create negative values with its own terrain generation in many cases.
So 90% of every terrain I make is below water level. And this is some how a good thing? I know itās an easy fix, but why should I have to?
Iām sorry, but itās a bit agrivating to make a terrain in WM thatās 0 to 5000m, then open it in TG to have a terrain thatās -3500 to 1500m. So Iām right back to what I was doing with the old WM, readjusting terrain hights in TG.
Even āmyā bugs :mrgreen: