Introducing Voxelform - voxel terrain (Marching Cubes) with real-time deformation.

Thanks guys! Just kicked out a minor update to the demo that should allow closer chunks to load faster and corrected a fog issue as well.

 

Just added a video on YouTube as well.

 

great pretty chunky play now adays but cool with the infinite ness...

 

Yeah, peformance is much better now, but to make up for that, I've extended the landscape out quite a ways. I get a typical frame rate of around 60-80 fps, sometimes up to 120 and occasionally as low as 45. The current demo will take advantage of multiple cores if you have them, so that makes a difference now too. It's tuned to my quadcore rig's performance and I've haven't tested it on any other configurations yet. If you watch your memory, you'll notice that digging doesn't have much of an impact, although it'll rise and plateau for other reasons. There shouldn't be any noticeable GC hiccups either.

 

2.6 Dual Core 4GB Ram, 8800GTX 512

slow chunk update
32FPS-50FPS

Web Applet

Very nice though

 

@runner - Thanks for the specs!

Here's another "lite" demo, which is essentially the same thing, but with less detail. It should run a bit faster if anyone would like to try it.

Lite Demo

 

Hi Mark, very nice demo, the performance are pretty cool !

What is your roadmap about the next release of Voxelform ?
Version 2.x or Voxelform v3 and when will this be available ?

Maybe could you tell us a little bit more about this because I'm currently using Voxelform for a project and I would like to know if the next release would be compatible with the 2.0.

Very nice job Mark !

 

Can this also raise the terrain to make a mountain?

 

Yes it can. The f(x,y,z) function that generates the geometry for each voxel (in real-time) that you see in the demos, starts with a 2D Perlin fractal noise function that creates a fractal mountain heightmap and then a 3D Simplex noise function is applied to the resulting heightmap to give it a more fantastic look. The more the Simplex noise is dialed down, the more traditional the look becomes.

One of the nice things about generating a world in this fashion, is that you can generate a world on the fly with 79,228,162,514,264,337,593,543,950,336 voxels at your disposal... or more if required, but that seems like enough to me... and no additional memory requirements. So it's possible that you could create whole solar systems with any type of mountain you wanted on the surface of the planets. Currently if you wanted to do that, it wouldn't be possible to see a planet in the distance and then fly to it, have it get larger and eventually land and keep everything as voxels at the same time. That may very well be possible in the future, but currently what would likely happen is when you got really close to the planet's surface, that would be the first time you ever even knew it was there. Of course you could sub in a planet model with various LOD and then swap in voxels close to the surface or do the same with voxels in space and then performance some type of transition... perhaps an excuse would be the fiery entry into the planet's atmosphere where you can't see anything and then suddenly you see clouds and pop through to the voxel terrain below. You could use the entry time to load in a large area of terrain so that the only chunks loading in upon "landing" would be off in the distance.

FYI - For all reading this post... this is speculation regarding an unreleased version of Voxelform and not the product currently available on the Asset Store.

 

wow this is phenomenal! I would glady pay again for an update like this. Is it possible to have pre-existing caves generated underground too? The second demo ran smoother for me, but I miss the fog... I really love this, keep up your hard work!

 

Hello

I am new to Unity and building games. I am using the free version of unity. I also use MAYA, ZBrush, Photoshop DAZ studio 4
Questions about the Voxelform program?

1. Can I make the Voxelform caves and above ground terrains in Unity?

2. Do I make the caves and above ground terrains in Voxelform and import them into unity?

3. Whether I make the caves or above ground formations from Voxelform, can I use the textures and other tools in unity to further design and shape my terrain. Can I add my trees, bushes, water on the Voxelform formations?

4. To make the caves and above ground formations do I have to script them or can I just start sculpting them like you can in Unity?

5. I am not a programmer or script writer. Would the program be of no use to me?

6. Are there other vids out that show how you actually use the and explain the features of the program? Great vids on making a cave and some structures, but I would like more visuals on how the program works.

Thank you for your time and help on my questions.

 

I was wondering if anyone has found a more efficient method to Altering voxels that keeps the frame rate up. I find that when altering voxels my normal frame rate of 80fps drops to 4 or 1 fps. I am just using the prepackaged voxelinteraction script.

 

