Voxel engine in Unity

Hi everyone!
So, this morning I was playing voxelstein 3d and got on a voxel kick, I started working on a voxel engine in Unity and was surprised at how great the performance was. I've been trying to make it as efficient as possible, and even in scenes with >16 million voxels I was still getting over 1000 fps.
There's still some optimizations I can do.
But I wanted to see what people thought or maybe get ideas for things I should add to the engine. Some obvious things would be water behavior, caves to the terrain generator, etc. But I don't want it to just be a "Minecraft-like" engine, I want it to be more general than that. I'm pretty excited about the prospects for easily deformable terrains (like a tank-battling game or 3D "Worms" game), or carving/exploding through walls of an FPS (like voxelstein 3d).




Here's a web player of a terrain/minecraft-clone example. It takes a while to start up though, virtually all of that time is generating the collision mesh, which I still need to optimize better. I had one method that did it about 7x faster, but unfortunately it stopped working (now leaves strips of "empty" mesh) and I'm not sure why. So for now it's the "slow but works" version.
Once it starts it should run fine, I get about 800-1600 fps, depending on how much of the scene I'm looking at.

http://www.porcellus.com/voxellus/voxellus.html

Please, if you get the time, let me know what you think!

Cheers,
Will

 

Totally sweet, nice terrain man

 

Ran really well on my MBP (it's a 13 incher from 2009). No apparent hitches on chunk rebuilds either

I'd be interested in hearing about how you went about this (ie: big 3d arrays, octree, etc). When I messed around with this type of thing a while back I used large arrays and wanted to see how an octree would fare but I never got around to it :/

Have you tried implementing your own collisions? Since the blocks are large enough you could do away with collision meshes altogether fairly simply by doing worldspace to voxelspace transforms (smaller blocks might make this method look funny).

As for additions, I think having a voxel to physics cube to voxel system would be handy. Say you are looking at a wall and you have some kind of explosive. You set it on the wall and rather than the blast simply destroying the material it actually flings debris outward that reacts to the world and when it comes to a stop is 'revoxelized'.

Another idea is that if you're not dealing with infinite terrains (which makes this a hard problem) you could add some kind of structural integrity checker. You could check if a block has a path to ground (the bottom of the world?) and if not it collapses. This could be extended so that if there isn't a good enough (say it's too long or some such) path to ground it collapses as well. Would be useful for knocking down buildings.

Anyway, great work. You did that in a day? Since this morning? Good job!

 

Awesome!

 

Pretty nice, but it it constantly gives me hick'ups when I remove a cube. :|

 

cool
I would say keep it simple.
make it easy for others to build a specific terrain as opposed to the infinite random trend.

Easy definable cube (characteristics if possible) and world dimensions
hand "Paint" the terrain / generate from heightmap/ or "just" build by layers would all be great additions
Physics would be the Top!

PS: runs fast, my only concern are the shadow/ black areas - sometimes cannot interact (destroy cubes), it would be best if there where no black sides at all.

 

Great! I have a quad-core Mac Pro (also from '09) so I worry about performance on other machines/laptops.

At the moment it's just one big array. I intend to implement octrees in the future. When I started I just wanted a proof-of-concept and then I figured I'd optimize until it ran well. To my surprise it ran well pretty much from the beginning (Unity never ceases to amaze me!), but there's still room for improvement.

I have thought about that, it would be a lot more efficient, but with collision meshes I get all of Unity's physics for free. Perhaps the ideal solution would be somewhere in between, with characters and non-bouncing/rolling things handled manually, but occasional physics-important objects still using a collision mesh. Some games could go without Unity physics (a straight Minecraft clone, for example).

Ah, now that is a great idea. I was thinking I'd just "hide" the instant-destruction by having thick explosions using the Detonator system. But an explosion combined with rigidbody cubes would look incredible, and take advantage of Unity's physics.

That would be cool, especially for a shooter, might be tricky defining which blocks should/shouldn't fall, so for example caves or archways would stay intact.

Yup! Thanks! Once I got started I just couldn't stop heh, it was very exciting. Usually when I'm working on a game I'll spend days/weeks trying to make something fun/balancing/whatever, it was really refreshing to just be working purely on math/tech .

Thanks for the input!

Cheers,
Will

 

That's a shame, what system are you running? If I can get my alternate-collision-mesh generating system to work, it would reduce chunk rebuild time by a factor of 7. It's driving me a bit crazy because it was working earlier, but recently something I did has broken it.

Thanks for the input, at the moment the terrain in my example is generated from a heightmap. Adding a sculpting/painting system is a good idea, since it would be really easy with voxels. The black areas are annoying, I agree, they're a result of me just using a Unity light. I plan on doing a manual light system/shader eventually, both for efficiency sake and to allow for insides of buildings/caves, etc.

 

For the collision mesh to be faster, you should just generate a collision mesh from the blocks close the to the player. Only regenerate this upon them moving a certain distance from the current 'center' of the collision mesh.

 

Lego bricks!

 

There's an idea. If you paired that with custom simple physics for chunks farther away from the player you could get 'real physics' where it's needed and save on computations.

 

Nice job - runs well for me!

 

Hiccups when removing cubes here as well.

My system is at least twice as powerful as yours so I doubt it's my performance.

Also, these aren't really voxels, but textured cubes, right?

 

Good input, I'll see what kind of impact that has on performance.

Heh, well that's a topic that's up for debate , some people say it's only "true" voxels if it's raytraced . But yeah, it's voxel data, converted to chunks of polygons. Though very few are actually "cubes," since only the exposed parts of the voxel map are generated, so most are just two to four triangles. A full cube would only be generated if a "solid" point was surrounded by "air" points in the voxel map. The cubes could be made smaller and smaller to make a game less "blocky."
Sorry about the hiccups, I still have optimizing to do.

Cheers

 

Uploaded a new version of the web player, you might have to clear your cache if you played the last one already.

1) Fixed my more optimized chunking/mesh generation algorithm, now about 7x faster than before.
2) Added TNT! press 'r' to place tnt and blow holes in the terrain.
3) Added a second Unity light, so the scene is less dark/more evenly lit. This is a stop-gap until I get a manual lighting system working.
4) Improved the way the 'selected' block is determined. Making digging (and placing TNT) more accurate.

