Mathematical question

Questions & Answers
1

Hey!

I’m hanging on a minecraft game… And I’m onto “how to optimize the chunks, size and so on”. But I got a question, and I’m not sure what == true :wink:

It’s about the quantity of verticies.

Lets begin.

If I make a simple quad I get 4 verts.

  • a cube has then 6 x 4 = 24 verts.

  • a chunk has then 256(y axis) x 16(x axis) x 16(z axis) x 24(verts / cube) = 1.572.864 verts!!!
    And that would be the really worst case.

Logically u could pick each second cube out of the mesh and u’ll get the halve of the final verts.

But that is definitelly more that 65000 verts, that can be stored in one mesh!

Am I wrong? What is the way to go?

Feel free to answer!

Cheers!

2

It may be worth observing how the game Antichamber handled its dynamic modeling. If you really want a reasonably effective and efficient game with building-blocks, you need the ensure that every face of every block is NOT being constructed at all times.

That said, Antichamber handles it by only bothering with bits at a time, rather than restructuring every piece of every block with every change. If you’re careful and methodical, you can intentionally make extremely inefficient patterns in that game. But that’s a small cost to pay for it working excellently 99% of the time.

I think that block-building would probably best be handled by dividing the blocks up by type, coupled with determinations of which sides are obstructed (except, for instance, by Minecraft-style trees, which you can see through to their other side) to remove faces from being generated. This way, a cube of any size would be no more vertices than the dimensions of its area, rather than relative to its volume.

Edit: Pair this with dividing up regions into chunks and, while it might add vertices between chunks without accommodations, it would still be a vast improvement over generating all 6 sides of a cube, buried 5 blocks deep.

3

You just make the chunk size smaller, although yes, you’re wrong, since you only draw the faces that touch air. If you filled the entire chunk, only the outer surfaces would be visible, so that’s 2561644 + 161642 = 67,584 vertices, assuming no other optimization. That’s still over 65K, so as I said you simply make the chunk size smaller. The worst-case scenario is to set every other cube in a 3D checkerboard pattern, so with no optimizations, the largest chunk size that could handle that and be below 65K verts is 16x16x16.