PicaVoxel

The Tiny Voxel Toolset for Unity
​

PicaVoxel is an easy-to-use voxel editing toolset that allows you to create and manipulate vertex-colored voxel models directly inside the Unity editor.

It is also a mini game engine that allows you to use the voxel data in your scene at runtime. Generate and explode voxels! Animate your voxel models using simple frame-based animation - just like creating a 2D spritesheet, but in 3D!

You can import voxel models from MagicaVoxel and Qubicle, the two most popular voxel modelling tools.

PicaVoxel includes five sample games to help you get the most from the toolset.

​

PicaVoxel came about during development of my current game Jarheads. One of the most asked questions during development streams is "Will you be releasing the engine?". For a long time, the answer was "Yes, but not until after I'm done with the game!". Then, over the holidays, I started thinking about it and became quite excited by the prospect of making a user-friendly version of the engine. Something that could integrate with Unity and help others make games that are similar in look and feel to Jarheads, Crossy Road and Voxatron.

And so PicaVoxel was born. It's a non-linear voxel toolset - you create individual voxel "volumes" that can be freely positioned and rotated in your scene. It uses solid colors only (non-textured) to give you that 2D-pixelart-but-in-3D feel that tools such as MagicaVoxel and Qubicle embrace. But on top of that, you get the ability to animate your creations by creating more than one animation frame and cycling through them - much like creating a 2D spritesheet.

And to add even more value, there's a set of scripts to help you use the voxel data at runtime. This is aimed more at desktops due to the processor-intensive nature of working with voxels, but with it you can explode, destruct, construct, collide with, and procedurally generate voxels in realtime.

PicaVoxel is available in the asset store now. I hope you enjoy using it as much as I enjoy working on it!

More information, videos and forums at picavoxel.com
Be sure to read the FAQ before purchasing!
View the Version History
Email support@picavoxel.com with any questions or tweet me.

 

1.2 doesn't compile to ios, I think the using UnityEditor code that's inside Chunk is killing it. You need to case it with #if UNITY_EDITOR

 

I just caught this earlier, looks like I'll be re-submitting then!

You're right, simply add a directive around using UnityEditor:

Code (csharp):

1. #if UNITY_EDITOR
2. using UnityEditor;
3. #endif

Edit: have now submitted the fix as v1.2.1. Another week I guess.

 

Another one , 1.2 tears more than 1.1

Looking at that picture, it would be nice to have the self shadowing not as blocky, as a smooth vertex interpolation

 

Oh and another bug, or at least change in how things work. When I drop a volume prefab the object shows up but when I run the game in the editor, all instantiating of volume prefab ends up empty - dropping a prefab in a running scene or instantiating through code.
I know you changed how things are built in 1.2.

 

I believe the "tearing" you're seeing is due to mesh compression. You can change this in the SetMesh() method in Chunk.cs:

Code (csharp):

1. MeshUtility.SetMeshCompression(mf.sharedMesh, ModelImporterMeshCompression.High);

Possible settings are Off,Low,Medium,High. Try a lower setting or turning it off completely. I'll be exposing this in the inspector in 1.3.

Your second issue is because I have stopped the meshes from being rebuilt on awake on suggestion from another user. This has the knock-on effect that, because Unity doesn't serialise meshes that are procedurally generated at edit-time, any volumes added to prefabs will no longer have a mesh unless you manually rebuild the chunks.

I'm looking for a fix for the prefab issue for 1.3, but in the meantime you have three options:
1. Set your prefabbed volumes to Runtime-Only Mesh.
2. In Frame.cs, change the following:

Code (csharp):

1. if (chunks == null && (ParentVolume != null && !ParentVolume.RuntimOnlyMesh))
2.                     CreateChunks();

to:

Code (csharp):

1. if (chunks == null && ParentVolume != null)
2.                     CreateChunks();

3. Manually call CreateChunks() on your volume(s) from your own scripts.

When instantiating from a prefab in your own scripts, call CreateChunks() afterward (unless you use option 2 above).

I posted a little bit on my plans for 1.3 over on the PicaVoxel forums. Top of the list is to implement smooth vertex shading.