http://www.porcellus.com/voxellus/Terrain.html

 

Very interesting, maybe someday voxel systems will be so efficient they'll replace polygons. I spent a good half hour just tunneling to the bottem heh.

 

works great,
Different Cube sizes 1/4 or 1/9 would amplify the constructability exponentially

 

Awesome, that was fun!

 

Wow!

 

msi gx623 laptop.. or did you mean something else? I was using FireFox 5.0 and whatever Unity web player I installed a couple of weeks ago. :/

[edit]btw: The new version doesn't seem to have the hicups.. but the tnt works in mysterious ways. For one.. I can spawn the tnt in mid air by simply point at another tnt piece... aka.. i can build a tnt bridge..

Also.. at one point the tnt blew away certain pieces of the.. world but not others which were right next to it.. its hard to describe but it didn't seem normal.. basically it blew away stuff and created a crater except that some cubes stayed making another bridge in mid air above the newly created crater.

and I dug through that terrain of yours.. it looked kinda funny when I was falling down and could see through the terrain.. but I goes that its the way it works. :|

 

Question will you be selling this on the asset store?

 

Yep, that's what I meant, just wondering, trying to get an idea how well it runs on different specs. Good to hear that my optimization fixed the problem. Yeah, the TNT is a bit weird now, I was a bit lazy with it's implementation since I'm still prototyping . It gets the idea across, though . Thanks for trying it out!

lol, yeah, I should probably add a floor/bedrock to the example so you don't fall into infinity by digging too deep.

Good question, I haven't really decided what my plans are for it yet, I have a few game ideas bouncing around though (most using a smaller block-size) once it's more fully-featured I wouldn't be opposed to writing up some documentation and selling it if people are interested.

Right now I'm working on the inventory system, so in the next version you'll pick up the blocks you destroy and be able to place them. Then I'm going to add support for transparency (water/glass). Stay tuned!

 

Alright, I've got a rudimentary inventory system, at the moment you don't pick up blocks though, but you can place some blocks. The main thing I added was transparent blocks and a water system. The water will flow into empty space/down hill. How often the water updates can be set, but the more often it updates, the harder it is on the system, but the more "flowy" the water becomes. For this example I set it to '10.' Which seems like a good balance for speed/performance.

http://www.porcellus.com/voxellus/voxellus.html

 

Once again, really fun! Good job!

 

how does this apply to development on a larger scale with higher quality? Right now it just seems to be a nostalgic dig-dug 3d type thing.

 

Thanks!

Well the limit is really your imagination, I did a Minecraft-like example because Minecraft is the "highest-profile" voxel based thing around right now. The blocks could also be smaller, but imagine a castle defense game where you build your own castle, or a prison escape game where you can dig through the walls, or a flight sim where your bombs leave actual craters, and blow through the walls/ceilings of buildings etc.
The appeal of voxels is mainly the on-the-fly-deformation, and ability to have enormous environments that draw quickly. For example in that test scene you have over two million blocks, but due to mesh optimization it can draw at 100s of frames per second (Try that with Unity cubes ). I've only been working on this for about 4 days so graphically it's just a prototype.

 

Red Faction and Battlefield come to mind, are they using a similar method to destroy environments?

 

no, battlefield, for the terrain, just uses basically splat maps that deform the terrain below its standard height, and thusly does not go lower than one deformation in height. As for the buildings and trees, those are all effectively pre-fabbed to destroy that way.

 

Interesting with the terrain... With the buildings I have definitely noticed the consistency and assumed thats what they were doing. I wonder if Red Faction does the same? It seems much more procedural with RF... unless they have level designers with +93 to mad skillz.

 

