GPU Terrains

Introduction

I’ve spent the last few days (yes, Christmas too…) working on a big refactory of the code of my programs, most of the code is Object Oriented now and I’m planning to make everything OO soon.

The changes

I’ve introduced 3 news classes:

• Shader : a vertex or a fragment shader, the code loads, compiles and manages a shader
• ShaderProgram : a shader program, it’s connected to two Shader
• PingPongTexture : a couple of textures needed by the Ping-Pong technique

Furthermore I’ve rearranged the shaders, now all the sources are in a separate directory and they can be easily used in both the programs.

Example of code

This code manages the erosion using the old code:

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fb);

vs = InitShader(GL_VERTEX_SHADER, “src/shad.vert”);
fs = InitShader(GL_FRAGMENT_SHADER, “src/shad3.frag”);
p = InitProgram(vs, fs);

tex0_loc = glGetUniformLocation(p, “Tex0″);
alpha_loc = glGetUniformLocation(p, “alpha”);

glUniform1i(tex0_loc, 0);
glUniform1f(alpha_loc, alpha);

for(int i = 0; i < eros_it; i++)
{
	glDrawBuffer(att_point[write_tex]);

	glActiveTexture(GL_TEXTURE0);
	glBindTexture(GL_TEXTURE_2D, tex[read_tex]);

	ShaderDraw();

	if(read_tex)
	{
		read_tex = 0;
		write_tex = 1;
	}
	else
	{
		read_tex = 1;
		write_tex = 0;
	}
}

This code manages the same stuff using the new code:

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fb);

p->AttachShader(eros1_shader);
p->LinkProgram();
p->UseProgram();

eros1_shader->SetUniformInt(“Tex0″, 0);
eros1_shader->SetUniformFloat(“alpha”, alpha);

for(int i = 0; i < eros_it; i++)
{
	pp_tex->SetDrawBuffer();

	glActiveTexture(GL_TEXTURE0);
	pp_tex->BindTexture(READ_TEX);

	p->Run(W, H);

	pp_tex->Swap();
}

The difference is really evident!

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.