Liquid Voxels

Community Showcases
1

Beta 1

Latest Beta: LiquidVoxels Beta 1.01 (updated with Uniblocks support)
Latest Demo exe: LiquidVoxels Demo1

Due to the delay in the full release, I’ve decided to send out a beta.
The new features in this beta are:

  • Lots of bugfixes.
  • New Inspector for LiquidVoxels object.
  • Regions have been internalised, you can control some aspects but that’s all that’s needed.
  • Pausing/Un-Pausing Simulator
  • Pausing/Un-Pausing Regions (simulator still logs and gathers FPS details but doesn’t tick the data).
  • Support for: Cubiquity, Voxwel, Uniblocks (Experimental), PixelWorld(Experimental),

Experimental = Partially working, may be terrible performance or really really buggy. Wanted to include the interfaces in the hopes that others have a go at making them better too! :slight_smile:
Uniblocks setup can be found in this post.

Also, read the Readme - Install instructions please, it tells you how to install it and what the main classes are.
There’s a video walkthrough on setup here: LiquidVoxels Setup

Where to post ideas and get help.
I’ve created some support forums and a Ideas voting box (similar to Unities) over here:
https://liquidvoxels.userecho.com/

Please use that for posting ideas or for getting help.

Halp! Something is wrong, halp me!
Go to https://liquidvoxels.userecho.com/
Things are going to be broken, a lot. Please tell me so I can fix them.
When telling me something is wrong the following information is incredibly useful:
Unity Version
Plugin Version
Exact Error
How you produced it
What you were expecting.
Will there be cake?

OMG! Why are you ignoring me?! Seriously?!
I’m not, truly I value your input, feedback, bugfixes and conversation. I live in Australia which means I am not going to be around in prime time Europe or America. I will respond and give feedback as often as possible, but please be patient as due to timezones I’m just not going to be around when most of you are. Sorry :frowning:

Liquid Voxels, what is it?

Liquid voxels is a liquid simulator (water to start with) for unity3d. It uses the term “voxels” because it’s initially developed for cubic voxel worlds, but it is being extended to isosurface/smooth style voxel worlds as well.

Why is Liquid Voxels different to other water simulators?
Under the hood, most simulators sample your terrain via ray casting or using the physics collision system in unity. Others aren’t a water simulator at all, they are infact very good shaders on a plane.
Liquid in LV interact with your worlds using a 3 dimensional array, mapping values from the game world into the simulators 3d array. This means that there are no collisions or raytracing occuring; it’s all data interactions that are then visualised via renderer plugins.

Features:

  • Reacts to changes in environment in real time.
  • Falls downwards realistically.
  • Interfaces with voxel engines via custom interfaces, allowing it to be very compatible.

Answers to common questions:
Will source be included: Yes
Price: Will be in the $10 - $20 mark I think.

Media:

Ell

3 Likes
2

Like it :slight_smile: Looks like some fun games could be done with that.

3

I think it looks a bit bad when its still with all the moving but thats my opinion

4

Thanks Spookycat, I hope so! :slight_smile:

I agree and thanks for being candid as all feedback is great. Constructive criticism being the most important!

There’s no threshold code yet, so even minute changes are being shown. Basically what you are seeing there is a surface oscillation (waves) and evaporation interplay. I have a task to add some threshold code to ensure voxels don’t change until a certain amount of “change” is applied. Also a bit of a delay between a voxel reaching evaporation point and the evaporation occurring will also help.

Fluids are a very interesting medium and quite difficult to simulate in a generic enough way to be useful to a wide range of people. We have to balance realism vs your CPU cycles to ensure you have enough to run your own game logic too. I expect i’ll be looking into multi-threading this before too long.

Ell

5

I just set it so block will only evaporate if they’ve spent 3 updates below the evaporation point. This had the unexpected side effect of now showing the surface of the water in more detail. You can see the ripples on the water now (once I write the shader to show partial voxels it’ll look better).

https://www.youtube.com/watch?v=AVsnbWMHQ-8

Bed time, it’s midnight now, but I’ll spend a bit of time quietening down the simulation tomorrow. Might be a good chance to introduce putting inactive blocks to sleep to save on the cycles.

Ell

6

Pretty cool, keep on going, Im hoping there will be a documentation just so we could implement with our own voxels.

