Increase voxel type range?

[deathcap]

There is a comment saying the voxel format could be changed over time so I have a suggestion :) could we change it to only include the voxel type index (which is dereferenced through voxelSideTextureIDs as of GH-1 to get the texture indices), and split out the opacity flags and ambient occlusion values to separate ndarrays?

The main reason I'd like to do this is to allow increasing the voxel data type size, currently capped at 8-bit in ao-mesher. With voxel-engine, the arrayType option can be used to change this type, defaults to Uint8Array but it can easily be changed to Uint16Array or even Uint32Array for more space. 256 block types could run out quickly (especially with some of the techniques described in https://github.com/deathcap/voxel-registry/issues/1) so having 65536 (or the possibility of 4294967296) types for extra breathing room could be quite useful. It looks like 4 or 5 unused bits may be currently usable for this purpose but anything more would run up against the opacity/ao/flip bits.

Another reason is for simplicity: having the voxel type array on its own reduces the complexity of saving and changing the voxels. For example, a game could have a setting to toggle between opaque or transparent leaves, for performance reasons. With the opacity bit stored in the voxel array, all occurrences of it would have to be searched & replaced to perform this toggling. Not impossible, but adds complexity. And when you are setting the voxel type you have to be sure to include the proper flags or it renders incorrectly. I see the opacity/ao bits as more of a "presentation" implementation detail, logically separated from the abstract voxel data type (like HTML vs CSS), so I think it makes sense to have distinct arrays for this purpose.

Possible disadvantages include potentially higher memory or processor usage, for the extra storage and lookup of the arrays. If this is a problem, ndarray-bit or ndarray-hash might help somewhat. But imho the added flexibility and simplicity would be worth it, what do you think?

[deathcap]

Reading the code now, only the opaque bit overlaps with the possible voxel types, the AO flags are stored beyond the 16 bits. Passing the opaque flags in a separate array looks like it would be difficult (at least for me) since it would need to reach the cwise-compiled code.

But increasing the voxel mask from 0xff to 0x7fff should probably be sufficient at least for my purposes, raising the maximum block index from 255 to 32767, not bad (tested this change with the maximum block index, works great). Submitted PR https://github.com/mikolalysenko/ao-mesher/pull/3

[mikolalysenko]

Maybe, though one downside I see is that it would require more than 2x more memory accesses, which could seriously reduce the speed of the mesher.

Regarding 2^32 voxel types, I don't think that will be easily possible since the internal ao-mesher combines all of the voxels together with the ambient occlusion bits for faster comparison. BUT, we could probably support up to 2^23 or so without too much trouble I think.