In my game players can modify terrain in real time, but I am not sure what is best practice for this scenario. I have redesigned and refactored the way the player does this a few times, and am feeling at a loss.

Initially I created small blocks of terrain as GameObjects, but this I quickly realised was grossly inefficient. Later I devised a system which procedurally generated the 3d mesh by creating vectors and tris for a much larger terrain chunk GameObject, but this is also unfit for purpose. As I would like the player to be able to place new terrain pieces (replacing old) from premade 3d art assets.

The question is how should one string these pieces together into one map, so that the player can enjoy a large map with a fine level of control? And for this not to break the game with inefficiency? Consider that the terrain system is composed of blocks of premade terrain segments, like river or cliff sections. I feel like I'm missing some basic knowledge of how and when to merge 3d meshes into GameObjects for this purpose?

  • 1
    \$\begingroup\$ The answer will entirely depend on the kind of terrain you're trying to generate. What works for one world won't work for another. It's also important how much a player can change the land. Can they remove things? Can they change the height of the land? Clear rocks and trees? Carve caves? \$\endgroup\$
    – Pharap
    Apr 25, 2017 at 7:51
  • \$\begingroup\$ It's unclear to me whether you're asking about assembling completely pre-made blocks of terrain in a tile-based fashion, or stamping of terrain features into a continuous heightmap as was done for the Witcher 3 (see section on stamping workflow in the last 10-15 minutes). Can you add more details or examples of what you want to achieve, and what particular step(s) in the process you need information about? \$\endgroup\$
    – DMGregory
    Apr 26, 2017 at 16:51

2 Answers 2



This is a 2D structure where every value represents either a vertex or a tile between vertices, in a grid structure. Heightmaps have been rendered in every from software scanline renderers (NovaLogic's voxel engine) to modern 3D environments. These were commonly used for rendering 3D in the '80s and '90s due to the low processing cost / simple structure - essentially a 2D array of integer or floating point values. Games like Magic Carpet used this to great effect.

pros: extremely cheap to process and send across network.

cons: Does not allow overhangs, e.g. caves, overhanging cliffs, etc.


This is a 3D structure where every value represents one volumetric element in the world (Vo-x-El). As we go from 2 to 3 dimensions, cost increases geometrically (excuse pun).

pros: Much more flexible than the heightmaps from which they evolved, you can really create any space you like (subject to voxel grid resolution / density).

cons: Much more costly to process - optimisation will be a necessity. Also, your terrain will need to be built with different tools, being a voxelised mesh.

Voxel template system

Provided your objects to be placed are static, nothing stops you from querying a voxel space for the placement of say, a 2- or 4- or n-voxel at once. So let's say you have a nice Roman column, maybe it's 5 metres high and your voxel scale is 1m cubed. So you will need 5 voxels vertically to fit this piece in. Query the voxel space in the grid at the player's chosen placement location (on the ground in front of them) and the four above it - place if all 5 spaces are free.

pros Voxels provide a nice neat grid in which to work / place objects. They forego the need for physics since one can use the grid structure and assume they adhere to that (e.g. Minecraft). Collapsing straight down due to gravity is easy enough to accomplish.

cons: Can be costly to check spaces for multi-placement as described above. Your template meshes, e.g. the column, need to be built to fit the underlying voxel system.

Also... Chunks

Chunks are a means of breaking up a large map into smaller, square sections. You only load in certain chunks depending on where the player is currently standing in the world. Each chunk will typically be nxn voxels in depth and width, and m in height (all depends on your coding choices).


The best approach is probably to save the "Pre-made gameobjects" as vertex arrays (x,y,z coordinates) just like you probably would with the terrain mesh. These can be smaller than the array you use to generate the entire terrain. If you find the correct positions in the array you use to generate the terrain mesh by looping through, you can define the position of the "Pre-made gameobject" within the terrain array and adjust the vertex height positions. This should allow the player to click on a location on the mesh and spawn a pre-defined mountain etc...


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .