Provide all functions with direct voxel coordinates

[nakedible]

The implementation currently has a built-in assumption of "cubesize", which is how many world coordinates a voxel takes. However, the library can very well be used for cases where there are no world coordinates in addition to the voxel coordinates. I would suggest providing all functions with versions that take in direct voxel coordinates, and making it clear that cubesize is optional.

[max-mapper]

totally agree, yesterday actually I removed cubeSize from voxel-engine (and set the cubeSize property to 1 so 1 game coordinate = 1 voxel coordinate). I havent removed cubeSize from all the other libs yet

[nakedible]

Actually, since you seem to be planning to work on this, there are a few other things that are on my personal wish list for voxel:

• Two versions of all public functions, one taking in x, y, z arguments and the other taking in a position vector. The latter would perform floor (and division by cubeSize, if that were used) and calling the former with just integer arguments. This promotes monomorphism, enables pure 31-bit integers and avoids the allocation for position vectors.
• Complete encapsulation of the pos.join('|') part inside the voxel library. Nobody outside should need know how to create hash keys for chunks, so the algorithm can be switched to a better one later.
• Support only chunkSizes that are a power of two, and replace all division and modulus by bitshifts. Code becomes much simpler and performance is increased.
• Allow not specifying a generate function, meaning all voxel values are initialized to zero automatically without looping through each value. Much faster for chunk worlds which are not pre-filled.
• Add a setVoxel method that will spawn a chunk on demand. Perhaps only for the zero-filled chunk option.
• Provide all voxel iteration functions (raycast, moore neighbourhood, etc.) inside voxel, where they can benefit from not having to look up the chunk on every iteration.
• Make sure all users of voxel go through public apis so that run-length encoding of voxel data can be added without touching callers. Same for new chunking methods.

I am willing to implement all of these, too - but I'd rather not do it if you do not agree with the changes or have other plans for voxel.

[kumavis]

@nakedible It has been some time since this discussion happened, but if you're still interested in dancing with voxels, PRs will be analyzed and accepted

[kumavis]

I've split up some of the issues mentioned so they can be discussed and fixed individually. Feel free to add more.