search

max-mapper / voxel-engine

3D HTML5 voxel game engine
http://maxogden.github.com/voxel-engine
BSD 3-Clause "New" or "Revised" License
1.29k stars 219 forks source link

Change to use stackgl (ndarray/gl-modules) instead of three.js (needs testing; help welcome) #103

Open deathcap opened 10 years ago

deathcap commented 10 years ago

Sending this PR for feedback and if anyone else wants to help out (moved to ndarray branch to maxogden/voxel-engine so it can be easily PR'd or committed to in the main repo) though it is not complete yet, progress towards https://github.com/voxel/issues/issues/4 ndarray/gl-now integration. Based on @mikolalysenko's voxel-mipmap-demo and @shama's ndarray branches, with lots of changes. Major changes included:

Not all of the existing API is supported yet, and more work & cleanup is needed before this is merged, but it is somewhat usable at this point.

deathcap commented 10 years ago

The biggest missing piece is currently the fps-style controls and physics.

Using https://github.com/deathcap/game-shell-fps-camera for now but would like to move to https://github.com/chrisdickinson/voxel-control and https://github.com/chrisdickinson/voxel-physical as used in the existing three.js-based voxel engine. Some progress porting voxel-physical off of three.js Vector3 (to gl-matrix vec3) in https://github.com/chrisdickinson/voxel-physical/pull/11 but they still have other implicit dependencies on three.js objects (should we implement a compatible interface? change to a more generic interface?)

kumavis commented 10 years ago

:fireworks: woa

mikolalysenko commented 10 years ago

Awesome work dude!

deathcap commented 10 years ago

As of the latest commits, this ndarray/gl-modules version of voxel-engine is now fairly usable, or near feature-complete: now integrates with voxel-control and voxel-physics for better FPS controls (implemented a simple readable Stream to hook up game-shell's pointer lock to voxel-control) and voxel collision detection. Not to say there aren't any bugs or missing API, going to test further integrating with https://github.com/deathcap/voxpopuli but it is getting closer...

ghost commented 10 years ago

Is there anything blocking this release, aside from the volume of differences? Can always bump the major and fix problems as they crop up.

deathcap commented 10 years ago

@substack There may be some incompatibilities or missing functionality not ported over, but imho it is at least worth merging at this point.

kumavis commented 10 years ago

couple notes:

kumavis commented 10 years ago

Tried voxel-hello-world with this version of voxel-engine. error'd.

console output: https://gist.github.com/kumavis/d195cc477351f3547a7d module graph: https://gist.github.com/kumavis/ab665acc1de2d7b6e67b

kumavis commented 10 years ago

Looking forward to merging this, but not sure what to expect in terms of backwards compatibility If we are expecting little-to-nothing to work from before, and we're simply entering a new paradigm, thats fine, just want to be sure and document that.

sadtaco commented 10 years ago

I'm having a big issue with how the "readme" doesn't work with this.

I can't figure out how to get started with a basic world, so I can then apply my own chunk generation, get a player in, and so on.

If I just 

var createGame = require('voxel-engine');
var game = createGame();

It's blank. I see no guide on how to start with this like the main branch has.

kumavis commented 9 years ago

@deathcap can you provide some guidance

deathcap commented 9 years ago

Haven't had a chance to work on this lately, but I agree the readme and voxel-hello-world demo should work with this change before it is merged

kumavis commented 9 years ago

@deathcap nice to hear from you again : )

deathcap commented 9 years ago

Hello =)