Your game's looking great, btw!

 

I added CreateChunk in appropriate places and it works. Thanks.
It does add to the complexity of initializing objects.
Something you may want to consider for 1.3 is a mechanism, that tracks how an object is being created:

1. if instantiated and nothing else, call CreateChunk on start
2. if instantiated then FromCompressedByteArray, wait for deserialization then call UpdateAllChunksNextFrame

something like that, I'm sure there are other cases.

Why the mesh compression? Does it fare better on benchmarks? I'm asking because I've only experienced problems with mobile shaders when the mesh was compressed.

 

I added the mesh compression to help keep the scene filesize down, but didn't realise how much the compression altered both colouring and vertex positioning. I've found that having it on Low is a good compromise. Like I say, I will include it as an Inspector option in 1.3.

 

Here's a game that I made with my jam team during Ludum Dare 32, using PicaVoxel:

 

Really cool asset.

Does it work on Mobile? Iphone 4?

Cheers.

 

It does work on mobile platforms, and some people are doing great things with it on iPad - but I don't officially support mobile platforms yet. The realtime destruction isn't performant enough (yet) for me to recommend it for mobile. I am actively looking at that for the next version.

 

Please keep us updated with the mobile progress.

 

Very fun LD, Gareth, bankers kicked my teeth on day 2.
To Rocki, I use pica on A7-A8 and it runs with minmal hiccups. Just avoid meshcolliders if you're on <5.0 and turn on culled meshing.

 

@Gareth, your gzip library isn't threaded I think.
I'm threading the saving of volumes which calls Frame.ToCompressedByteArray ();
but Frame.ToCompressedByteArray () does a GetComponent to initialize parentVolume. I had to remove it from line 640, maybe you can thread that function yourself or better you initialize parentVolume elsewhere, when the Frame gets created by Volume.

That's the code calling ToCompressByteArray(), I removed line 640 from Frame and nothing is breaking (yet).

Code (CSharp):

1.         public void Save ()
2.         {
3.             if (dirty)
4.                 this.StartCoroutineAsync (SaveThreaded ());
5.         }
6.         IEnumerator SaveThreaded ()
7.         {
8.             byte[] byteArray = volume.GetCurrentFrame ().ToCompressedByteArray ();
9.             yield return Ninja.JumpToUnity;
10.             PlayerPrefsX.SetByteArray (id.ToString () + "/volume", byteArray);
11.             dirty = false;
12.         }

 

Is there a way of generating some sort of terrain with the help of a heightmap with this asset. It has not to be infinite, but some sort of basic terrain generation would be very nice.

 

Hi!

So far I love Picavoxel and it has been to great help! But I feel like something is missing, which is illuminate voxels. It would be great if you could have some voxels on your model that are illuminated and being able to control the strength of each voxel. They don't need to emit light or anything. I looks kinda weird making a torch model with fire that is quite dark so that is why this would be a great feature.

 

Not in picavoxel, you have full access to the voxel generation though so you can make one.

 

What is the performance, What about drall calls?

 

1 mesh every chunk, which size is 16x16x16 voxel, all meshes sharing the same material so possibly batching if pica is set to greedy (decimation).
When you edit voxel at runtime, it's slow on 4.6 due to physX being a dog at mesh collider rebuild. It's ok on 5.x but either way, if you want to change large voxel volumes every frame, forget about it.

 

PicaVoxel 1.4 has been released. Please note that 1.4 drops support for Unity 4, but you can still download 1.3 via the asset store if you haven't moved to Unity 5 yet. As always, please read the FAQ before purchasing!

And now, onto the good stuff:

Marching Cubes Meshing




Emissive and Mosaic shaders




Convert 3D model (mesh) to voxels




Import image as voxels



Face Overlap to eliminate mesh seam artefacts



And a bunch more exciting stuff. See this post on the PicaVoxel forum for the full 1.4.0 changeset.

Email support@picavoxel.com with any questions.

 

Sorry for not answering this sooner (this thread always slips my mind). Essentially, Laurent is correct when it comes to mobile. Updating meshes at runtime in Unity is expensive, even moreso if you have colliders attached. That's why I don't make any guarantees for mobile platforms. The runtime portion of PicaVoxel is mainly aimed at desktop.

