FAQ  FAQ   Search  Search   Memberlist  Memberlist   Usergroups  Usergroups
Register  ::  Log in Log in to check your private messages

Post new topic  Reply to topic
 Editor - adjust the level of percision with the Grome editor « View previous topic :: View next topic » 
Author Message
PostPosted: Sun Apr 08, 2007 2:50 am    Post subject: Editor - adjust the level of percision with the Grome editor Reply with quote

Joined: 05 Apr 2007
Posts: 12

My engine currently:

- supports a png, bmp and jpg for the heightmap
- imports the heightmap and does not allow for and adjustment (e.g. scale or bias) for the input file
- recommends a maximum 1024 x 1024 height map

It is my understanding that:

- a png file is a 16 bit file
- a bmp and jpg file is a 8 bit file

My engine simply just imports the heightmap file. It does not prompt you for adjusting the bias or scale upon input. So whatever is written heightmap is the value used by the engine.

Is there any way to adjust the level of percision within the Grome editor? In other words, make it so that Grome does not render a terrain with a decimal point.

That way, I can see what the terrain is going to look like within Grome before I import it in my engine.

Information (from earlier post in another forum)

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?


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
View user's profile Send private message
PostPosted: Sun Apr 08, 2007 6:12 am    Post subject: Reply with quote

Joined: 12 Feb 2007
Posts: 1328

For now Grome editor doesn't allow adjustment of the level of precision (doesn't allow to change the data representation to integers). We are considering this for the next versions (is added in the todo list).

Now, what can we do for a momentarily solution? First, I suggest working in the 16 bit range (from 0 to 65000). Also try using almost all the range so you have enough precision.

Next save the raws without any transformation (bias zero and scale 1). Because you are using all the 16 bit range a fractional value (hopefully, we need to do some tests) will not be visible. 0.1, for example, is basically a small part of the 0, 65000 range (is 0.1/65000) so if it is lost the results are not visible.

To give you an example of the precision you lose. Let's consider you are using cm as units. So maximum terrain is 65000 cm which is 650 meters (which is ok for a altitude difference for a game inside a terrain zone). Now you can end up loosing maximum 0.5 units (because of number rounding). So you can end up with difference of maximum 0.5 cm (5 millimeters) in some places for the vertex heights. I think this difference is negligible (it wouldn't produce visible artifacts).

Now, if you really are worried about these small differences and need to see the results in Grome as in your engine (i.e. to force the precision), you can construct a plugin (a utility plugin) that is called from application menu and force the numbers to integers (get rid of the fractional part for the current scene terrain heights). Thus after you worked on a terrain, call this plugin and see the scene in the Grome as you see in your engine.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

Jump to:  

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

Based on a template by Dustin Baccetti
Powered by phpBB © 2001, 2005 phpBB Group