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

rip the octree out of spatial-events, make improvements, and use that to keep track of the locations of items (to build and update potential collision sets for those items)

ability to register bit masks and then add items with a bitmask, and additionally request a list of items using a bitmask

game.registerItemMask('terrain')
game.registerItemMask('player')

game.getItemsMatching(game.masks.terrain | game.masks.player) // == [list of items]

var into = []
game.getItemsMatching(game.masks.terrain, into, atIDX) // === into, into has been updated with the new items

SPACESHIPS

make aabb-3d not quite so horribly painful to work with, somehow

solve the horrible yaw / pitch / roll set of nested object3ds somehow -- use one object3d for all three, maybe?

I have no idea what the API for this would look like, but it would be nice to have additional steps for terrain generation, we need to make it easy for people to hook into terrain generation to add features like:

• ore stems
• rivers
• biomes
• structures

This might look something like this:

1. the chunk generation step emits a beforeGeneration and an afterGeneration event
2. when these events get emitted, the engine passes the chunk to whatever is listening
3. developers can do what they want with the chunks.

make voxel-control operate in world coordinates, again somehow

Document the whole public API

being able to use the aforementioned octree to do:

game.getItemsNear(point, radius[, optionalMask])

emit a start event once all resources have been fetched

• loading api
  
  Push/pop onto loading stack, get status, maybe on a worker?
• main menu
  
  Start game, options, key bindings, hip blurry and slow moving backgrounds
• player/item attributes/stats api
  
  hp, str, stam, dex, etc, full on D&D
• better fog
  
  Only show on XZ plane so the sky isn't hidden
• watery bodies: ocean, riviers
• lots of mobs
  
  A cool mob api with AI
• inventory
  
  Hold all your things
• crafting api
• stream all the things
• airships

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.