The reason for this is because the way that script is setup up, it makes minor changes to every voxel its editing every frame that the user holds down the mouse button. This translates into the each chunk that has at least one edited voxel must now update its mesh every frame that the user holds the button down. Rebuilding those chunks is relatively fast but its not fully optimized in its current form (this is an entirely different subject though). However if you happen to modify a sphere of voxels that crosses multiple chunks it will get very choppy (the worst case here being if the center of your sphere sits at the seem of 8 different chunks... arg).

To maintain frame rate you are going to want to limit how often these chunks are built. You really don't want to hit altervoxel each frame (in my opinion). I would suggest putting in a delay of some sort that staggers out the altervoxel calls to some greater period than every frame. I am solving this problem by eliminating the minor volume changes to the voxel each frame and using something else to demostrate the removal effect. The melting effect is cool but its a result of altering the voxels a tiny bit each frame and rebuilding voxel chunks is a beefy enough routine that this just isn't a good approach in my opinion.

Also understand that the speed of rebuilding those chunks is a linear function of the number of voxels per chunk (in each dimension). I think the default is 8,8,and 8 (X,Y,Z). I use 16,16,16 and it gives me better rendering performance overall since unity doesn't use as many gameobjects but it slows altervoxel down even more. Like I said I don't use the melting effect and alter the voxel to its final state in one go. I then don't let the user remove any other voxels for about a quarter of a second. The effect is far less smooth but the frame rate stays constant.

Hope that helps a little...

 

This organic terrain looks amazing. I was wondering Mark Davis or maybe someone who has already purchased Voxelform, would it be possible to create small demo, just with non-triplanar shader, just basic Unity diffuse shader without any texture, just brown color put on material. I am really curious how much better does it get performance if you arent using triplanar shaders, becouse i am quite interested in purchase.

 

1. Yes
2. No, Voxelform is integrated in Unity
4. You can sculpt them
5. I bet it's pretty easy to use

 