Draw calls is an interesting question. Despite using a shared material, the draw calls (batches in U5) always seem high. I'm guessing this is down to the meshes having >900 vert attributes. Again, we're rubbing up against limitations with procedural meshes in Unity.

Your mileage may vary though, which is why I honour refunds within the first two weeks if you find that PicaVoxel doesn't suit your project.

 

I love this toolset very much, and Can you provide a teaching video about the new features like Marching Cubes Meshing and Emissive and Mosaic shaders?

 

Thank you! I do need to do some more tutorial videos, but I'm happy to answer any specific questions here or via email (support@picavoxel.com)

Marching Cubes meshing is simply a third meshing mode you can switch to in the PicaVoxel Volume inspector (Meshing Mode drop-down).

There's a step-by-step guide on the new shaders in the manual (page 18).

 

@GarethIW i can't reach you by email (undelivered exception), i let you a PM.

 

Is the engine compatible with playmaker?

 

Your Jarhead game is awesome. Any chance you sell it as a complete kit asset? ;D

 

I don't use Playmaker, but I don't see why it wouldn't be.

Hehe, thanks - but no

 

How can I destroy voxels, like in your game the tower? I want to shoot on object and it goes bang.

 

and is it possible that destroyed objects, autorepair after a amount of time?

 

I've been considering developing a voxelized rpg and was wondering if you can create an item and then scale it down (basically for better resolution), I'm wanting the flexibility of voxels but better detail. And can each item be scaled seperately? Are the objects created saved as individual files say for importing into multiple projects?

Any performance comparison with say Voxelmax?

Thanks in advance

 

Each PicaVoxel object (we call them Volumes) has its own Voxel Size parameter which sets the size of the individual voxels in units. So yes, you can scale your models as you see fit, and have different sizes for each.

The created objects are not saved as individual files, but you can create prefabs from them.

I would suggest using an external editor such as MagicaVoxel or VoxelShop to create your models, and then import them with PicaVoxel. That way your models are not tied to a particular Unity project. PicaVoxel has full workflow support for .vox and .qb voxel formats.

I'm afraid I don't have any performace comparisons with other assets for you.

 

Hi!

I just updated to PicaVoxel 1.4.7 and every time I try to import a .vox file from MagicaVoxel, I get an error. It just returns an object reference exception and points to this line of code.

Code (CSharp):

1. if (voxelData.Length == 0) return; // failed to read any valid voxel data

Is this a bug or am I somehow doing something stupid?

 

Don't worry - it's not you, it's a bug

I've just submitted a fix to the Asset Store (same version number). In the meantime change line 105 of MagicaVoxelImporter.cs from:

Code (CSharp):

1.  //numFrames = stream.ReadInt32();

to

Code (CSharp):

1. stream.ReadInt32();

Basically uncomment the line and remove the numFrames assignment, so it just does a blank read.

This was all caused by wanting to get rid of the unassigned variable warnings that Unity throws up, trying to keep the asset import clean!

 

Thanks for the quick reply! The fix worked perfectly! Keep up the good work!

 

Hey @GarethIW I updated to 1.4.7 and save/load is no longer ok, what's the new syntax for save/load?
voxels.dataholder.data.LoadFromString(PlayerPrefs.GetString(PPname));

Also the chunk building is super slow, any plan to thread mesh building?

 

There's nothing in PicaVoxel that has the above syntax (dataholder etc) and I have not changed the syntax for loading from a byte array since the very early versions. Did you add your own code to the PicaVoxel classes?

Also, mesh generation in PicaVoxel is threaded. Are you sure you're not looking at another asset?

 

That and meshbuilding in the editor is super slow plus search was in full word mode (sneaky) so I couldn't find threads. This is what happens when reviving year old project with confusing names. So now I spend time before naming my projects, a bit like this


By the way Voxel.Active is a getter. I think I changed it to a variable because when I load I don't want the mesh to be built (it causes a hiccup), could you add something?
I've hacked a thing in the meantime.

Code (CSharp):

