GPU Terrains

Introduction

These are the benchmarks of the Circles algorithm using 16-bits floating point textures.

All the tests are made using 800×800 GL_RGB16F_ARB textures.

Circles algorithm benchmarks

The following data are the execution times needed to complete a different number of iterations of the generation phase, for each group of iterations you can see the slowest, the average and the fastest time on 10 tests.

iterations = 100 -> min = 84 ms. - avg = 85 ms. - max = 85 ms.

iterations = 250 -> min = 207 ms. - avg = 208 ms. - max = 210 ms.

iterations = 500 -> min = 411 ms. - avg = 412 ms. - max = 417 ms.

iterations = 1000 -> min = 819 ms. - avg = 820 ms. - max = 820 ms.

iterations = 2000 -> min = 1636 ms. - avg = 1636 ms. - max = 1637 ms.

The following data are the execution times needed to complete 1 iteration of the first technique of erosion, here you can see the slowest, the average and the fastest time on 10 tests.

iterations = 1 -> min = 1 ms. - avg = 2 ms. - max = 2 ms.

The following data are the execution times needed to complete 1 iteration of the second technique of erosion, here you can see the slowest, the average and the fastest time on 10 tests.

iterations = 1 -> min = 2 ms. - avg = 3 ms. - max = 3 ms.

Some final notes

The generation using floating point textures is about 37~40% slower than the 8-bits version, and the erosion times are about the same, this means that the use of floating point textures is reasonable to fix the white-regions problem.

Introduction

This post discuss the use of floating point (16 bits) textures with the Circles algorithm.

Results summary

Using floating point textures  gives a good improvement because it fixes a problem that affects several maps generated with this algorithm. In fact, when the number of iterations is bigger than 500 or when some parameters like the radius of the circle are bigger than the default values, the map shows several white regions.

Thanks to floating point textures and to the normalization phase those regions are normalized and all the maps are usable.

Some examples

This is a terrain of type 2 generated by 500 iterations using a 16-bits texture before (left) and after (right) the normalization phase:

It’s possible to notice the white regions in the first image.

This is a terrain of type 1 generated by 1000 iterations using a 16-bits texture before (left) and after (right) the normalization phase:

Also here it’s possible to notice the white region in the first image.

Introduction

These are the benchmarks of the Fault Formation technique using 16-bits floating point textures.

All the tests are made using 800×800 GL_RGB16F_ARB textures.

Fault Formation benchmarks

The following data are the execution times needed to complete a different number of iterations of the generation phase, for each group of iterations you can see the slowest, the average and the fastest time on 10 tests.

iterations = 100 -> min = 78 ms. - avg = 79 ms. - max = 80 ms.

iterations = 250 -> min = 193 ms. - avg = 194 ms. - max = 194 ms.

iterations = 500 -> min = 383 ms. - avg = 384 ms. - max = 385 ms.

iterations = 1000 -> min = 766 ms. - avg = 767 ms. - max = 768 ms.

iterations = 2000 -> min = 1527 ms. - avg = 1529 ms. - max = 1530 ms.

The following data are the execution times needed to complete a different number of iterations of the erosion phase (blur radius = 10), for each group of iterations you can see the slowest, the average and the fastest time on 10 tests.

iterations = 1 -> min = 23 ms. - avg = 24 ms. - max = 25 ms.

iterations = 2 -> min = 41 ms. - avg = 42 ms. - max = 42 ms.

iterations = 3 -> min = 58 ms. - avg = 59 ms. - max = 60 ms.

iterations = 4 -> min = 76 ms. - avg = 77 ms. - max = 79 ms.

iterations = 5 -> min = 94 ms. - avg = 96 ms. - max = 98 ms.

iterations = 6 -> min = 111 ms. - avg = 113 ms. - max = 114 ms.

Some final notes

The generation using floating point textures is about 49~56% slower than the 8-bits version, and the erosion is about 14~28% slower, this, together with the less realistic maps generated, makes the use of floating point textures not the better choice for this algorithm.

Introduction

This post discuss the use of floating point (16 bits) textures with the Fault Formation algorithm.

Results summary