This would be possible but only because you are coloring the terrain one color. I really doubt you'd get that much better performance though. In my opinion any performance issues are a result of marching cubes just simply generating a lot of tris and the fact that we can't share verts for those tris, coupled with trying to run altervoxel every frame. The infinite terrain demo has performance issues for entirely different reasons I would guess (we haven't seen that code yet). If you check out the previous demos we don't get nearly the performance issues when using a static area.

The reason one color will work but just barely is because Voxelform doesn't imbed UV coordinates (well technically all uv coordinates are Vector2.zero), by default the shaders take care of this using the vertex coordinates as a base . The side effect here being that if you move or rotate the terrain in any way the texture mapping changes in interesting ways (because your vertex coordinates change). So for instance if you have a static asteriod that sits in the same place the whole game you could use a voxelform terrain for that, but if you want it to move or rotate the asteroid dynamically voxelform won't be a good choice.

That said if you know what your doing this is a great kick start. I have gone in a completely different direction than Mark is heading, so I had to make a lot of modifications to what is there (and its easy to read and reasonably documented so this wasn't a problem). Voxelform was well worth the money for me.

 

Oh ok, i am just trying to figure out how to get better performance, becouse at the momment it is very slow on my computer. If you think that changing material wont work, what would be best option to increase performance?

 

Your opinion seems quite right except for the fact that vertices can't be shared:
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html Section: 1.4.4 Generating a Block: Method 3

I don't know if Mark generates the geometry this way though.

Maybe you could just project the vertices back into object space before applying triplanar projection.

 

Wow thanks for that link. The triplanar shader code listed there is very similar to the code in Mark's shaders (at least the projection formula is). The methods listed though apply to generating terrain within the GPU (which would be awesome but unpractical and probably unworkable when using unity). Though you could translate those methods to the code where the mesh is built. He certainly isn't using method 3 (only building verts on edge 0,3,and 8 and using a lookup table for previously generated verts).

As for the vertex sharing issue the code comments suggest this has to do with how normals are produced. The triplanar shaders will seemingly stretch the texture in unsightly ways unless you blend the vertex normal with a flat normal that is triangle specific (note triangle not vertex specific this is why we can't share them) and a blended normal that he derives through sampling surrounding voxels. So in essence the vertex normal is weighted based on the triangle it is included in.

That probably wouldn't work as the texture sampling would likely get messed up along chunk lines. For instance we have two chunks that are aligned along the x axis. chunk 1's (8,0,0) voxel would be right next chunk 2's (0,0,0) voxel and it would create a seem between the two since we are basing it on object space. In world space they are nicely aligned at (8,0,0) and (9,0,0). Now if we only use one really big chunk to render the object as opposed the multiple chunks we don't have the issue.

As a side note I did modify the code to add UV coords back in by just translating the projection that was done in the shader but in the code where we build the mesh. It took me a couple days to get it right, it still isn't perfect and there is slightly misaligned seems occasionally but it was workable for what I needed it for. But this wasn't out of the box, I had to add the code for this.

 

vesuvias,
thanks for your last answer!

So folks im playing aorund with materials and I see that you can specify a type of material for the voxel. What I am wanting is to setup a biome type situation... If the surface has a mild angle aka relitivly flat it will be grass... That is if it is exposed..
So would I be checking if the iso surface of the current voxel is close to the isosurface cutoff?

Im guessing for snowy type biomes I could just check worldspace corrdinates and only do that material at higher y coordiantes...

 

another question. I have been messing about with the noise to generate land.. However I end up with the same permutaion of noise each time... thus resulting with the same crazy but cool shape each time i generate voxels.

I would like to have a new noise seed each time so that when I generate off the perlin noise it looks different each time. Anyone have a method to change up the noise permutaiton that is provided? Sorry if this is basic. Just learning here.

 

If your using VFPerlinNoise or VFSimplexNoise then there is no way (without modifying those classes) to reseed. To create a seed function for those noise classes you need to generate an array of 256 ints. Those ints need to be 0-255 in value, and should never be repeated. So create a list<int>, put 0 to 255 in order into the list, then randomize the the list order, get the array from the list and set p to that array, and call Initialize. Basically that will reseed the Noise function. You'll understand more when you look at those classes.

 

thank you again. Makes sense.

 

hello guys,how to dig a different hole with different digging tools use VoxelForm.

 

Finding amazing creations like this, is true inspiration. Wowzas. Keeping my eye on this

 

How long until this will be released?

 

@yahodahan - Thanks!

@wsworin - I was able to make quite a bit of progress earlier this year and was hoping to get things into a releasable state a couple months ago. Unfortunately as much as I enjoy working on this project, it may be awhile (perhaps Q3 or Q4) before I'll be able to cobble enough spare time together to make another release.

@all - Just noticed that Winterkewl and The Yogscast are using Voxelform to create a sandbox game and appear to be well on their way to making a quarter million dollars through a Kickstarter campaign. Just to be clear, I'm not associated with the project in any way, but would like to wish them the very best. From what I can tell, they have some beautiful concept art and some cools models thrown into a very basic Voxelform demo. They clearly have some amazing artists, but from an indie coding perspective, it seems like a pretty decent demo of what you could do in a week with Unity and some off the shelf components from the Asset Store.

http://www.kickstarter.com/projects/winterkewlgames/yogventures

http://forum.unity3d.com/threads/131317-Yogventures!-An-open-world-sandbox-game-being-built-in-Unity3D!/page2

 

Hi Mark I hope I'm not repeating something here...have you seen this?

 

This seems interesting, but what if we want to flatten a piece of terrain to put buildings on it?

 

Hi Mark,

Brilliant work mate, just brilliant.

To bring my development into its next stages im really banking in your next release (infinite terrain) Is there a chance that those that have purchased (like myself) your product could get access to the latest betas even if it is sans heavy support?

Again, great job.

Cheers
Benjamin Swinbanks

Generalist Technical Director
Fuel VFX Sydney

 

Hi mark,

I have the same thoughts as benswinbanks. I would love to have access to the beta version. I am not looking for support either as I am using this as a learning experience while making it a core part of my game idea. I also have no intrest in the editor.

 

@Mark
I saw that the Yogscast were creating that game and I was thinking they were using Voxelform. The terrain seemed way to much like Voxelform's terrain and with a newer video trailer of the game, they were showing terrain removal and adding similar to what is in the Voxelform examples. I'm glad they chose Unity and Voxelform!

 

Hey all,

I am working on my terrain engine using unity. As of now sometimes the rebuilding of chunks takes a while... which gives me a spinner on my mac. Is there a method in unity to throw up a progress bar and now have the application hog all the system resources to do this action of rebuilding chunks? I know that Unity isnt thread safe so....

Ideas?

 

Even if unity isn't threadsafe, you can still use multiple threads to build new chunks (calculate Vertices, normals, indices,...), as long as you don't access unity directly (creating a new GameObject or using the Mesh class, for instance, won't work from a seperate Thread)
It's similar like working with a GUI Framework like WPF, you can't access the GUI from a seperate Thread either.

If you just want to run a longer task over several frames, you could use a Coroutine, which runs on the main thread and has full access to unity.( See http://unity3d.com/support/documentation/ScriptReference/index.Coroutines_26_Yield )

Just experiment with multiple threads and coroutines to see how you could use them in your solution. You will most likely ending up with using a clever combination of both.

 

After buying this lovely asset some months back I finally had a chance to play around with it in a bit more depth.

I became interested in what I could sacrifice in order to get a notable performance boost. Started off by getting rid of the colliders and ray casting, pretty much eliminating the continual cpu consumption by the physics side of Unity.

But then during the progress of commenting out various things I discovered that I get a really huge leap in performance if I disable the line 199 in VFVoxelChunk which runs the CheckVisibility so often.

Obviously there are implications to this and in a variety of scenarios some compromise will be required (such as running such functions less frequently rather than not at all as I have done here), but the difference in performance was so notable that I thought I ought to mention it.

 

thanks Elbows

 

Hi everyone - I have some slightly bad news... I'm reposting this from my website.

Important Notice: Voxelform is being discontinued as of June 30th.
I've thoroughly enjoyed getting to know so many in the Unity Community over the last year. Researching, developing, and sharing Voxelform has been a great experience, but it isn't sustainable, and I don't have the resources to support a larger user base.

I will do my best to support existing users for as long as possible. Please feel free to continue to correspond at the e-mail address below, and I will respond as soon as I can.

I am currently working on a much more advanced product that may be of interest to commercial teams with professional developers, but just don't have the resources to target general use scenarios any longer. I may post more about the work in progress in the future.

Thank you so much for your encouragement and support in making Voxelform possible to this point.

Best Regards,
Mark Davis

 

Sorry to hear it Mark - it's a great product. Perhaps you should consider open sourcing it (if it doesn't overlap too much with your more advanced product) or offer it on the asset store without support just for cheaper price? It's a great bit of kit.

 

Hi Mark,

does this mean we will be/wont be getting access to v3 as it was the sole reason (infinite terrain) that I purchased your system.

If this is not going to happen I would appreciate organising a refund as I will not be using the product otherwise

please respond

Benjamin Swinbanks

 

has anyone at all gotten a response from Mark about V3? I also will not be using voxelform without infinite terrain.

 

apparently Infinite terrain will only be available commercially

 

curious if anybody has tried this in a purely 2d game. currently I'm implementing collision detection at the pixel level, but I would greatly prefer to use marching squares and use unity's built in physics engine.

I have x,y data points that I would like to use to create the marching squares collision polygon but i'm not quite sure how to translate it to the script found here(http://unifycommunity.com/wiki/index...archingSquares).

 

I can't find any information about the required version of unity. The asset store says 3.4 is required.
So my question: Does it run with Unity 3.5?

Thx
TheMipper

 

Hello,

I am using the most current version of Unity and voxelform is working just fine

 

Well, he did say June 30, so I guess the update will arrive at that date? Still, it would be nice to get this verified.

 

I asked mark for the update several times and he said it will only be available at commercial pricing. the last release is the last release there will be no version 3 for us. which is unfortunate since several people have purchased it expecting infinite terrain in the next release but that is the way these things often go.

 

What happens to Voxelform re the Asset Store after June 30, i.e. since I already purchased it, will I be able to continue to download it from my personal Asset Store inventory, e.g 6 months from now? Or do I need to squirrel away a copy? Is there an official Asset Store policy on this sort of situation?

 

For Voxelform, is it possible to now only deform by removing as I've seen in all the demos of it, but also add to the terrain as well?

 

I have a similiar question - how can we edit (add) terrain in the real time? Are there other brushes, than sphere?
What is the precision of editing (minimal amount of terrain that can be edited)?

 

You can add terrain back. There are samples for both sphere and cube "brushes" and you can code your own. I was able to dig/build pyramid-like shapes as well as pillars/spikes and others with minimal effort.

The provided VoxelInteraction sample also allows you to adjust the "power" of the interaction. If you're a programmer, the code is well documented so modifying it isn't too difficult. It also includes some PDF documentation for a high level overview.