Version 1.3 is now available, with many performance optimizations and improvements with Unity 5. Maintenance has been on and off over the years, as jobs and life situations change, but I plan to keep this project alive as long as it is useful. Thus far I have not seen another product with the same features (although several have come and gone with related abilities). To further help users new and old I’ve created a tutorial video of sorts walking through starting a new scene:
The latest version includes a beta version of an Octree scene manager! I’m very excited about this ability as it ensures that all of your data is always rendered at some level of detail, regardless of how near/far away the camera is. And it’s still deformable!
Please let me know if you enjoy (or have problems) using these assets. Feature requests are always welcome as well. Comment on this thread or send me a personal message.
All the best in your game development!
[Original Post: ]
I’m very excited to announce the release of this project which provides a very strong solution for some unique problems (destructible worlds fully deformable meshes), in a light weight package. This is the only package like it implemented entirely in C# (giving you full control of every aspect!)
Please post or contact me with questions, feature requests, and bug reports/problems. I fully intend to grow the functionality of this project over time and would be glad to see sharing of use scripts and modifications as users dig into it. I also intend to write-up a tutorial on how to write scalar density generating functions for iso-surface extraction which should clarify and get people up to speed quickly. Finally, a sister-project with a suite of shaders for mesh-based terrain (used in the demos) will be released to support this project soon.
I have some questions, maybe you can answer them I’m definitely interested in this but I’m unsure if it will work for my current project.
Can you convert an existing height map to a voxel terrain? Any performance improvements from doing this? This would not be an infinite terrain I’m talking about.
Can it handle complete dynamic level generation? Is that a goal? See below for more details.
Do you have any easy functions in code built in, so I could for example, flatten/raise areas under entire buildings while I’m generating the terrain? How difficult do you think it would be to create terrain that resembles a realistic city? I currently have a system that generates buildings procedurally but I’m still looking for a good way to generate the entire world itself (for example, placing forests, mountains, oceans, and cities) that look somewhat believable.
Do you plan on providing a few different noise functions so users can generate the terrain without coding their own? I know this can be a time consuming process so anything out of the box would be awesome
Does this play nice with AI solutions out there, like arongranberg’s A* pathfinding? A* Pathfinding Project
Those are really my main questions. I know it’s a lot so I appreciate your time
@bens1984 Bought it! First impressions are very positive. I’ve been messing with the public variables in the inspector and getting fun results. I’ve also been browsing the scripts and documentation. The documentation isn’t as sparse as you let on – though being as unfamiliar with the inner workings and terminology of marching cubes I’m doing a bit of guessing as to what is doing what and some passages I’ve no clue.
My goal right now is to get the ray gun in your demo to create square voxels on the smooth voxel land for creating buildings and other man made structures. How would I call a perfectly square voxels to be placed? Looking up the marching cubes it looks like case 0 is square empty and case 22 is square full. Which script would I do that on? Thank you.
I have a question about the nature of the voxel data being used in this application: Is the data simply a binary yes/no as to what is located at a point or is it set up to handle multiple materials? What I mean is could you differentiate between air, dirt, rock, coal, iron, bedrock based purely on the voxel data being stored?
May I ask if you use a special algorithm for triangulation since this is not a triangle soup? (Shouldn’t be very easy to do this efficiently)
In my project I need to do a lot of modifications, mostly digging through the voxel data and I need a re-sizable sphere/cylinder/capsule shaped collider for the modification which might involve a few chunks simultaneously! Do you have a demo showing a sample like this:
I’d love to see something like that in your engine, TBH, I’m saving my money for TerrainEngine (in case no-one gave me the money for it ), but I need an affordable/working/supported voxel engine to work on my prototype before actually spending $3K, and I’m looking after your project.
@dl_studios: glad you’re digging it! For regular old, minecraft-voxel cubes you would want to push in scalar density data that will cause the marching cubes to produce cubes (you don’t want to reach inside those scripts, although you are right about the 0 and 22). The terrain demos use one “density map” (think height map but in 3D) for the whole space to enable digging and building land. For discrete structures (buildings, etc.) you may want to instantiate new density field/march cubes areas that make cubes. The ice-sculpting demo uses discrete “blocks” of ice, which are quite large, but you could look at that and think about it.
One problem is that the engine will always try to bevel the edges of the cubes (producing diamonds, or buildings with beveled roof/corners). I’ll have to think about how to defeat that.
@Socrates: it is not binary, it’s continuous scalar data (that’s the only way to have smooth deformation). You could easily define ranges of values (where currently < 0 is “air” and > 0 is “dirt”):
< 0 = air
0 - 1 = dirt
1 - 3 = rock
3 - 5 = coal
5-6 = dirt
6 - 10 = iron
10 = bedrock
and then you have to handle rendering this out. I will put in a hook that bakes the density values into the mesh Color values–something I’ve been thinking could be useful–as this would allow you to write a shader to display the correct textures and then modify the sculpting/deformation code to respond differently for the different material type (dirt “digs” faster than rock, etc.)
@Rico:
yes, it would be easy to do. In fact I’ll do it this coming weekend! The advantage is that you could easily allow the player to dig into the ground, or blow up subterranean bombs, or crash ships into the earth, or construct earthen defenses, or…
this is the goal! I’ve got some good tree algorithms I’m toying with and will bring out soon. Right now it’s terrain only (but perhaps many materials, formations, etc.).
I don’t have them written in yet, but in theory it’s pretty simple. Doing it at run time would be very easy. Doing it in the editor less so at the moment. My editor tools are static right now (open the wizard, tweak some parameters, bake a new landscape mesh. Repeat as desired).
Yes. I have classic and perlin noise at the moment. And you have full control over number of octaves, base frequency, strengths, warping the noise lookups, and more.
It will play nice with any AI (I’m assuming you mean mostly navigation systems) that looks at mesh colliders at run-time. The one you linked should be easy–they say it generates nav meshes at run time. Eventually I’ll have more in-editor tools to allow packages that need to build pre-run. I’d love to see some AIs navigating around the landscapes that I’m delivering “out of the box”! That’d be wicked.
Thanks for the advice on how to go about making cubes. I’ll give that a go. But before I do that I realized I might have a larger issue. I’d like to use Ruaumoko for an iOS game. But at the moment it’s not building to ios. I get the error:
Unsupported texture format - needs to be ARGB32, RGBA32, BGRA32, RGB24, Alpha8 or DXT
UnityEngine.Texture2D:GetPixelBilinear(Single, Single)
c__Iterator2:MoveNext() (at Assets/Ruaumoko/Plugins/RuaumokoDensity.cs:205)
My guess is that for whatever reason the maps created by the noise algorithm are in the wrong format. Is there a work around for this?
dl_studios: it’s not the internal noise but the bitmap that guides the noise. Find the texture “gradients” in the Shared/Textures folder and change the Format (it’s the last option at the bottom of the Inspector window, probably says “automatic compressed” at the moment. Change it to RGB24 or one of the others as the error specifies). Hit Apply and it should get you past that one.
Let me know how it does–I have no idea what it’ll be like on iOS but post your findings here, lots of others are keenly interested!
3K?!? Holy *^#@ I can do all of that, and I will (and show you too). At 1’22" or so you see how far behind the deformation lags the cursor?? And the framerate: it’s like 25fps or so and there’s no other game play. Either they made the video on a crap system or it’s very heavy on the CPU.
Also, all of the voxels are beveled, as I noted mine would be as well. I have some ideas to make them true cubes (since it seems so attractive to many), but in the mean while mine are fully continuous and smooth. I will put in a toggle to reduce it to beveled, like in this video, but it’s actually simplifying the engine to do that (taking out the more accurate smoothing calculations).
Now to put my words into action… might be days before I find time.
@bens1984 Thanks for the help. So in response to the anticipated question does it build the answer is…sort of. I’m new to Unity and programing in general so I hope those interested can be patient with me here.
I’ll give you all of the errors and what I’ve done to try to get around them and the results, just in case I introduced new errors.
The first error that appears is:
Assets/Ruaumoko/Demo Scenes/IceSculpting Prefabs/Lightning/Scripts/Lightning.js(113,99): BCE0005: Unknown identifier: ‘i’.
I have no idea why it would be complaining about those since it runs fine normally. So I just declared the variables at the top of the Lighting.js doc as public floats–my guess is very dangerous as far as programing goes, but I just wanted a quick hack to get it to stop complaining. At any rate, it stopped throwing an error.
After that it threw the error about the texture. bens1984 your solution worked(I changed gradients to RGB 24 bit) and it allowed me to play the game in the editor.
I then built it to the device, it began to run. On my 4s I could see the skybox and I could look around and tap to shoot lighting. No land appeared. Then in xcode I got a thread error: Thread1:EXC_BAD_ACCESS(code=1,address=0xc))
Photo below to see thread error in context.
Well, this is a very special case, he claims that his package is very optimized and yeah, the video has been captured on a pretty old dual-core PC.
His customers seem pretty satisfied and I’m pretty sure the best part in his product is his support, which can be VERY useful
Package has been submitted with an update to vrs 0.12b, including the planet generation code and new demo.
@Banksy - nice vid! The hands animations make it look really cool.
@Curious: the demo’s at the top of the post!
I also added a sculpt mode that uses a cube brush, however the beveled voxels are still in effect so it’s still more on the smooth side.
The “non-triangle soup” solution is two parts: first generate all the vertices but only make each one once (loop through only creating vertices for voxel edges 0, 3, and 8, because all the other edges will then get built as a 0,3, or 8 of another voxel). Then use a lookup table to generate the triangles, sharing the vertices on each edge with the neighboring triangles.
I’m frequently making meshes with 40K vertices, using my current model, and if I was generating each vertex 5+ times Unity would scream at me. If using the lookup to share vertices incurs any performance hit it’s made up for in increased functionality by making real meshes (so normal and tangent calculations work great, deformation works, dx11’s all good…)
@dl_studios: I’m glad you’re on the iOS! But I have no idea what that Xcode error is. Can you post the image or PM it to me? Did you try one of the other demos, such as the “IsosurfaceWorld” scene? It has less stuff in it so it might help isolate what’s causing the problem.
“IsosurfaceWorld” built on the iphone! My guy was able to land on the generated ground and look around. That’s one small step for virtual man, one giant leap for ios gamer kind.
There are still a number of performance issues that need to be ironed out. It took 40 seconds for the game to go from the Unity splash screen to game play, and the frame rate is choppy. But still, it ran! How to optimize is the question now.
A thought: I’ve been reading around and came across dual contouring. http://procworld.blogspot.com/2010/11/from-voxels-to-polygons.html
I don’t know if you’ve given it any thought, and if it is a possibility, but it looks like it is a lot less limited when it comes to crispness and precision than marching cubes. In the end it might make things easier for you to get any shape customers want.
I saw the latest demo, tnx
First, I want to congratulate you, the mesh looks really nice and smooth
I can’t really say anything about the performance though, as I can’t see the framerates, the very miliseconds it took to create the n^3 sphere voxel data, the RAM usage amount, the digging speed and resurfacing speed… I’d love to know more about the scene (And a FPS counter there would be nice)
What is the voxel dimensions? How many chunks are there in the scene? And please note that the planet in the video I mentioned before was really HUGE, how about an updated planet demo that lives up to its name? A planet
This will let you make one as big as you want (bear in mind that the voxel count in the lower corner is cubed in actuality. Planets over 256 ^3 will take time to generate!). I have it maintain 10fps while building, which slows down the total time but lets the progress bar fill up. Once it’s built I’ve had huge meshes deforming at 60fps (clamped at screen refresh rate, so could be faster possibly). I’m attaching a wire-frame image.
The “planets” demo has 4 spheres, with varying numbers of voxels. The smallest is 32^3, the largest is 96^3.
@dl_studios: that’s great news! I wonder what are the best steps to optimization… Let me know if you get any of the others to work (the ice-sculpting one, maybe?). It could be that the isosurface scene generates too many polygons for the phone (and the generation clearly takes time - 40 seconds in your case). You could mess with the parameters to have it build a smaller scene… try this: Set the “TerrainTest” scale higher (4x4x4?) and pull it down in Y in the scene (otherwise you’ll spawn below it). Change the TerrainDensityGenerator script “Size” to something smaller (64?). Also change the material it uses to something simpler (it could be the shader that’s not optimized for iOS!)
@Victomeyezr: sorry about the docs. They’re coming along, but not top priority yet. I hope you can poke around and try changing the scenes to figure out how things work. You should be able to duplicate them at least.
I’m definitely interested in this but I’m unsure if it will work for my current project.