Using floating point textures don’t give a real improvement to the Fault Formation technique, in fact the terrains generated using fp textures are usually too homogeneous and are made mostly of high values (light gray/white pixels), usually these terrains require one of the two erosion algorithms showed in the circles algorithm post to be more realistic.

For these reasons, and for the higher execution times caused by the fp data, I think that the fp textures are not a good choice for this technique.

Some examples

This is a terrain generated by 500 iterations using a 8-bits texture (left) and a 16-bits texture (right):

These images are the results of 6 iterations of blur (blur radius = 10) and of the second erosion technique from the circles algorithm on the terrain generated with the fp texture:

As it’s possible to notice the final image is similar to the result of the generation/erosion process with the 8-bit texture.

This is the terrain generated by 1000 iterations using a 8-bits texture (left) and a 16-bits texture (right):

These images are the result of 6 iterations of blur (blur radius = 10) and of the second erosion technique from the circles algorithm on the terrain generated with the fp texture:

In this case the 8-bits and the 16-bits textures give two really different terrains.

Introduction

Here I’m going to discuss about floating point textures and relative errors you can get using the different internal formats, furthermore I’m going to explain why I don’t really need full floating point precision for my project.

Texture internal formats

When you use a “standard” internal format for a texture, like GL_RGB for example, each component of the texel (usually) has 8 bits and the stored values are floating point values clamped to the range [0.0, 1.0].

So what to do if you need more accuracy and a not-clamped value? You have to use the internal formats defined by the GL_ARB_texture_float extension.

The texture float extensions offers two kind of floating point textures, the first one uses 16 bits for each component and the second one 32. An example of the first kind of format is GL_RGB16F_ARB, this internal format uses 3 components for each textel and 16 bits for each component (so 6 bytes for each texel). An example of the second kind of format is GL_RGB32F_ARB, this internal format uses 3 components for each texel and 32 bits for each component (so 12 bytes for each texel).

Accuracy errors

Usually a floating poit value uses 32 bits, so using less bits means less accuracy so some rounding errors, I’ve run some test so to understand how much this error could be.

I’ve used the following code to generate the texture data

float inc = 0.01;
float val = 0.0;

for(int i = 0; i < n; i++)
{
 	val += inc;

 	if(val > 1.0)

 	 	val /= ((rand() % 9) + 1);

 	data[i] = val;
}

This code fills the array data with growing values from the range [0.0, 1.0], the inc variable determines the increment of the values at every iteration, I’ve chosen the value 0.01 because is the lowest value that it’s used in the developed generation algorithms.

Then I’ve created the textures using the array data as image data and after that I’ve retrieved the stored data using the function glGetTexImage, finally, I’ve computed the percentage error using the formula:

rel_err = (100.0 * abs(tex[i] - data[i]) / data[i]);

These are the results of my tests:

GL_RGBA - 8bits components

elements = 40000 - avg err = 0.209%
elements = 160000 - avg err = 0.207%
elements = 360000 - avg err = 0.206%
elements = 640000 - avg err = 0.206%

GL_RGBA16F_ARB - 16bits components

elements = 40000 - avg err = 0.016%
elements = 160000 - avg err = 0.016%
elements = 360000 - avg err = 0.016%
elements = 640000 - avg err = 0.016%

of course the 32-bits format gives a 0% error.

Floating point textures in my project

Do I really need floating point textures? Yes and no.

I don’t need them for the accuracy, because the 8-bits format gives me good results and very short execution times, if I would to analyze the problem better, I can say that the minimum percentage error required to have a wrong pixel is abs(254 - 255) / 255 * 100 = 0.392% and this error is bigger than the average error I got from 8-bits textures, so, on the average, I can’t have wrong pixels in my height-map.

Furthermore my work is based on pseudo-random generations, noise, erosion and etc. so a value that’s slightly different from what it should be can be considered a feature, not a bug

But… I need floating point textures because for some algorithms I need not-clamped values as I’m going to show in my next posts, so all I need is the 16-bits texture because it gives me not-clamped values and an insignificant rounding error.

So the better solution for my project is to use both 8 and 16 bits textures and leave the user the possibility to choose what accuracy he needs for his generations.