Yet Another Voxel Addon

[cogg]

Note: I'm putting this here instead of in addon releases since it's more of a library targeted toward developers and is far from finished.

Yet Another Voxel Addon or YAVA is the latest advance in "Minecraft-in-Gmod" technology.

Here's a screenshot:

http://tmp.bz/da12yvDlhW.png

And here's the code used to generate that thing:

include("yava.lua")

-- checkers.png and rock.png are in materials/yava
yava.addBlockType("checkers")
yava.addBlockType("rock")

yava.init{
generator = function(x,y,z)
local d1 = ((x-64)^2 + (y-64)^2 + (z-64)^2)^.5
local d2 = ((x-64)^2 + (z-64)^2)^.5
if d1>30 and d1<40 and d2>20 then
if d1<32 then
return "checkers"
end
return "rock"
elseif d2<5 and y>10 and y<120 then
return "rock"
end

return "void"
end
}

Unlike my previous attempts at this kind of thing, this is written entirely in lua, and has no module dependency.

Current Features
Efficient storage: Block data is packed into 48 bit integer arrays, and uses simple in-memory compression based on Roblox of all things.
Fast mesh generation: The mesh generator is designed such that most of it can be JIT compiled. I wanted to use greedy meshing, but it ended up being way too expensive and is impossible to make work properly in source without a custom shader.
Automatic atlas generation: You can just chuck individual PNGs into a directory and a texture atlas is stitched together at runtime. (Currently slightly broken.)
Multiple block types: Technically supports up to 4096 block types. Each block can have a different textures on each side.
Networking: Chunks are generated on the server and shipped to the client.

Planned Features
Different block shapes: I have a plan which shouldn't add much complexity to the mesh generator, but should allow for a wide range of custom block shapes to be culled reasonably well.
Better networking: Currently block data is networked using the in-memory compression scheme, which is pretty good, but far from optimal, especially since initially generated chunks utilize this format very poorly. Considering Source's networking limitations, implementing better compression for the wire is a big priority. I had a plan for this but was too damn lazy to implement it on my first pass at chunk networking.
Physics: Not sure how this is going to work. Voxelate implemented its own optimized trace code, but it was buggy as hell, I don't know how well a lua implementation would perform, and I'd prefer to have fully functioning physics. I'll probably just skip traces for physics and do everything with custom physics colliders.
World modification: There isn't much point to writing all this ugly code if you can't edit the world. This is very easy to implement, but there isn't much point until you can properly interact with the world.

Limitations
Textures must be 16x16 pixels. This is not likely to change. The only real reason I supported larger textures in Voxelate was because I wanted to do dumb gimmicks, like disguising a voxel map as gm_flatgrass.
A maximum of 512 textures is currently supported. This could easily be fixed but would force me to use something less optimal for the mesh generator.
No block metadata. Metadata is a waste of space for blocks that don't need it. If you need metadata, just make multiple block types. This will likely be automated at some point.
There are some weird artifacts that are either caused by bad mipmapping or by Satan.

Source (This is not ready to be used in gamemodes yet!)
GitHub

More Media

http://tmp.bz/db87Mdv9JW.png

[rrkpp__]

Whoa, this is crazy cool. I haven't kept tabs on Gmod development for a long time, it's insane seeing stuff like this. Just out of curiosity, why not use a module? Wouldn't that be a lot more efficient than Lua?

[cogg]

Modules are fun, but very few people want to actually install a module and keep it updated. If you can somehow manage to not upset the JIT, you can get lua to run very fast. The biggest issues of using lua are that you can't store integer data very efficiently, and you can't do really hacky things like inject your own shaders. That being said, developing this thing has been a lot less aggravating than developing voxelate just by virtue of the fact that I can test it so quickly.

[Trackster]

Reminds me of Minecrafts Worldedit with //sphere and so on..might i ask what this does? Because it looks cool but i have no idea what this does

[cogg]

It's for using minecraft-style voxel worlds in gmod. It's mainly meant to be used by gamemode developers.

Today I implemented a system that allows different components to pipe RLE compressed block data to each-other. The idea is that you can compose these together in any number of ways. Currently this is only used for world generation:

function yava._chunkGenerateAlternate(cx,cy,cz)
local consumer, block_data = yava._chunkConsumerConstruct()
yava._chunkProviderGenerate(cx,cy,cz,consumer)
return {x=cx,y=cy,z=cz,block_data=block_data}
end

First, this allows me to get optimally compressed chunks straight from the generator. Memory usage on my test world has reduced from 1.69MB to 1.26MB. This will also allow me to implement my more aggressive network compression very easily by piping an existing chunk to the network server-side, and then doing the reverse on the client.

[cogg]

ETA for alpha release on workshop is sometime tomorrow. I wanted to have it ready when the GCC started, but I've been debugging physics crashes for the past few hours and really didn't want those to be common in any kind of official release.

Physics meshes are currently only generated on the server. This means that it works fine in singleplayer, but is going to be a little buggy in multiplayer. I wanted to have each instance manage it's own physics, but getting traces on custom meshes on client-side entities to work correctly is impossible so far as I can tell, so the client is just going to need to piggyback off of the networked server entities.

I'll include a minimal sandbox test-bed that the average gmod user might be interested in playing with. I am probably going to regret that immensely.

[cogg]

Updated OP with new demo, new technical details, workshop page, and test server.

[Vioxtar]

I don't want to start digging around code files so asking here: is every voxel its own entity? Or is it some sort of super entity that handles all the voxels together?

[cogg]

Blocks are generally handled in 32x32x32 block chunks, but these aren't actual entities. They're usually just a table containing a data array and maybe a graphical mesh. Entities are only spawned for collisions, and only if there is something to collide with. An empty chunk, or a chunk full of blocks, will not generate a physics entity (or a graphical mesh, for that matter).

As far as vphysics is concerned, using entities for collisions is also totally unnessary. Voxelate happily spawned it's own independent colliders. It just isn't possible from lua as far as I'm aware.