I am trying to create a minecraft clone to practice some stuff in Unity including Raycasting, terrain generation and player controlls.

Terrain is generating without any problem with a perlinNoise.

My problem is the then following performance problems.

The terrain is only 1 block high with no underlying blocks. Each block constist out of 6 quads with a 64x64 texture. I generate terrain at 200 x 200 size.

I can't imagine why 4000 voxels with such simple textures can lag out whilst my pc runs objects with 50k tris and complex textures without any problem.

My code:


public int xVoxels = 200;
public int zVoxels = 200;


for (int x = 0; x < xVoxels; x++){
    for (int z = 0; z < zVoxels; z++){

        // voxel = script parameter
        GameObject newVoxel = GameObject.Instantiate(voxel);
        Vector3 position = new Vector3();
        position.x = xVoxels/2 + x;
        position.z = zVoxels/2 + z;
        // PerlinNoise stripped out for testing
        position.y = 0f;

        newVoxel.transform.position = position;

Solutions I tried:

Combining meshes

Combining all meshes to a single one per material worked wonderfully... until I wanted to interact with each voxel determined by Raycasting from the Camera, I had a raycast hit to the combined mesh and not to my determined voxel

Generating the planes myself

Instead of using the unity plane object I generated all vertecies myself, same performance problems

  • \$\begingroup\$ When you say you're making your voxels out of 6 planes, do you mean the Unity plane primitives? These have something like a 10x10 grid of triangles on their surface, so your 4000 voxels would be something on the order of 2.4 million triangles, ie almost 50 times heavier than the "50k tris...no problem" load you described. So, it's not surprising that this would lag, with the overhead of 24 thousand GameObjects too. High-performing voxel games do not spawn a mesh per face nor per voxel, but per chunk. Translating a raycast hit from a chunk to a voxel is just math, well worth the chunk speedup. \$\endgroup\$
    – DMGregory
    Mar 15 '19 at 11:51
  • \$\begingroup\$ Ill take a look at that asap. Thanks. I was aware of the chunk mechanic but that would be step 2 after solving my performance problems \$\endgroup\$ Mar 15 '19 at 11:55
  • 1
    \$\begingroup\$ Also, if you treat every block as a gameobject, that can lag the game severely too and costs way more memory than it shoud \$\endgroup\$
    – Bálint
    Mar 15 '19 at 12:22
  • \$\begingroup\$ Well in the end every block should be interactable \$\endgroup\$ Mar 15 '19 at 12:42
  • 1
    \$\begingroup\$ "Every block should be interactable" is not in opposition to "Do not make every block a GameObject." As mentioned above, all you need is a bit of math to pick the relevant block out of a physics hit on a chunk. And if you can generate the chunk once, you can re-generate the bits that change when an operation is done on one of the blocks. \$\endgroup\$
    – DMGregory
    Mar 15 '19 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.