voxel-engine to-do list

readme.md

major goal: "everything is just an object and voxel-engine just deals with keeping a list of objects for collisions" via voxel-chunks

pending:

• voxels.createChunkRadiusStream().pipe(voxels.generateChunkStream()).pipe(game.voxels) for async chunk loading
• switched to the culled mesher so that we can implement texture atlases, which will reduce draw calls by a ton
• implement ambient occlusion after switching to the culled mesher

investigated/completed:

• use _ prefixed methods for internal. UPDATE: on second thought this is kind of mess. I prefer to think instead of things as 'more public' and 'less public', e.g. beginner methods and advanced methods. The core API is grouped together now inside voxel-engine (look up 'external API' in index.js)
• addgame.voxelRange(low, hi).createReadStream() for bulk read access. UPDATE: since this isn't an async API (all voxels are already in memory) a stream didn't make sense, so I decided on game.blocks() instead: https://github.com/maxogden/voxel-engine/commit/9ca141ff368ed5d272c67de5ee0cc5d93c509108
• game.staticPath that integrates static-assets. UPDATE: waiting on zlib + tar to get integrated into this solution
• use voxel-raycast against voxel-chunks. it is implemented for voxel terrain but voxel-chunks need more work before this can happen
• switch to gl-matrix (or similar) for vector maths UPDATE: added here https://github.com/maxogden/voxel-engine/commit/26625ef241707850d171b4eb60be47d0347e0750

I think the question is "what should voxel-engine be?" What functionality should it hold?

It seems like it should have as little implementation as possible, and instead just be an API for different modules and the communication between those modules. Ideally everything could be entirely replaced individually without having to modify the core engine or interfaces between modules.

Some ideas for what modules should be the core engine, with their current implementations if they exist:

• scene manager (THREE interface in engine)
• renderer (THREE)
• mesher (voxel-mesh)
• chunk manager (voxel-chunk & some kind of spatial partitioner)
• chunk generator (voxelGenerateChunk, do it need a pre/post like Techwraith suggests?)
• cameras
• game item/entity manager(s?)
• physics (voxel-physical)
• collision? (seems like it might fall under the chunk manager or physics manager)
• controls (voxel-control)
• resource manager?

SpatialEventEmitter is cool but yeah, it seems like something that should be separate from the actual spatial partitioning algorithm.

@snagy very well said, thank you

Voxels needs to be more than a type if we want to record data like state (open/closed), rotation (steps, fences). If we assume most blocks will not a have a state, we could just have a hash for lookup in each chunk.

Oh and an easy one, we should all start using peerDependencies to specify the version of voxel-engine each module is compatible with. http://blog.nodejs.org/2013/02/07/peer-dependencies/

meshing and terrain generation is expensive. move heavy loads out to web workers. A streaming interface between webworker and main thread could be cool

q. is there already way to get the items ? http://www.minecraftwiki.net/wiki/Items

here is what @vogonistic does to load async chunks:

1. inserts an empty chunk (I assumed this would stop additional requests for it to be made)
2. requests the chunk to be generated (socket.io connection)
3. replaces the chunk with the generated one when it is done.