Red Faction used their own "Geomod" engine. From what I remember hearing about it, they had spheres/other shapes as "anti-meshes" which would "cut into" the level using some kind of boolean geometry algorithm and tell the renderer not to draw the intersecting part of the level mesh, and to instead draw the inside of the intersecting "anti-mesh." I might be wrong about that but that's what I remember from reading an article about it years ago...

 

Woo! Alright, I wrote a script to load .binvox files into my system, which should make it a lot easier to make interesting levels and objects, since binvox can convert from obj, dxf, vrml, and other formats:



More info about binvox can be found here: http://www.cs.princeton.edu/~min/binvox/

 

Okkk ..that's awsome..I will look forward on that

 

You know about Voxatron, right?

How's this engine coming along?

I thought you'd enjoy Voxatron because it's different than just a minecraft repeat.

 

Hi gl33mer, yes I actually stumbled across Voxatron while doing research for Voxellus, it does look really cool, I'm excited to play it but don't think I'll have any time to play a new game this month :/ .

I've also been distracted making some games on the side, but I have been making a lot of silent progress on Voxellus!
Unfortunately I haven't been able to upload a webplayer for a while, since now Voxellus relies on a local harddrive to cache terrain data, so I'll list the changes here, then i'll go into more detail, with screenshots!
1. Reworked terrain generation, major optimizations to loading/storing terrains.
2. More local-oriented/flexible/integrate-able "worlds." (Hard to explain exactly what I mean here, see detail below).
3. "Biome" class that contains rules for generating terrain, and what blocks to use in that biome.
4. Changes to water system.
5. Inventory/NPCs


Through various means I've reduced the ram footprint of a given area of terrain to about 1/12th of what it was the last time I built a web player. Making for much bigger worlds, much faster. I don't think I can make it any tighter now.


Everything about the "worlds" has been localized/internalized to make them more flexible and friendly to the "outside forces" of a Unity scene. Now you can have as many separate "voxel worlds" as you want, moving around in your unity scene, and registering collisions with anything to change geometry. Earlier that would have been quite impossible, because it made a lot of convenient assumptions about the position of the terrain, I rewrote the functions for getting and setting blocks, so they can translate the global unity coordinate system to those of it's voxelmap. I left the old functions in as well, since if the terrain is built around the origin and unmoving, they're (a tiny bit) more efficient. For example in the screenshot above, there's a small "voxel world" sliding around on a unity terrain, and it can be interacted with and built on without issue. Off the top of my head this could be useful for a game of players building and destroying each others' floating islands, airships, etc. Or two planets (spherical terrains) firing missiles at each other. A cannon ball could be launched off of one moving terrain, using Unity physics, and collide and smash blocks out of the other moving terrain. Outside of some really buggy mods, I don't think Minecraft is capable of that . I'm planning on making an example game like this soon. You might also notice in that screenshot, there's no problem with using specular/normal/whatever maps, the only requirement is that you have to tile your specular/normal/whatever onto one atlas (so the terrain remains only one material). [Not exactly a requirement, but adding a second material would double the number of chunks being processed in a terrain]



Biomes! Sections of terrain now generate based on rules in their "Biome" class. Biome's describe variables for the terrain generating algorithm, what blocks to use, what depths they can be used at, whether water can spawn, etc. Also a block type can be set to spawn under/around water. For example, in the screenshot above, sand spawns only under water.


Underwater! There's now an underwater checker, which detects when the player enters/exits water blocks, and handles splashing, turns on it's attached underwater sound and underwater visual effects. (I'm also pretty proud of how my 'underwater effect' looks )


I'm not sure if this should be "engine-level" or "game-level" but I've got a usable inventory system now, complete with drag-and-drop icons, tooltips, and quickbar. Also the inventory is persistant (saves to hard drive when modified). I've also got some basic NPC interaction and AI going (like raycasting to know when to 'jump' up blocks to reach a target/waypoint), but there's not much to look at, since that would be game-specific anyway, for now I just have placeholder art and strings for them.

I've also gotten a few private messages and e-mails from people asking if it's for sale, so thank you for your interest in my project! I'm still not to the point where I'm comfortable doing so, the code is not really human-readable at the moment, very few comments and no documentation :razz:. If anyone interested in buying this kind of thing is reading this, let me know what kind of features you'd want and how well documented you'd expect stuff to be .

Cheers!
~Will

 

Sent you a PM.

 

I've released a game using my engine on the Mac App Store, a sci-fi mining game which I intend to continue to add to over time, and my goal is that public feedback from that game will help me further improve the engine.
So now I've begun cleaning up and documenting the code for a Unity Asset Store release.
Some of the new features I've added recently are a new custom-lighting engine, by using this system I've eliminated all actual "Unity lights" from the scene, resulting in better performance, appropriate 'cave' lighting, etc. As well as support for 'block emitted' light, ala Minecraft torches.

A green "light rod" illuminating this player-dug tunnel:


A scene outside with the new lighting:


And the lunar biome:


Versatile, Terraria-style crafting system:

 

how do you make the crafting system?