How to efficiently use command.getBlockInfos()

I have an idea of how I'll solve the problem I'm having, but I think I could solve it in a smarter way with the help of some of the computercrafters here.

The problem: Given an area of N size, what is the most efficient way of using command.getBlockInfos() on that area? (How to make the least number of cuboids each as close to 4096 blocks as possible).

What I was thinking: Make 16^3 areas, then for the extra dimension%16 blocks, try (somehow?) to get it as close to a volume of 4096 blocks as possible.

Does anyone else have suggestions? (Geometry is one of my least favorite subjects of math…give me trig or calculus any day :P/>)

I suppose you'd probably get better performance if you furthermore line up your cubes with chunk borders. Beats me, I haven't seriously played with the command yet, I'm just going with my gut. Another factor is how you're collating your results… raw scans can quickly add up to large amounts of RAM, and attempting to apply any sort of basic compression is a fair bit simpler if you can rely on your input stream being in a certain order…

Frankly I rather suspect the extra calculations your code would end up doing in order to achieve 4096-block-scans "whenever possible" would outweigh the cost of simply doing things the simple way and "cutting" your final cubes down to the smallest size they need to be in order to fit into the pattern of the full-sized cubes' placements. You'll find that some shapes will force you to do multiple non-4096-block scans whatever you do anyways.

If you really want to make a block puzzle out of it, though, I suggest going with the nearest powers of two. Every time you halve the width / length of your cuboids, you can double the height. You'll potentially scan excess blocks this way, but it keeps things relatively simple to calculate.

In case anyone else has a similar problem, I asked this question on Stack Overflow, and got a very good answer. Here's the code I ported from the answer. It splits the cuboids into the most optimal equal size. It's a heck of a lot better than what I was trying initially (16^3 until the end, then in the remaining space, divide the longest side by 2 until the volume is less than 4096).