


SDK example  determining the height of a tile 
« View previous topic :: View next topic » 
Author 
Message

speedcm 
Posted: Sat Apr 07, 2007 1:48 pm Post subject: SDK example  determining the height of a tile 


Joined: 05 Apr 2007 Posts: 12

The exptxt plugin source calculates the height for each tile to be:
int hm = (int)((heightmap[row + x] + _hm_raw_bias) * _hm_raw_scale);
The exptpt plugin provides the ability to scale and bias the heightmap range via the options button in the exporter GUI.
 Normalize terrain to Min_Value Max_Value
 Modify terrain by bias_Value scale_value
Here are my questions:
1. What is the definition of normalize terrain? If modify the value, what does it do?
2. What is the definition of bias and scale. If modify the value, what does it do?
3. In the source code, you will notice the variable name is _hm_raw_bias and _hm_raw_scale.
Is bias and scale only specific to the raw format? For example, is bias and scale applicable to determine the height of a tile for a .png file? 

Back to top 


ALicu 
Posted: Sat Apr 07, 2007 5:48 pm Post subject: 


Joined: 12 Feb 2007 Posts: 1328

Well, things are very simple and are caused by the fact that raw (and 16 bit png too) contains integer values (no decimal point). Grome, as many graphical application, works in floating point. Now, in Grome you can have a terrain that has a height to maximum floating point number (which is 3.402823466e+38F, that is 3.4 multiplied by 10 at 38 power which is a huge number). So you can have, for example, your terrain between zero (or a negative value) to 9999999.99. Now, in 16 bit raw you cannot represent this range. 16 bit unsigned integers are between 0 and 65535. Your single solution here is to take your bigger range and normalize it to this smaller range.
Normalization means taking a range and bringing its values to another range (so minimum value from first range is minimum from second, same with maximum).
The exporter offers two ways of modifying the current terrain range. By directly specifying the range to normalize to or by providing a bias (a value to be added) and a scale (a value to be multiplied). These are similar, there are only different ways of looking at the same calculus.
Basically, internally, the exporter is using only bias and scale (as seen from the formula above).
The exporter also helps you choose the bias and scale by providing the following information: the raw signed and unsigned representation range, the current scene range.
So, now some practical examples. Let's assume you have a terrain from 0 to 200 meters. Because in Grome you can work with floating point you can have heights with fractional numbers after decimal point (11.23, 0.03 etc).
Now, if you are to represent this with no transformation (you can do that by choosing 0 for bias and 1 for scale so your scene values remain the same at export) you end up loosing the values after the decimal point (11.23 is now 11 for example). That's because raws contain only integer numbers.
So, the solution is the following. Just expand the value so you bring fractal numbers at the right of the decimal point. So for example you can choose 0 as bias and 100 as scale. So you values are now in the 0 and 20000 (200*100) range. The 11.23 is now 1123 and no precision is lost.
But now you have the terrain 100 higher. Because the raw doesn't contain additional information about the scaling you, as the developer who saved the file must remember this value when you use the file again. For example. the raw importer has a scaling option so you scale you values before importing. In this case you will be using 0.01 (1/100) so you bring your values in the correct interval. Now 1123 becomes again the original 11.23 = 1123 / 100.
Now, the scaling can work in the opposite way too. It can be used to shrink the original interval. As state above, in Grome you can have very huge values but in 16 bit integers you are limited to 65535. So if you have a terrain with heights as big as 655350 you need to scale it down by 0.1 to bring it to the max representable number in raw files. This is a limitation of the raws (and png) as they contain only 16bit data. Of course, you will loose a lot of precision. 11.23 is multiplied with 0.1 and is now 1.123. And at export you will actually write 1. And then at import: 1 * 10 (you multiply with 10 to bring it back to the original range) = 10 instead of 11.23. So a loss of 1.23 units. Now all these tell us to not try to represent huge height intervals with 16 bit raws because by exporting and then importing we will not get the same result (we will obtain terracing as the values are discreticaly clamped).
The bias can be used when you save unsigned raws. These raws (and I believe that all other programs consider the raw files containing unsigned values and not signed even though Grome allows for saving signed raws) contain numbers above 0. So if you have a terrain that has its heights between 100 and 100 meters you may consider using a bias of 100 so you bring it in the 0 , 200 interval. Otherwise you will end up exporting only the above 0 values while all value < 0 will be clamped to 0. Again when importing back you should use a bias of 100. Or, if the exporter doesn't support bias, you should consider applying an elevation filter with 100 after import
The raw and bias are not specific to raws. They are specific to any data processing that needs actions so you don't loose precision and numbers due to data representation. 16 bit png will need these adjustments too. 

Back to top 


speedcm 
Posted: Sat Apr 07, 2007 6:26 pm Post subject: 


Joined: 05 Apr 2007 Posts: 12

One of the biggest reasons why I selected Grome was the people behind Grome!
The response to this question is clear, understandable and provides examples. What more can you want!
I am really amazed by the support behind this tool! Keep up the great work! 

Back to top 






Page 1 of 1 

You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum



