Hello All,

New to the forum and new to game development in general. I started taking a computer graphics class at MIT OpenCourseware to get the lay of the land. I'm an engineer (aerospace) by trade, and have little classical training in low-level languages. I'm learning more about C++ and OpenGL concurrently. Learning by doing.

The first assignment was to load a .obj file and make it rotate, change its color, etc... I expanded this assignment to include include a typical FPS type camera movement, like a minecraft style camera with no gravity, floating ominously in empty black space... Fixing that is where I'm running into issues...

I've since figured out how to display a relatively simple surface. It is a 3D sine wave F(x,y) = sin(x) + sin(y). I create an equally spaced mesh in x and y and calculate a z. I collect all the vertex information and use GL_QUADS to render my polygonal surface. This works great, except when I try to render too many polygons. This is my first problem:

How do I efficiently store this data? Is there an "industry standard" way to store/render a 2-d mesh of data? I can't think of any other way to render a hilly landscape than to do some sort of 2D meshgrid and map an altitude (Z-axis) to it.

My implementation has 3 parts:

Vec_V, which is a vector of type Vector3f which stores 3 floats, being the xyz coordinate of the vertices

Vec_N is the same, except it stores the normals

Vec_F is vector<vector<unsigned> > . Each element is a group of 4 integers, which are the vertex indices that go together to make a quadrilateral.

I then use all of these vectors to render all of the quads I used to make the surface. My code breaks when N is large (more than 3000ish), where N is the length of the mesh grid (N * N = number of vertices, (N-1)*(N-1) = number of quad elements).

Is that implementation reasonable? I know there is plenty of room for improvement. Using simpler data structures can help. Using quad strips instead of quads can reduce my data.... Any advice or resources? I tried googling "How to make the ground surface game dev c++" and similar queries and am struggling to find good resources.

Second question..... In procedurally generated games, or games in general... What methods are used to render what needs rendering. I'm struggling to fathom how this is done, because in my mind... it would require one to know every vertex in the entire world to determine which are "in view" of the character. I'm struggle to store 25 million vertices, which are but an insignificant fraction of what I plan to make the world out of.... How can I even calculate which vertices are in view, if I can barely store the local vertices? Obviously it's been done, so I'm just being ignorant. I'm really looking for some solid resources on how to conquer this problem.

Any help would be appreciated.. Resources, advice, explanations etc... Thanks in advance!

To represent yout terrain you could use a height map texture. With this you only need to store the x and z coordinate and get the y coordinate from the height map. The advantage of this is that you can easily modify the height field by painting on it with Gimp or a similar program.

The other way to store your data is to not store it at all. You talked about using a 3D sine wave to create the data. Basically this is what is used in games with procedural terrain generation. For each position you evaluate a height function which gives you the height value. For this you only have to store a seed for the random number generator. The disadvantage for this is that you have to evaluate the height function per vertex, also it is not easy to create a specific terrain.

Concerning your second question you should look into spatial data structures, bounding volumes, frustum culling and level of detail techniques.

Spatial data structures divide your whole scene into some kind of tree structure. There exists quite a lot of these techniques. Because you just want to have a 2D Terrain a quadtree would be sufficient.

If you have the data structure set up you can create bounding volumes for the different levels of the tree. For example at the top of the tree you have the full extent of your terrain. One level lower your terrain is split into 4 parts and each has again a certain extent.

On these bounding volumes you can perform frustum culling. You take your view frustum which are 6 planes and perform interesection tests with the bounding volume and the planes to determine if the bounding volume intersects the frustum. You go through the whole tree and perform culling to determine which elements are in view.

Back the the small example you would start at the top and cull your whole terrain. Then you go to the next level and cull the 4 terrain parts. Now assuming 1 part of these is not in the frustum you know that none of the leaves of this tree node can be rendered.

Level of detail can be used to reduce the number of vertices you need to draw depending on your position. The general idea is that less details can be seen the farther away the viewer is. You can for example use tesselation based on the distance to the player to determine how much detail your mesh should have.

For resources I found this article quite good http://developer.amd.com/wordpress/media/2013/02/Chapter5-Andersson-Terrain_Rendering_in_Frostbite.pdf

Another resource is the Virtual Terrain Project http://vterrain.org/ which has so much information it can be quite overwhelming.

While heightmapped Terrain is a common way to generate terrain, keep in mind many games are just using meshes for their Terrain.

While Heightmapped terrain is extremly good for changing your terrain and iterate upon it as long as you have a good 3D heightmap editor like every modern engine editor contains (painting the heightmap in Gimp is certainly NOT very effective), it comes with a whole bag of its own problems.

The first is the even distribution of polygons on the terrain, meaning for rather flat parts of the terrain you have a lot of "wasted tris".

For large Terrains, while you can use an LOD System to reduce the polygon density over distance, you still are limited in your abilities to cull occluded parts of the terrain.

A mesh can have only the polygon it actually needs to have, so if the area is flat, you can save a lot of polygons even close up. You can now easely break down the terrain into multiple meshes and cull occluded or far away meshes, as well as LOD the terrain meshes (only the whole mesh though, less dynamic than what is possible with heightmap terrains).

Of course you can break down the heightmapped terrain into multiple heightmap tiles and thus heigthmapped terrains, but making the border of these fit each other with their respective LOD Systems changing around polygons can be a pain to handle.