ndarray/gl-now integration

[shama]

Previously in issue #3 the goal was to streamline meshing and support transparent blocks, better ambient occlusion and make voxel chunks more dynamic. But shortly after @mikolalysenko released https://github.com/mikolalysenko/ao-mesher which does all that but far more performant.

Moving forward I attempted to integrate ao-mesher while keeping three.js as the renderer with: https://github.com/shama/ndthree But that didnt work as well as I hoped. It will quickly hit memory limits as BufferGeometry requires multiple Float32Array to function and still not as performant as if the renderer was switched out for a gl-now approach.

That and realizing having three.js part of voxel-engine is the reason most voxel plugins have a horrible peer dependency to the game instance. I think all focus should be towards integrating ndarrays and gl-now into voxel-engine (or better yet, as separate rendering modules).

It's difficult because so many things rely on three.js atm. I think a good first step is to build a separate module that procedurally loads chunks and displays them with gl-now. ndarray-continuous and voxel-mipmap-demo might give us pieces for most of that now. Then start integrating with the physics and lastly into voxel-engine.

Especially awesome if we can make it so voxel plugins don't need a game instance but are all individually configured.

[hughsk]

👍

The gl-* modules are really nice to work with, I prefer them to three.js now. Is there any interest in moving voxel.js to 1.0.0 and building the core up from scratch again? This is probably a good chance to think about how to handle shaders in a modular fashion too :)

Lurking IRC, but supposed to be working on an application today so will have to join in on the discussion later!

[deathcap]

Looking at the available gl-modules, appears at least this functionality would need to be integrated and/or ported over:

1. FPS controls - voxel-mipmap-demo uses an orbit camera (arcball); mouselook / pointerlock (as in interact, voxel-control) is definitely needed
2. Chunking, load events - the demo meshes the entire terrain altogether; though ndarray-continuous looks promising. Currently the voxel module handles chunking (chunker.js), emits missingChunk, and voxel-engine implements getChunkAtPosition, showAllChunks etc., and emits renderChunk
3. Texture atlas packing - voxel-texture and voxel-texture-shader dynamically build up the texture atlas using atlaspack; v-mipmap-demo currently loads the textures as 5D array (isabella-texture-pack), then passes as-is to gl-tile-map
4. Physics, skin - voxel-player, voxel-physical; voxel-engine also has a gravity constant, applied in addItem()
5. Other plugins reliant on three.js - surprisingly not as many as I expected, from a quick search for game.THREE, besides those mentioned above: voxel-client (creates the player skin, maybe can be refactored out), voxel-daylight (lighting), voxel-debris (cube geometry), voxel-debug (axis helper), voxel-drone, voxel-highlight (wireframe highlight), voxel-mine (overlay texture), voxel-oculus (custom shader), voxel-server (just for initializing position to a Vector3), voxel-sheep (object model), voxel-sky (lighting, material), and voxel-webview (uses 3D CSS renderer for three.js). Once the basic foundation built on ndarray/gl-now is at or near parity with the existing three.js-based voxel-engine, it may not be too difficult to port these remaining plugins.

[shama]

Excellent list!

[deathcap]

Mm. Some progress, (1) game-shell-fps-camera + an updated basic-camera for FPS-style movement controls; (3) voxel-stitch, voxel-registry + artpacks -> gl-tile-map, for dynamic texture atlases.

Test/demo for what I have so far at https://github.com/deathcap/game-shell-voxel - but there's a long ways to go to reach three.js-based voxel.js parity, many small- and medium-sized pieces missing. I think the next big missing part is (2) chunking, maybe using @hughsk's ndarray-continuous.

[shama]

Not to discourage you from building your own implementation because you're certainly are cranking out some awesome voxel modules much faster than the rest of us atm. :)

But just a heads up, I started on a ndarray/gl-now based chunker: https://twitter.com/shamakry/status/452305719010684928 I am trying to build it in a way where we don't cause any peer dependencies. It avoids passing the instance of another class into it's own class. Basically avoiding this new VoxelModule(othermoduleinstance).

At the moment, it just manages an array of vertex data to bind to the gl instance along with some convenience helpers. So in theory, could be used by libraries other than gl-now. Or if and when gl-now or it's dependencies update, the impact on the chunker module will be minimal, if at all. Also chunks can be fully constructed to their vert data array within a web worker and merged into the array to avoid blocking the main thread.

