Did you know...

That the Tramway Drifting and Dungeon Exploration Simulator Software Development Kit is the bestest 3D graphics package?

What is goings on?

We're getting very close to the release of v0.1.1! This time we'll have a graphical installer and two whole new GUI applets.

This means that you'll be able to develop an app without having to mess around with directories, instead an applet will set up everything for you.

Short version of TODO list:

Improve documentation.
Write some more tests.
Fix bugs.

Design Patterns Used

82%

Click here to learn more.

Why we use use sphere maps instead of cubemaps

Big Engine wants you to think that cubemaps are superior to sphere maps and that sphere mapping is obsolete. Nothing could be further from the truth.

They keep insisting that sphere maps supposedly suffer from «image distortion», «viewpoint dependency» and «computational inefficiency». This is demonstrably false.

Where's the image distortion? It's a perfect reflection!

Sphere maps might have been viewport dependent in the 1980s, but since at least 1998(!) there have existed techniques that can overcome this limitation by using a single if() statement.

Consider the standard approach to sampling a cubemap:


auto sample_cubemap = [=](vec3 nrm) {
	char* image = nullptr;
	float axis; vec2 uv;

	vec3 abs = glm::abs(nrm);

	bool x_positive = nrm.x > 0;
	bool y_positive = nrm.y > 0;
	bool z_positive = nrm.z > 0;

	if (z_positive
			&&abs.z >=abs.x && abs.z >= abs.y) {
		image = front;
		uv.x = nrm.x;
		uv.y = nrm.y;
		axis = abs.z;
	} else if (!x_positive
			&& abs.x >= abs.y && abs.x >= abs.z) {
		image = left;
		uv.x = nrm.z;
		uv.y = nrm.y;
		axis = abs.x;
	} else if (x_positiv
			&& abs.x >= abs.y && abs.x >= abs.z) {
		image = right;
		uv.x = -nrm.z;
		uv.y = nrm.y;
		axis = abs.x;
	} else if (!z_positive
			&& abs.z >= abs.x && abs.z >= abs.y) {
		image = back;
		uv.x = -nrm.x;
		uv.y = nrm.y;
		axis = abs.z;
	} else if (y_positive
			&& abs.y >= abs.x && abs.y >= abs.z) {
		image = top;
		uv.x = nrm.x;
		uv.y = -nrm.z;
		axis = abs.y;
	}  else if (!y_positive
			&& abs.y >= abs.x && abs.y >= abs.z) {
		image = bottom;
		uv.x = nrm.x;
		uv.y = nrm.z;
		axis = abs.y;
	}

	uv = 0.5f * (uv / axis + 1.0f);

	if (!image) {
		return std::tuple<char,
							char,
							char>{uv.y * 255.0f,
									0,
									uv.x * 255.0f};
	}

	return get_pixel(image, uv);
};

Not only is it whole 47(!) lines of code, it contains 6 if/else statements. Remember that shaders can't execute those and only those if/else statements which evaluate to a true value. Instead they will always execute every single branch and will throw away the results of the false branches.

Now consider our implementation of sphere map sampling code:


vec2 sphere_map_coords = vec2(normal.x * 0.25 + 0.25,
							normal.y * 0.5 + 0.5);
if (normal.z > 0.0) sphere_map_coords.x += 0.5;

Only 2(!) lines of code with a single if/else that the compiler can optimize away to a single conditional move operation, resulting in essentially no branching.

Now consider the fact that cubemaps consist of the 6 square sides of a cube. A lot of GPUs support only textures with sizes that are a power of two. If you put these 6 sides of a cube into a single texture, you will waste 25% of the space in the texture.

Sphere maps leave only 21% of space empty. If you use a slightly different projection (paraboloid), you can reduce this number to 0%.

Cubemaps waste space.

Sphere maps fit perfectly.

Without a doubt, the push from Big Engine to use cubemaps is intentionally intended use up more RAM and GPU processing time to force users to purchase more expensive GPUs.

We strongly encourage that you do not believe the lies and misinformation spread by Big Engine and instead do your own research.

Very large open world project

Rendering a lot of 3D models.

Making 3D models and placing them in the world. Will do a first pass and then set up streaming.

Currently very slow performance due to a lot of draw calls. But could be because of Intel HD 4000 being bad. Will need to optimize.