15 comments

[ 39.2 ms ] story [ 562 ms ] thread
Thanks for sharing. Stuff like this instantly rekindles my desire to create games. It's like being a kid again, the tiny visible portion sparks my imagination as to what could lay beyond...
If you haven't seen Voxatron you might like it. It's a virtual fantasy voxel console you can make "cartridges" for. Here's some of the user made carts

http://www.lexaloffle.com/bbs/?cat=6&mode=cposts&orderby=ts&...

and there goes my weekend, this is so freaking sweet
I made a little voxel game earlier. Faar from as good as voxatron but it was just a learning game. Http://voxlords.webgl.nu
Dang dude this is super impressive. How did you get started learning how to create games like this?
Working as a programmer but like game programming on my spare time. But I'm still a novice game developer. But it's fun :)
I'm stúck at Loaded: 83% using Opera browser.
I am getting periodic drops in FPS, is it rebuilding chunks or what?
It's a work in progress but it shouldn't rebuild other than after world generation.
This is built using Three.js ... I've seen tons of cool Three.js demons, even tried doing some stuff myself, but not that many actual games. It seems webGL is too bleeding edge. Maybe when the WebGL spec. is final and implemented in the major browsers I'll give it a try. But for now I use Canvas for the graphics. Canvas is much higher level and hardware accelerated, plus easier to use then WebGL. Low level graphics and JS don't fit well together.

I'll love to see a good voxel engine in JS! I think you will be too limited by Three.JS though.

I made a voxel engine without using Three.js a few years ago[1] (well, the engine is rendering-agnostic, so I actually used Three.js, but only the really basic primitives, such as BufferGeometry).

The issue wasn't so much WebGL performances (especially since WebGL is actually hardware accelerated), but rather the CPU cost required to rasterize a real-time voxel world into a polygonal geometry. I wasn't able to generate geometry chunks fast enough to match the player speed (so the player was always able to catch up with the rendering). Even using workers wasn't improving the perfs so much (but I think could have improved that by changing the update heuristic a bit).

But it was pretty fun nevertheless! I'm proud to be one of the few JS voxel engine using marching cubes, which look much better than usual cubes :)

[1] http://arcanis.github.io/voxplode/ (may take a while to load, may be a bit buggy, especially if you move before the chunk underneath has been loaded)

Several books with WebGL in the title are almost completely about Three.js. The same goes for several online tutorials for beginners. A sad current state.

Three.js is a JS library, one of its render targets is WebGL. Three.js is more a scene graph layer and graphics/game engine.

Where as WebGL is bare metal. And I wish more people would consider using WebGL directly for their demos, tutorials and products.

It's like every top answer on a JavaScript questions on Stackoverflow was answered with a JQuery code snip back in 2013. Fast forward to 2015, the landscape changed completely and the SO community upvoted vanilla JS answers.

Some may remember the Voxel.js project that had gained traction fast. The main developer wrote a long blog post about the development: https://medium.com/@deathcap1/six-months-of-voxel-js-494be64... .

Quotes from that article: Unfortunately the greedy meshing + texture atlases demonstration was not compatible with the three.js library used by voxel-engine, so I forked it. [...] I updated to three.js version r66, from the previous r58 series. Slightly non-trivial since there were a few major changes, though they provide a migration guide to help updating. The most noticeable was the removal of Face4 (quads, removed in r60), so you need to use two Face3 (triangles) in its place. [...] 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.