Change to use stackgl (ndarray/gl-modules) instead of three.js (needs testing; help welcome) #103
Conversation
voxel-texture 0.5.0 switched to use texture atlases, packing all the block textures into one graphic for efficiency purposes. However, this introduces two problems: - With the culled mesher (default as of voxel-engine 0.17+), I get serious lag spikes (30-60 ms frames, or unplayably higher) when placing/breaking blocks, and also slow page load as the meshes are built (see voxel/voxelmetaverse#10) - With the greedy mesher, performance is much better (fixes first issue) but textures are stretched across each of the greedily constructed meshes, instead of tiled across each block (see voxel/voxelmetaverse#14) Example: https://f.cloud.github.com/assets/5897956/1651233/1f478c9e-5aca-11e3-82cc-4028f1e1b1da.png There are techniques for texturing greedy meshes, detailed in this article: http://0fps.wordpress.com/2013/07/09/texture-atlases-wrapping-and-mip-mapping/ - Using array textures is ideal, but they won't be supported until WebGL 2.0 at earliest https://www.khronos.org/registry/webgl/specs/latest/2.0/#3.7 - Otherwise, they can be tiled manually, but this requires a few tricks, would certainly be worthwhile to implement, but is fairly complex. Maybe later, once I understand it better. So for now, (unfortunately) I've reverted back to voxel-texture without atlases. This keeps mesh recalculation fast (when breaking/placing blocks) and avoids stretched textures but may slow down complex scenes with many materials (see performance improvement @shama noted in #69).
…y switching mesh type
With this change you can now change in-game (e.g. with voxel-debug):
game.meshType = 'surfaceMesh'
game.meshType = 'wireMesh'
and explore new chunks, then the old meshes will be properly cleaned up (vs crashing).
Allows you to dynamically change the mesh type at runtime:
game.meshType = 'surfaceMesh'
game.meshType = 'wireMesh'
then explore new chunks, and revisit old (unloaded) chunks -- the
new meshes will be displayed correctly, instead of overlapping the
older mesh type. With this change and c845d3f, meshType is now only
used for determining the type when _creating_ new meshes.
Useful for refreshing after changing rendering settings.
…mic material loading.
Unused, so removed -- was accidentally added in deathcap@47a05ba
Moved to voxel-texture deathcap/voxel-texture@fd5b723 This reverts commit c674690.
(required for kb-bindings-ui)
deathcap/voxel@b45d02d Export the transgreedy mesher deathcap/voxel@3800e7a Add transgreedy mesher by @vogonistic Commit message generated by https://github.com/deathcap/lmno-cl
deathcap/voxel-texture@a58b287 Add custom ShaderMaterial supporting greedy meshing + atlas texturing deathcap/voxel-texture@dad8347 Remove material option configurability Commit message generated by https://github.com/deathcap/lmno-cl
deathcap/voxel-texture@0946124 Add 4-tap sampling to fix artifacts near texture boundaries deathcap/voxel-texture@83bc801 Discard transparent pixels in fragment shader Commit message generated by https://github.com/deathcap/lmno-cl
This reverts commit 791c74a. Conflicts: package.json
deathcap/voxel-texture@32d3847 Change to load textures using 'artpacks' module deathcap/voxel-texture@57998e0 Remove optional require('three') deathcap/voxel-texture@6a90b85 Add three.js shader chunks, fixes missing lighting deathcap/voxel-texture@3f1b5d5 Cleanup tileSizeUV / tileSize unused code Commit message generated by https://github.com/deathcap/lmno-cl
According to http://webglstats.com/#h_texsize, 100% of WebGL users in the wild support up to 2048x2048 textures. With 4x4 repeated/padded textures 16x16 each, this will support up to 1024 textures per atlas.
Revert "Use more compatible texture API" This reverts commit 58967db. Conflicts: index.js
|
I wouldn't worry about making breaking changes to 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: |
|
I figured out the plug-in system based on voxpopuli but there was extensive
|
deathcap
changed the title
|
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). |
|
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. |
|
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. : ) |
This allows plugins to perform actions which require all plugins to be initialized (for example, calling showChunk which requires the mesher and stitcher and shader to have loaded, and set in the game instance).
voxel-raycast can return a hit normal of [0,0,0] if, for example, the starting position is within a voxel, but this is not a valid normal vector. If this happens, instead default to [0,1,0], the top face.
|
How would you test this? I would like to implement it in my game. Thanks! |
|
@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 |
|
@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. |
Branch from max-mapper/voxel-engine#103 ndarray
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 voxel/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.