To put this bluntly, for non-destructible/non-constructible voxel style terrain, are generated meshes handled much better than instancing? Is there another method to achieve millions of visible quad faces per scene with ease? If generated meshes per chunk is the way to go, what kind of algorithm might I want to use based on only EVER needing the outer layer rendered?

I'm using 3D Perlin Noise for terrain generation (for overhangs/caves/etc). The layout is fantastic, but even for around 20k visible faces, it's quite slow using instancing (whether it's one big draw call or multiple smaller chunks). I've simplified it to the point of removing non-visible cubes and only having the top faces of my cube-like terrain be rendered, but with 20k quad instances, it's still pretty sluggish (30fps on my machine).

My goal is for the world to be made using quite small cubes. Where multiple games (IE: Minecraft) have the player 1x1 cube in width/length and 2 high, I'm shooting for 6x6 width/length and 9 high. With a lot of advantages as far as gameplay goes, it also means I could quite easily have a single scene with millions of truly visible quads.

So, I have been trying to look into changing my method from instancing to mesh generation on a chunk by chunk basis. Do video cards handle this type of processing better than separate quads/cubes through instancing? What kind of existing algorithms should I be looking into?

I've seen references to marching cubes a few times now, but I haven't spent much time investigating it since I don't know if it's the better route for my situation or not.

I'm also starting to doubt my need of using 3D Perlin noise for terrain generation since I won't want the kind of depth it would seem best at. I just like the idea of overhangs and occasional cave-like structures, but could find no better 'surface only' algorithms to cover that. If anyone has any better suggestions there, feel free to throw them at me too.

Thanks, Mythics


2 Answers 2


This could help you out;


  • 7
    \$\begingroup\$ Please say something about this. Answers which are just links are discouraged. \$\endgroup\$ Commented Jul 3, 2012 at 8:45
  • \$\begingroup\$ The main reason being that links die sometimes, like this one did now. So as it stands this answer is just "this could help you out" and a dead link. \$\endgroup\$ Commented Sep 16, 2019 at 8:09

well, one big problem you will ahve is the number of triangles for just rendering flat surfaces. one thing you could do is to do some kind of optimization where a 6x6x1 arrangement of cubes gets translated into one bigger cube, thereby reducing the number of primitives.

(pre: 6*6*2 primitives. post: 2 primitives)

This would be expanded uppon to combine large planes into simpler meshes.

I'm at work now, so I can't really spend a lot of time on it. And I have also never done it in this kind of engine (I used it in a heightmap).

It is important to balance how much processing you do on the CPU, versus how much you leave for the GPU. If you only do rendering and world-generation at the moment; Put in a Thread.Sleep(2); or something in your update to simulate gameplay-code.


You must log in to answer this question.

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