I'm writing a simple Minecraft like game to test out a few world gen algorithms and to learn more about OpenGL. My first render code was glBegin() ... glEnd() style. Very ineficient and slow. I started learning VBOs for a heightmap project but using VBOs will force me to update the whole VBO of the chunk if something is added or removed due to it's size changing. That also sounds ineficient. The most plausable theory so far I can think of is instancing but even this isn't good due to multiple render types.

When I've been modding Minecraft all the render code i've seen there (and written my self) has been glBegin() ... glEnd() style. Is it really that? It just feels so wrong since it can render 64 chunks 20 fps no problem on an Intel intergrated GPU.

  • 3
    \$\begingroup\$ I'm voting to close this question as off-topic because it is about a specific closed-source game's implementation details. \$\endgroup\$
    – Anko
    Jul 11, 2015 at 20:34
  • \$\begingroup\$ Well I might of asked it stupidly but what I'm looking for is an efficient way of rendering 8 x 8 chunks the size of 16 x 16 x what ever and Minecraft just was a good example to use. \$\endgroup\$
    – Hullu2000
    Jul 12, 2015 at 5:46

2 Answers 2


The bulk of Minecraft's chunk rendering goes through a vertex array. The world is split into 16x16x16-block render-chunks (which currently happen to be the same as storage-chunks, but it wasn't always that way).

Each render-chunk is converted to a vertex array, and rendered. It uses OpenGL display lists (one per render-chunk) as an older alternative to VBOs. If any blocks in a render-chunk change, the entire vertex array and display list for that chunk are regenerated.

  • \$\begingroup\$ Do you know how when rendering they record vertices for each cube? Do they duplicate vertices for each face for UV purposes or only store one vertex for each visible corner of the cube? \$\endgroup\$ Jan 8, 2020 at 22:07
  • 1
    \$\begingroup\$ @NathanWiles When this answer was written, it just duplicated vertices. Each cube was rendered independently, but with faces hidden depending on whether each side had an adjacent cube. However, there were some rendering engine rewrites in version 1.8, so I do not know if this is still correct. \$\endgroup\$
    – user253751
    Jan 8, 2020 at 23:28

Modern iterations Minecraft can use both VBOs or immediate mode (glBegin and friends).

The reason why it can get away with that is because of other rendering optimizations. Try refraining from rendering any blocks that are not adjacent to air (less bandwidth), building and optimizing meshes from chunk data (less vertices to draw), or cutting down on the size of each vertex element (less bandwidth). There are plenty of other ways to increase performance with such an engine.

That also sounds ineficient.

Have you done any tests that show that this is a bottleneck? What is inefficient is trivial if it's using time that isn't needed elsewhere. If it works without problems then you're fine. Only start worrying about it if it's preventing you from achieving your target framerate.

AFAIK Minecraft does this whenever there are chunk updates. It isn't as expensive as you think, provided the chunk is of a reasonable size.


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