As for voxel-hello-world, started updating it (https://github.com/deathcap/voxel-hello-world/tree/ndarray), but there are many fundamental differences, made the changes for a minimal ndarray-based voxel-engine example in a separate repository: https://github.com/deathcap/voxel-example. Most notably moved toward a plugin-oriented design, even much of the core functionality is implemented in plugins (but included by default), imho this is an improvement since it'll allow different parts of the engine to evolve independently. The main entry point now boils down to specifying the plugins to load and their respective configuration options.

voxel-example functionality is not quite at parity with voxel-hello-world but it does demonstrate custom blocks and terrain generation. There are some API incompatibilities, not sure how much is worth bridging over. For example, opts.materials used to be accepted to configure the voxel types, an array indexed by the static voxel ID index, to the texture name(s). Texture handling had to be redone to remove three.js so I went ahead and changed it to use dynamic ID allocation via voxel-registry, plugins can now register their own blocks on-the-fly instead of specifying it beforehand in the voxel-engine options, and the texture handling/rendering code recognizes it. Maybe if there's demand for it the old option can be bridged to the new way, though.

Terrain generation could either use opts.generateChunks, or (preferred) listen for the missingChunk event (etc.), then generate the chunk on the fly and call showChunk. voxel-hello-world used a generator from the voxel module, had some trouble porting that (cannot recall the details), but voxel-example uses the alternate technique (more sophisticated chunk generation example in voxel-land). Could possibly support both, but I think the events-based technique is the way to go (as it is functionally a superset).

Avatars are not yet supported, but could be implemented in a plugin. three.js-based voxel-engine has voxel-player and minecraft-skin, both heavily dependent on three.js so major changes would be needed. Started on a gl-stack version of minecraft-skin in https://github.com/deathcap/avatar, but hasn't been integrated into a user-controllable physical player object like voxel-player (help welcome if anyone wants to make this; personally I prefer first-person perspective :p but would welcome third-person avatars too, the code just hasn't been written yet).

kumavis commented 9 years ago

I wouldn't worry about making breaking changes to voxel-hello-world or simply replacing it with voxel-example as the getting-started demo.

The plugin system seems really powerful, but I think you're the only one who knows how it works. Is there any doc/explanation on how author and import plugins?

Its hard to tell what's going on here: https://github.com/deathcap/voxel-example/blob/master/index.js#L7-L12

georgzoeller commented 9 years ago

I figured out the plug-in system based on voxpopuli but there was extensive work needed to restore the headless server capability on node rather than browser (gameshell requiring a document context, etc ). I have a client / server environment successfully running now but its missing lights since I have trouble with the shaders. On Feb 6, 2015 3:07 PM, "aaron" notifications@github.com wrote:

I wouldn't worry about making breaking changes to voxel-hello-world or simply replacing it with voxel-example as the getting-started demo.

The plugin system seems really powerful, but I think you're the only one who knows how it works. Is there any doc/explanation on how author and import plugins?

— Reply to this email directly or view it on GitHub https://github.com/maxogden/voxel-engine/pull/103#issuecomment-73192932.

deathcap commented 9 years ago

Considering whether it would be worthwhile to release separate engine modules (voxel-engine-stackgl + voxel-engine-threejs?), since the three.js version is still useful and more complete, with features not present in this branch I might not get to anytime soon (avatars and so on), and various other compatible add-on modules still dependent on three.js.

Downside is possible fragmentation but it may not be too bad having two alternatives. Maybe the threejs branch could continue with GH-74 and/or https://github.com/coballast/threejs-browserify-conversion-utility while this stackgl branch evolves in parallel, striving towards a compatible API. Some plugins won't be compatible with both but many higher-level plugins should be (and even more if the voxel-engine API can be refactored further ala https://github.com/andyhall/voxel-engine/commits/experimenting-ndarray).

mikolalysenko commented 9 years ago

Sounds good to me. I think forking the project is totally ok, and would also make it easier to iterate going forward.

One suggestion is that in the new version it might be better to focus on just doing a low level voxel renderer and not worrying so much about the rest of the game play elements. The goal would be to have some module which can draw a bunch of voxels from any given view frustum as efficiently as possible while supporting some reasonable set of dynamic updates/queries.

From this you could build different game engines or other higher level systems on top of it.

kumavis commented 9 years ago

while i like the idea of breaking the engine up a bit more, I don't think we should worry about a three.js branch/fork. We should encourage growth in the stackgl community instead. : )

z3t0 commented 9 years ago

How would you test this? I would like to implement it in my game. Thanks!

deathcap commented 9 years ago

@z3t0 best complete example of this branch is https://github.com/deathcap/voxelmetaverse, there's also a smaller example at https://github.com/deathcap/voxel-example

z3t0 commented 9 years ago

@deathcap Thanks! also would it be possible to work on a small guide to introduce people to the things going on here and filling it with links for places where they can learn, I am just thinking of ways to try and lower the barrier of entry to contributing to this project.