VoxelPrimitive currently allocates a large Megatexture for each metadata property, which is frequently much larger than the input data (256 MB texture for a 20-30 MB tileset).

The sizing of the texture is constrained by several factors:

• The texture is 2D. The 3D metadata is stored in 2D slices.
• The texture is required to be square. This results in sub-optimal arrangement of the slices, since tiles can have different sizes along each axis.
• The size of the texture is required to be a power of two.

As a result, we are effectively choosing from a very sparse set of tile sizes, i.e., 4, 16, 64, or 256 MB. And with the inefficiencies of the slice arrangement, most real-world tilesets (including small 20-50 MB datasets) will usually allocate the maximum 256 MB texture.

A few peculiarities of the availableTextureMemoryBytes argument in the Megatexture constructor:

• The hardcoded maximum 512 MB is actually rounded down to 256 MB because of the requirement to be square.
• The default 128 MB is also not a square, so it is rounded down to 64 MB.

Options to improve:

1. Allow non-square textures. This would increase the number of possible sizes (for example: 128, 192, 384, 512)
2. Allow non-power-of-two sizes in a WebGL2 context. This could reduce the amount of padded space around the data.
3. Use 3D textures, and drop support for voxels in WebGL1. This could significantly reduce the amount of unused memory, and potentially also improve rendering times -- see Voxel rendering performance #11086

The first two options would require us to revisit the slice arrangement code, which is somewhat messy. The best ROI might be to jump straight to 3D textures. See #12550