[deathcap]

@shama Sounds awesome looking forward to it =)

[deathcap]

As of voxel-mesher 0.6, voxel-shader 0.8 (based on @mikolalysenko's ao-mesher and ao-shader examples, respectively), and voxel-stitch 0.6, I think the texturing functionality (3) is now at, or at least near, parity with the three.js-based voxel-texture/voxel-texture-shader modules (side-based texturing, atlaspack arbitrary rects, high-res support, etc.).

Haven't started on (4) skin/avatar yet, anyone know how to best handle scene graphs with gl-modules? In three.js, one would use scene.add(object) and Object3D; couldn't find an analogous gl- module for this purpose. Updated minecraft-skin for three r66 compatibility in the meantime, but would rather go straight to ndarray/gl-now ;)

@shama how are you handling the meshes in your chunker (should they be stored in the this.meshes array of voxel-engine? Trying to port showChunk()). Also would this be separate from or integrate with voxel/chunker.js? And I think I ran into the same (or perhaps completely different) problem you mentioned around the chunk edges, if a block is entirely solid (e.g., all stone) ao-mesher returns no vertices; I'm thinking the way to solve this is to have the chunk voxels always surrounded by air, for meshing purposes at least.

[shama]

@deathcap Cool. The chunker is vaporware atm, so if you've got an implementation in mind please go for it. I am slow at software. But the chunker I'm working on just manages a typed array fed to a VAO. It's going to be it's own generic module, not integrated with voxel-engine.

[mikolalysenko]

Regarding scene graphs, I am kind of against the concept since I don't think it is terribly useful. If we are going to have a central game engine module, which I think is ultimately necessary, then we probably want to have it be responsible for all actors within the system and to draw them as needed using an appropriate algorithm. I don't think that there is any compelling reason to double up all of this functionality in a separate scene graph module.

Here is an interesting perspective on the subject from Tom Forsman:

Scene Graphs: Just say no

[shama]

I don't think we need a central game engine module. I think that should just be the user's application. For verbose operations, just create helpers for the user.

Re: scene graphs, I was thinking about just having flat layers. Each layer is just a typed array to be fed to a VAO and a name. The just add/edit/delete vertices in a layer and draw each layer by name as needed. Would that be sane?

@deathcap BTW, are you going to nodeconf? It would be really cool to chat with you in person about voxel. :)

[mikolalysenko]

That could work. Though there is going to be some trade off between having a central module vs. having each application call many parts.

Where things get a bit hairy though is when you have interactions between multiple types of objects, like in shadow mapping and so on.

Generally though, what you want to do is group objects by material/shader and do as few rendering/state changes as necessary to draw them all. So a render loop could look something like:

1. Begin shadow pass:

   a. Bind shadow shader/shadow fbo
   b. Draw terrain and objects

2. Begin render pass:

   a. Bind draw buffer
   b. Bind terrain shader, draw all visible chunks
   c. Bind object shader, draw all objects

3. Post process:

   a. Apply filter effects and blit to screen

Or something like this.

[deathcap]

I suppose scene graphs are not really necessary. In three.js they are how you do relative transforms, wrapping the objects in an Object3D, but under the hood all it is essentially doing is matrix multiplication, which is easy enough to do explicitly. Another benefit of multiplying the matrices manually is that it can be written in GLSL instead of JavaScript, which might be faster in some situations (benchmark: http://watmough.github.io/webgl-matrix-demo/)

Using this technique to implement https://github.com/deathcap/avatar, generating gl-vao meshes for MC skins. Analogous to the three.js-based https://github.com/maxogden/minecraft-skin (supports 64x32 skins like the minecraft-skin module, and also the new 64x64 MC 1.8 format), but for gl-modules instead. So that takes care of half of (4). Haven't started integrating it with the rest of the scene, though.

[mikolalysenko]

Creating hierarchical transformations is a simple enough task that it doesn't really matter if you use a scene graph or not. Though I do think that longer term it makes more sense to switch to skeletal animation and skinning rather than assembling objects as collections of rigid transformations, which is a fairly limited and clumsy way to do animations.

The bigger issue though is how to handle different shaders and multipass effects, which I still don't have any great ideas on how to modularize (perhaps it isn't even possible?)