Grim Reaper
Grim Reaper

Reputation: 561

Creating Huge Low Poly Terrain

I am starting a new project in C++ using GLFW and GLEW.

The plan is to have a fairly big Low Poly terrain. It will NOT be randomly generated, I am planning on making it in Blender.

My problem is, that I cannot create a huge Low Poly terrain in Blender, because the program becomes really slow with the amount of vertices that the terrain has. I created a 500m x 500m terrain, and subdivided it by 1000. That gave me ALOT of vertices, making the program not usable.

What would be the best approach to creating a huge terrain? Im not sure how I would go onto creating chunks of the terrain, since I have to model them.

Another concern of mine is obviously loading the world into a custom game engine of mine. I suppose a big world like this would have huge problems with the load times.

Upvotes: 2

Views: 2357

Answers (2)

Zebrafish
Zebrafish

Reputation: 14318

Terrain in game engines like Unity, Unreal Engine and CryEngine is treated differently from your average static or skeletal mesh. Creation of different levels of detail are is usually done at runtime, as opposed to ordinary meshes having their LODs pre-created. Loading a mesh from a 3D program like Blender or 3DS Max as your entire terrain just isn't doable.

The Direct3D tutorials at rastertek are very good for learning, but isn't OpenGL obviously. Here is a basic tutorial of creating a basic terrain in Java OpenGL (This doesn't go into LOD handling I don't think).

Java OpenGL terrain

Most commonly I think I've seen a quad tree system, where you have terrain patches, and each patch is subdivided into four other patches, depending on a condition (whether distance to camera or screenspace size).

This is what a standard quad-tree LOD system looks like, in particular for the game Kerbal Space Program.

enter image description here

Along the way you'll need to figure out how to solve some problems, like how to get rid of the cracks and gaps in between two terrain patches that are of different LOD levels. Kerbal Space Program solved this by treating the edge vertices differently to line up, and not allowing any two adjacent terrain patches to be more than one LOD level of difference.

One method I tried was to upload two vertex positions for each vertex, the current LOD position and the position of the LOD vertex from one level down, and linearly interpolate between the two based on camera distance. Yet I'm pretty sure there are more elegant ways than this.

I've posted a video from a while ago of me messing around with this stuff, it shows the basic quad tree pattern, the problem of cracks, and then the vertex interpolation method. Some people create the patches on the CPU and other on the GPU and read back any necessary info, (like for example for physics) using transform feedback. There's lots of ways of doing things, and I hope to get back into it.

TerrainPatches

Upvotes: 3

Lloyd Crawley
Lloyd Crawley

Reputation: 41

I did something similar many years ago and found this tutorial very helpful:

http://www.rastertek.com/tertut05.html

It describes creating a quad tree with specific triangles from your terrain mesh partitioned into AABBs, using frustum culling huge parts of your terrain can be culled during runtime and your application's performance should improve. As long as you are confident importing meshes exported from blender (are they in .obj ?) you should easily be able to partition the different triangles using the strategies outlined in the tutorial.

A further optimization could be to have various LODs for nodes in your quadtree depending on the distance from the camera, i.e if a node is a set distance from the camera render a lower poly mesh by skipping certain vertices to make the smaller triangles "collapse" into larger ones. I'd recommend generating specific index lists to do this and use the same vertex data as opposed to having separate pre-generated chunks of mesh to save on memory.

Upvotes: 3

Related Questions