7

That does look very cool man I am very impressed. Wish this forum had a ‘subscribe’ feature I will subscribe your channel.

Yay!!! This forum does have a subscribe feature!! Subbed!!!

8

Amusing bug that I’d like to share, I just implemented the first try at multi-threading, the result was rather funny to say the least.

Quite a bit of re-factoring is going to be required to multithread but the simulation time has really improved tremendously so it’s worth the effort.

Ell

9

Wow, this is really one of the coolest things I’ve seen in ages! I’m really honored that you chose to use Cubiquity for this and I’m amazed at how good it looks even at this early stage. I’m sure it could be used for some really awesome games (particularly some puzzle-style ones?).

So on to the questions… I’m naturally curious about how Cubiquity is working out for you and what you might want to see changed? Are you performing the simulation in a separate 3D array or are you somehow encoding the attributes (pressure, etc) into the Cubiquity colors? Is the update speed of the voxels sufficient? I guess it’s the simulation which becomes the bottle neck as the amount of water becomes larger?

It would be really cool to see how it responds to in-game modification. I can imagine that adding voxels is slightly tricky, but deleting them should be ok? Then a player could shoot part of that water tower and see the water come pouring out :slight_smile:

Good luck with the rest of the development and I hope it does well. You might find that the guys in the giant ‘After playing Minecraft…’ thread are also interested in this, especially if it is extensible to other engines.

10

Hi Daivd,

Thanks for the kind words. Cubiquity sold itself to me rather quickly as it’s very straight forward to use and it doesn’t try to be too much more than a voxel engine. I really enjoy the fact that it gives us the building blocks to build our own terrain/environment types instead of dictating one to us.

Yes, the first step was to create my own 3D array object that allowed me to store data in it. Then I created some liquid objects that could be stored in each array node. It can store multiples, so I’m sure some smart bikkie out there is going to have multiple liquids interacting at some point.

Next I created an interface that to allow me to interface with Cubiquity, the interface controls the information mappings between Cubiquity and the liquid simulation. The liquid simulation has an enum of different types of voxels: Liquid, Solid, Air and AlteredFlow, so all I’ve done so far is pick a specific colour to be Water and then the interface creates/deletes water voxels for me.

At this point the bottleneck is the simulation, and Cubiquity is holding up to the pounding very well!
I’ve just finished a video of the latest version of the multi-threaded edition, which is below (it’s running 4 separate instances of Cubiquity there). I’ll create another with some runtime modification for you to see, I might even dig up your explosion script and see if I can blow the side off the tower.

Thanks for the tip about the guys over at the other thread, I’ll drop by there a little later.

  • Ell
11

It went really smoothly! Worked straight out of the box, no modification required!

Second one, this time I managed to show the water actually flowing post explosion. Got a little trigger happy last time!

  • Ell
12

Those explosions are so cool! It’s nice to hear that it ‘just works’ because it shows we’re both doing something right :wink:

I wonder whether it is extensible to other kind of cellular automata effects? For example, maybe it is possible to simulate the spreading of fire in this way, or to have acid which can slowly dissolve through objects? Mixing these with the water could also be fun!

I wonder about your plan to offer a compilation though - do people tend to own/use more than one voxel asset? Maybe you are better off putting different effects (such a those mentioned above) into a compilation.

Anyway, really cool stuff and I’m keeping a close eye on it. Do let me know if there’s anything I can do to help.

13

Those are good ideas. A bit of a detour from the initial idea but something worth considering.
Perhaps instead of:
Liquid Voxels for
I go with
Liquid Voxels
Fire Voxels
Gas Voxels
Exploding Rainbows of Fiery Deathly Unicorns of Destruction Voxels…
as a series, and the compilation is something like Simulated Voxels.

In regards to the support for different engines; depending on how well my integration implementation works I might just make this an ever expanding list of features for each package.

This is all just food for thought, I’ll focus on getting this first simulation out and then ponder the possible futures.

  • Ell
14

+1 for Exploding Rainbows of Fiery Deathly Unicorns of Destruction Voxels…

15

Hehe, I thought someone might like that.

