deathcap
commented
9 years ago relevant, some discussion about MC's chunk size https://gist.github.com/Gjum/d28fdb59e588cbbb84c4
21:36 <+Amaranth> btw, this would be a good time to change to 32x32x32 chunk size :D
21:36 <+Amaranth> Double your draw distance
21:37 < Grum> that is not how it works Amaranth :p
21:38 <+Amaranth> Well, unless you're already bottlenecking somewhere else that's close enough to how it works
21:38 < Grum> not really
21:38 <+Amaranth> Although you'll also slow down mesh generation on updates
21:38 < Grum> yeah and this means you have to generate 8 times the amount of mesh
21:39 <+Amaranth> But the overhead for setting up state and drawing each chunk as a separate draw call is non-trivial and having bigger chunks means you get to cut that down or draw more with the same effort
21:40 <+Amaranth> Of course you also have to worry about memory and blah blah blah
21:40 <+Amaranth> But once you optimize the rest the chunk size will end up being a limiter
21:43 < Grum> yeah gpu memory is also a pain
21:44 < Grum> we can get quite some gain from jsut rendering a sphere
21:45 < Grum> saves 33% area assuming i remember right =)
21:47 <+Amaranth> Yeah, something like that
21:50 < Grum> anyhow, until we fix generation that is just all pointless
21:50 < Grum> threading that is going to be needed to do anything >16
This should simplify chunk conversion from MC instead of the default 32x32x32 (maybe even make 16x16x16 the default in voxel.js/voxel-engine? why 32 anyway?), as each MC mini-chunk maps to one voxel.js chunk, avoiding the need to handle updating sections of chunks individually.