koobas.hobune.stream
Mathematical question
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 ;)
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!
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.
Yes, you are right. I'm using a logic like that already, but $$anonymous$$e is much more dynamik. I'm creating just used faces. However, I would like to know "what is the worst case of faces" if every second block is missing or sth like that. Whit the worst case I will decide the dimensions I have to use
Well, if you generate careful boundaries, occlusion could be detected for enclosed spaces. That said, that's much more work than simply checking immediate neighbors.
The absolute worst case scenario, by the concept of every other space being filled like a checkerboard (by $$anonymous$$inecraft's tree blocks?) and no safety in place, would be 2708 blocks using all 24 vertices each (65000/24). That would limit you to a 16x16x10 area of blocks or, for maximum possible use, 15x15x12 (2700 of 2708 1/3 available cubes).
If, ins$$anonymous$$d, blocks with transparency were accounted for if enclosed, the next-most likely worst-case scenario would be an outer layer of AxBxC dimensions times 4 vertices each times two for total area, plus 24 times half the volume contained inside (((A-2)(B-2)(C-2)*24) / 2). This would permit a possible maximums of around 15x15x17 or 16x16x15 (the total sum for 16x16x16 would be 65696, just barely too high).
// Style 1, no efficiency:
public bool IsUnder65k(int A, int B, int C)
{
Debug.Log(A * B * C);
if(A * B * C * 24 < 65000)
return true;
return false;
}
// Style 2, outside messy, inside complex
public bool IsUnder65k(int A, int B, int C)
{
int area = A * B * C * 2 * 4;
int internalVolume = ((A-2) * (B-2) * (C-2) * 24) / 2;
int total = area + internalVolume;
Debug.Log(total);
if(total < 65000)
return true;
return false;
}
Edit: Actually, no. $$anonymous$$y mistake. With a checkerboard of $$anonymous$$inecraft tree-style blocks on the outside, there would actually be no gaps on the outside. So it would be the entirety of the outside volume rather than with any simplification. I guess I also forgot about half of the outside blocks' internal faces counting. Whoopsie.
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 256*16*4*4 + 16*16*4*2 = 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.
Yes. That is just the problem. Look. If u are taking off every second block by the player. Every second block would be fully visible. Because the second x,z row would be x + 1 and then u'll get something weired and verts esting... But in fact. It would be about 32000 verts. That means the maximum would be 16 x 16 x 32 Blocks. But $$anonymous$$ecraft can handle that? How?