Ok, so the multi-threading is going quite well and the simulation is quite a lot faster now.
I’m now starting to put in a couple of options, such as being able to take a copy of the underlying voxel engine into a 3d array to allow me to safely access the voxel information in a thread-safe manner. It will be a toggle-able option, as you may not want the CPU/Memory overhead of a duplicate of the voxel details in your game. Also, you may be on the ball enough to integrate the simulation into your voxel engine in a thread-safe manner.

Here’s a video of an issue where I believe I might have a race condition when asking Cubiquity for voxels and I could be doing nasty things to David’s Octree retrieval due to the threads :slight_smile: I’m calling the video “Rusty Containers” as it sprung a leek. Interesting to know that the simulation see’s it’s now a valid place to go and happily flows out of it.

I’ll edit this post in a few hours with some more videos of progress. Mainly similar to things posted earlier, but running faster and less hap-haphazardly.

  • Ell
16

This update deserves it’s own post. I created the ability to throw water at a terrain in the simulation.
The result was really fun. I’ve already spent a heap of time just throwing water at stuff :slight_smile:

The terrain comes as an example terrain with Cubiquity, go check it out! http://forum.unity3d.com/threads/184599-Cubiquity-A-fast-and-powerful-voxel-plugin-for-Unity3D

17

Any idea when it will be released?

18

Seriously cool stuff - looks like it’s scaling up to larger volumes quite nicely :slight_smile:

I think it would be nice if Cubiquity let you get/set part of the volume data by using an array. At the moment you can only access the volume data through GetVoxel() and SetVoxel() which each work on a single voxel at a time, and each call to these has to go through the P/Invoke layer and has some extra overhead. It might be nice to have version where you can pass an array of voxels to Cubiquity along with a Region identifying where they should go, and Cubiquity would do the copying for you in C++. This should be faster.

In fact I’ve just logged that as an issue: https://bitbucket.org/volumesoffun/cubiquity-for-unity3d/issue/53/allow-getting-setting-of-an-array-of

Could well be, in general you can’t read/write voxels from multiple threads at the moment. Again this is something I’d like to fix in the future.

19

Hi Ghoetam, I’m hoping to have a beta release by the end of May for people to play with, and a final release probably 2 months after that, as I want to ensure I have good documentation to go with this product. Voxel engines that I haven’t written the integration for will need a little work so I’m keen to make that as straight forward as possible.

A GET function using your Region object would would also be super useful. I could then easily even pre-get all the voxels I need before firing off the thread component, and then there’s no threaded calls at all to cubiquity. For now I’ll be running a pre-threading loop to get the current state of Cubiquity to pass into the threads to save the engine a little.

As for Set, that’s not a bad idea either. I save all the voxel sets for outside of the threads; I knew I was pushing my luck doing threaded gets, let alone setting as well :slight_smile:

Cubiquity is performing quite well, the biggest bottleneck is the GETs within threads, which I’m going to stop because that’s a cruel thing to do to any engine. The SET’s on the other hand is doing really well. In the last demo , it’s averaging around 900-1200 voxels on screen, and the code that fires off all the SET’s is returning in 0.02 ms on average. No complaints here.

I probably won’t be doing it this way for much longer. Apart from the performance concerns of 1000’s of gets per simulation update, it also means I could only interface with threadsafe voxel engines. I’d rather be a little more compatible than that.

Also, I hope you don’t mind but I ripped that flying cube and the torque spin from your destruction code. It looked really good.

  • Ell
20

Greetings everyone.

Today’s update is demonstrating the growing scale that the simulation can work at, and showing off the profiling I’ve put together to allow me to locate the slower parts of the simulation.

This first video is something I’ve wanted to do for a couple of days now but the engine wasn’t fast enough. It is now!
I’ve set-up some source blocks that replenish water supplies and placed them in feeder springs. These springs flow together to form a river and then drop over a cliff to form a waterfall.
The simulation isn’t great at flowing water like a river yet, it works really well for interactions and reacting to things though. Not sure if I can make it do that easily, or if I’ll save that for my next simulation type in the package.

This next video is of one of my benchmark scenes with my profiler running:

Have a fair bit of optimisation to do yet, as I’m still consuming way too many cycles to simulate the water.
Next major step will be looking for a couple of other voxel engines to try out. It integrates really smoothly with Cubiquity, but I expect it may throw a few bugs around once I try other simulators.

I’ll put out a request for volunteer voxel engines in the next week.

  • Ell