1.             set{State = value ? VoxelState.Active : VoxelState.Inactive; }
2.  

 

​

Hello people,
the last couple of weeks I've worked for my current project on a workflow and scripts for rigging a PicaVoxel object using Qubicle, Blender and - no wonder - PicaVoxel. As I thought it would be useful for others as well, I'm hereby releasing it to all PicaVoxel owners. It enables you to combine PicaVoxel objects with Unity avatar setups and so to animate multipart voxel models via Mechanim.

As a bonus, the asset also contains an importer for the new Qubicle Binary Tree format to take automation even further.
I've tried to write the workflow as detailed as possible without being bloated. I've tested as much as possible, but I'm sure there's lots of room for improvement. Out of need for my project, I'll go on to extend this further, so expect more in the future.

If you got any comments, requests, bugs etc. please feel free to contact me via the mail adress you can find in the workflow document. Looking forward to your feedback.

Now go and get the asset here (if you're interested that is):
http://www.outeregions.de/upload/RigIt!WorkflowV1.1.unitypackage

 

1. Is it possible to rig and animate a PicaVoxel model?
2. Does PicaVoxel work with Voxel Importer?

 

You can't rig it directly in Unity because it's not a SkinnedMeshRenderer that Unity uses for these cases, but have a look at my post above yours, I just created a workflow and scripts for exactly that purpose and I'm continously working on extending it for my own project.

 

Thanks!

 

Hey
So I'm not sure if this is a very important part of the asset but it would appear that runtime-only meshes don't work on the Universal Windows Platform. They are just empty. The workaround is, as you would suspect, not to use Runtime-only meshes. But I'm still afraid they might take up a lot of space later on. But it could also just be me being overly paranoid.
Just wanted to let you know.

 

Interesting. Is this at build-time only or does it happen in the editor when you switch to the UWP platform? Also, are you sure it's a UWP issue only (does it work in a desktop build?)

 

(UWP) In the editor: Fine.
UWP built: Invisible.
Standalone Windows: Fine.
So it seems to be something with UWP.

 

Okay, thanks. I imagine it's an issue with the cross-platform zip library. I'll check it out and get back to you.

 

I tried a UWP build running locally and in the x64 emulator. No problems there. So I'm assuming you're getting the issue on an actual device (i.e. running an ARM build)?

edit: Just to preempt this - and because I don't have a physical Windows ARM device to test on - I've put up a version of Frame.cs that skips the zipping/unzipping of voxel data, as I'm pretty sure that's where the fault will lie. Please give it a test to confirm my suspicion - but try it on an empty scene or new project as it will nuke any current voxel data stored in your volumes:

https://gist.github.com/GarethIW/7578b9894237729ca1534f97ddb67ef7

 

So after some further testing on a brand new project, I've discovered that the runtime-only mesh problem occurs on objects you instantiate. If the object is already in the scene, everything is fine.
And I also tried that update Frame script you provided and that just resulted in build errors and it prints out the error message "Couldn't deserialize something" and an Out of range exception starting at line 951 in Frame.cs.

And with the ARM build thing, to be fully honest, I'm not sure about this. I don't have an actual physical device to test ARM on and I'm not sure how I would go about (if I even can) running ARM on my PC. But I did, however, test it with both the x64 and x86 architecture and both of them result in the same way. The instantiated objects don't show up.

 

Ah okay, that's a different issue then. If you're instantiating without a mesh, you will probably have to call Volume.UpdateAllChunks() after instantiating. I would actually recommend not using runtime-only with objects you're instantiating, especially if you're doing it during gameplay.

Use runtime-only on static stuff like scenery that will be present when the scene is activated.

 

Ah, I see. Thanks for the tip! I'll continue to use non-runtime-only meshes for my objects. I still think it was worth bringing up.

 

Hello... again.

I come again to bring up another problem that has "kinda" stopped me from building to UWP.

The problem itself is a shader error that sometimes stops the build and sometimes doesn't. The actual error is:

At first, I thought it was something with Unity, and I can't really say if it is or not, but I still managed to get a response about the issue and how it can be fixed. The workaround/fix and explanation why can be found here.

I just thought I should let you know.