Minecraft like batching performanc

Started by
2 comments, last by dougbinks 11 years, 10 months ago
So I have been creating an engine for awhile that uses techniques discussed a lot on mc. I've come to an impass though and am trying to figure out which direction is better from a performance perspective.

So typically you draw the Vertices for the land in chunks, the average size for theses seems to be 16x16x128. So you put all the vertices for these blocks in a single vertex buffer. Now lately I've read a lot about people making the chunksize 16x16x16. Now if you consider this, it could potentially lead to many more draw calls, and it will certainly lead to many more frustum checks, however most of the time you could save on drawing vertices since a lot of verticies will get culled out and now drawn.

So the question is, does not drawing those vertices make that much of a difference? I've read that by and large, graphics devices prefer large, infrequent calls over smaller but more frequent calls. So I would guess that drawing 16x16x128 less times than 16x16x16 would be a preferable choice.

Am I wrong in any of these assumptions? I love to hear whether I am mssing any information or not considering something correctly.
Advertisement
You should be able to batch things such that all your geometry goes up in a very small number of draw calls. Someone with more experience on modern GPUs can probably elaborate better than I can, but basically you shouldn't need to mess with a draw call per "block" in the first place.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

I found that a good rule of thumb is to draw your geometry in as few calls as possible, yet that may not be where you really need the extra performance. using smaller chunk sizes give you extra performance in other areas of your frame time. I can see using 16x16x16 if you want to have higher update rates for chunk building if you are doing a lot of liquid or lighting calculations. Building a 16x16x16 chunk is a lot faster than building a 16x16x128 chunk and since the player will only ever be editing small areas of the voxel data at a time, this setup will probably end up being better performance wise in a typical game play scenario. Also, if you take extra steps ahead of time to make sure your shaders and rendering code are optimized (profiling here would be good) then you can get away with any "perceived" slow down you may experience. A good optimization is to pre-transform all of the vertices to world space while generating the chunk geometry so you don't have to do it in the vertex shader. I've also seen people bake ambient occlusion into vertices when generating geometry, but that's for another time :).
There are a number of good articles in the wild about batching drawcalls which a quick google should find. State changes between drawcalls effect their performance significantly, so you can achieve good results by ensuring you sort draws by shader, vertex buffer and texture. I've found using large vertex buffers which contain data for objects which share roughly the same state helps reduce vertex buffer changes, and texture changes can be reduced through using atlases or texture arrays if supported.

If you've got multiple objects in one vertex buffer which share state, once you've determined visibility it may be possible to collapse several draw calls into one, also helping performance.

This topic is closed to new replies.

Advertisement