Liquid Voxels

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!
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

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

 

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

 

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

 

Thanks Spookycat, I hope so!

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

 

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).

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

 

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

 

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!!!!!

 

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

 

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

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.

 

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

 

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

 

Those explosions are so cool! It's nice to hear that it 'just works' because it shows we're both doing something right ;-)

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.

 

Those are good ideas. A bit of a detour from the initial idea but something worth considering.
Perhaps instead of:
Liquid Voxels for <voxel engine here>
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

 

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

 

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 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

 

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

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

 

Any idea when it will be released?

 

Seriously cool stuff - looks like it's scaling up to larger volumes quite nicely

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/...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.

 

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

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

 

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

 

Looking good

 

Wow, that's really really cool.

 

Thanks very much for the nice comments.

Things are going quite smoothly now, so I'm still on track for a public beta by the end of the month.
Going to update the front page to look a little nicer, link to more recent screens etc.

Next up, I'll begin work on integrating into the non-cubic version of Cubiquity, as that's going to look very nice

 

Wow, you've really made some great performance improvements here - that profiler example is really running smoothly and it's nice to see the system scales up to larger volumes as well. Really good progress!

No problem, you're doing great things for Cubiquity

How are you planning to handle the rendering here? I can imagine it will be more challenging than in the cubic case.

p.s. I got you're PM and will take a look soon.

 

Cheers David!

I'm thinking I'll need to extend my IVoxelComm interface to support passing in and out the mass of the liquid voxel in my engine.
I'll also need to update the metadata to hold a MassModifer value, and then when the simulator requests MaxMass via a getter it wil first multiplied the mass with the modifier. A couple of tweaks and we should be good to go, i'll prototype it tomorrow.

For example, say a voxel in your smooth terrain has 200 Stone, and 20 Mineral, that leaves 35 units for water. I'd need to return 13 (percent) as the modifier to the simulation, that would let the simulation know that it can only ever put 13 percent of a liquid voxel's mass into that space.

By doing that, I'll then be able to make a "water" material and add it to the terrain's list of materials. Water will then become part of the landscape. Might need a super sexy shader to make it look decent, and we won't be able to enter it, but those would be implementation limitations. The alternative would be to run up a second terrain just for rendering the water, and remove it's collider so players can walk through the water.

Just a couple of thoughts; I haven't started it yet.

 

Status Update​

For those that didn't notice, there's now a playable demo out now, linked also on the front page.
Check it out for some water throwing fun! Click to throw water, Shift Click to throw it further.


[TABLE="class: outer_border, width: 700, align: center"]
[TR]
[TD]Item[/TD]
[TD]Old State[/TD]
[TD]New State[/TD]
[TD]Comment[/TD]
[/TR]
[TR]
[TD]Implement threading using own custom solution, I'm sure LOOM shouldn't come with my asset! [/TD]
[TD="align: center"]:-([/TD]
[TD="align: center"]:-|[/TD]
[TD]First cut is in and from what I can see with my profiler, it allocates threads as efficiently, but takes longer to do it. Have a bit of work still to do here. Michiel really knew what he was doing when he created LOOM![/TD]
[/TR]
[TR]
[TD]Implement pre-fetching of volumes (removes need for thread-safe voxel engines)[/TD]
[TD="align: center"]:-|[/TD]
[TD="align: center"][/TD]
[TD]Done, could do more but it's a minor task now, I'll track it separately.[/TD]
[/TR]
[/TABLE]

- Ell

 

Hi all of you avid readers out there, I know you are there lurking on the forums. I can't see you, but like Darth Vader said, "I felt your presence" (at this point, my wife interject and ask who gave me my Internet license, and why they haven't taken it away for having humour like mine).
This post is basically a call for people to give me their opinion.

It's time to start the search for two other voxel engines.​

Whilst Cubiquity is the engine I will be releasing beta with full support for, it is really important that I test integration with others before releasing the final product. I really don't want to get it out in the wild only to find I've made some unseen fundamental error that brings the whole project crashing down around me and basically ends the world for all of humanity as we know it.

So, what I would like from you all is to begin suggesting voxel engines that preferably comply to as many of the below criteria as possible. I'll take the top 6-7 responses and release a poll thread to allow people to vote for them over the period of 1 week. At the end of the week I'll announce the two winners (the top two in the poll) and begin work on integration.
I'm hoping that this means in 2 weeks time I will have 2 engines to begin my integration work with and release beta with at least some preliminary integrations.

Criteria for engines:

• Completed: Works in progress will potentially have me chasing bugs instead of integrating.
• No existing fluid simulation: engines with a running simulation are probably not in need of another.
• Currently Supported: I need to be able to ask questions/interact with the developers if there's issues. This simulation really pushes voxel engines update methods.
• Sub $100: if the two winning engines both need to be purchased then I will do it, but I o have limited funds at my disposal to purchase assets.
• Available to the public: private engines for game development is what the Beta/Released asset is for, I won't be integrating with private engines in general. Feel free to write the integration though, if you can write a voxel engine then integrating this simulator into it will be easy.

That's it, If you suggest engines that meet a subset of the criteria and the reasons given are reasonable then I will probably add it to the poll.

Suggest away! Poll starts on the evening of Monday 12th ACST time (aust central standard time) and finishes on the following Monday, hope to see a lot of suggested engines here!

- Ell

 

I think both of these approaches have potential and I'm not sure which is best. Working with the multiple materials might be a little complex and I'm not really sure how it would look, so I guess my gut instinct is to try using the second volume. This will also probably let you do transparent water if you set an appropriate material too. However, you also need to keep other engines in mind and I don't think any of the others actually support multiple volumes.

I've never actually used any of the other voxel engines from Unity but naturally I keep quite a close eye on what it available. I guess you've searched on the asset store, but the main options are:

• Voxwell (Cubic style)
• Uniblocks (Cubic style)
• TerraVol (Smooth)
• Ruaumoko (Smooth)
• Voxeland (Smooth)

I guess you will want to start with the cubic style ones first because they will fit more closely with the work you have already done.

The Voxwell guy is pretty helpful and was giving away free copies for LudumDare (and before that he even gave me a copy). But I think his tool is more for prototyping levels and so I'm not sure if it can modify hundreds of voxels per frame. Of course you can talk to him about it. As for the others you should at least ask for a demo to make sure they meet your needs (e.g. whether they give you direct access to the voxel data or whether they just generate terrain based on noise functions, etc, and also you'll need to see how fast they are). Needless to say I'll be very curious how they compare to Cubiquity!

 

I agree that the second approach for cubiquity is a good way to go. I can do all of that within the integration point with cubiquity and not make any changes to the core engine at all. So basically it would just be the way the simulation works in cubiquity; we may need to do similar types of configuration for each engine. Might even be an option to run a cubiquity engine for simulating water within someone elses voxel world!

That's a good list (very similar to the one I came up with privately in case people don't respond, although I missed UniBlocks in mine). I was hoping that people would all recommend their fav engines, giving me an instant short-list. I really have very little clue as to how many people buy voxel engines at all.

All very good points, I'll send out a few pm's emails next week and see what comes back.

I'm taking a night off tonight on progress, spending a bit of wife and kids time. Picking back up again tomorrow, hopefully to tackle some of the inefficiency that crept in when I rolled my own threading machine.

Thanks for your insights David, always good to hear from you!

- Ell

 

I would love to see you getting this on TerraVol

 

Hi Mathias,

I was just looking at the TerraVol terrains and it looks quite nice. I do notice that a limitation of version 2 is there can only be one terrain object, which might make a water implementation difficult (using terravol itself for rendering). I might start messing with a smooth volume simulator in Cubiquity and see what it looks like as a renderer in other engines (as it allows multiple terrains).

I also haven't addressed how to handle unlimited terrains, that would be a challenge there too. Seems like an good engine if I want some interesting challenges!

Ell

 

A brief interlude to lolz at an amusing bug that I noticed when I got home from work today.

I'm thinking that writing thread locking code late at night is perhaps not the best of ideas. If you ever decide to thread your app then do yourself a favour and purchase LOOM; at least all you have to worry about is the thread-safety of your shared objects. Let LOOM do the heavy lifting of managing threads

I'm not associated with LOOM at all, I just like making sure good assets get the publicity they deserve.

P.S. Whatever the bug, I really hope that my profiler isn't lying and the entire simulation step is really taking 100 - 150ms for 4000+ liquid voxels. I highly doubt it's real though; one can always dream
- Ell

 

Hi All,

Quick update. Work is going to raise it's ugly head the week after next, causing me to have to fly overseas for a week.
That means I either delay beta release for a week or remove a week's worth of effort from the plan.
After a bit of thought, I've decided to remove a weeks worth of effort and still release beta at the end of May.

The easiest win here is to remove the smooth voxel support and focus on a nice cubic release; then go back and add smooth after beta . So that's what I'll do; I'll update the front page as well.

Just to re-assure you, the project is still moving along quite well and I'll keep posting progress videos for you all to see.

- Ell

 

Today's update is rather big (for me anyways).
I managed to tune the simulation to give us approx 5 times faster performance than my first benchmarks (around 3 times faster than my last few videos!).
Very happy with the result. Also finished my own threading implementation, and boy that was one steep learning curve!



[TABLE="class: outer_border, width: 700, align: center"]
[TR]
[TD]Item[/TD]
[TD]Old State[/TD]
[TD]New State[/TD]
[TD]Comment[/TD]
[/TR]
[TR]
[TD]Implement threading using own custom solution, I'm sure LOOM shouldn't come with my asset! [/TD]
[TD="align: center"]:-|[/TD]
[TD="align: center"][/TD]
[TD]Complete[/TD]
[/TR]
[TR]
[TD]Attempt to get sub 16ms for 625 voxel updates (0.0128 ms per voxel, currently 0.5 now).[/TD]
[TD="align: center"]:-|[/TD]
[TD="align: center"][/TD]
[TD]Complete[/TD]
[/TR]
[TR]
[TD] Upwards Pressure [/TD]
[TD="align: center"]:neutral:[/TD]
[TD="align: center"][/TD]
[TD]Complete[/TD]
[/TR]
[TR]
[TD]Add support for smooth (isosurface/marching cubes) engines. Removed from beta: See here for reason[/TD]
[TD="align: center"]:sad:[/TD]
[TD="align: center"][/TD]
[TD]On Hold[/TD]
[/TR]
[/TABLE]


Videos for today:

RAIN! My wife had the idea during one of my (many) demo's to her, and it turned out all the tools were already there to make it work so I put it in.

[video=youtube_share;5X94q5GUJpU]http://youtu.be/5X94q5GUJpU

A few demo's of the new frame-rates available.

[video=youtube_share;WWq9ehbsuAs]http://youtu.be/WWq9ehbsuAs
[video=youtube_share;YMfwOe3fhYA]http://youtu.be/YMfwOe3fhYA

Hope you liked the update.

- Ell

 

Looking good as always, and it's nice to hear you are still getting performance improvements. Actually I notice in your first video that you have a Volume Collider component on your volume - does it go any faster if you remove that? I believe that updating colliders is one of the slower aspect of Cubiquity, though perhaps it's still faster than the actual simulation.

I think that's a smart move - aim to get something released as soon as possible so you can start getting feedback. I'm still haunted by this comment where I predicted Cubiquity would be on the asset store last July/August... so we're about nine months late! Such is the world of software development ;-)

By the way, it seems another cubic voxel engine called 'Voxity' got added to the asset store last week: https://www.assetstore.unity3d.com/#/content/17470

 

Thanks David, yes the collider made a huge difference!
The first demo was with 10 new water droplets of rain per second; this one is 100. It manages to hold around 30 fps (simulator time), but I just noticed rendering drops it to around 8-10. Might look at running up a second voxel simulation for water, or look into a dedicated mesh renderer. Don't you love the smell of fresh scope creep in the morning

- Ell

 

Afternoon All,

In addition to the updates below, I had a private request to try the simulation in someone's engine.
I thought I'd give it a shot. I wasn't expecting big things because my simulation is alpha and so was the voxel engine but it highlighted a couple of things that do need to be looked at:
1. Focus on chunks/regions and the flowing of water between them. This engine was made up of a lot of chunks and I ran 1 simulation per chunck. I haven't handled flowing of water between simulations yet.
2. The water simulation is very taxing to voxel engines, making the edges of the water a little quieter is perhaps worthwhile.

On the bright side, it didn't take very long to integrate at all, and once I'd made some of the core changes (I had been directly accessing cubiquity when I shouldn't have been), the only effort was to create 2 interfaces! Very happy with the design. I hope you will be too.

I'm not going to count this as an additional voxel engine integration, as I really wanted the integration work to be public and useful to people; so the vote next week is still on.

Ok, on with today's progress:



[TABLE="class: cms_table_outer_border, width: 700, align: center"]
[TR]
[TD]Item[/TD]
[TD]Old State[/TD]
[TD]New State[/TD]
[TD]Comment[/TD]
[/TR]
[TR]
[TD]Runtime handling of solid block being placed within existing water.[/TD]
[TD="align: center"]:sad:[/TD]
[TD="align: center"]:smile:[/TD]
[TD]Complete[/TD]
[/TR]
[TR]
[TD]Runtime subtraction of new liquid[/TD]
[TD="align: center"]:sad:[/TD]
[TD="align: center"]:smile:[/TD]
[TD]Complete[/TD]
[/TR]
[TR]
[TD]Expose AddLiquid Method to consumers[/TD]
[TD="align: center"]:neutral:[/TD]
[TD="align: center"]:smile:[/TD]
[TD]Complete[/TD]
[/TR]
[TR]
[TD]Investigate how to suggest to implementers on how to set-up 1 simulation per chunk/region and handle inter-region water flow.[/TD]
[TD="align: center"]:sad:[/TD]
[TD="align: center"]:neutral:[/TD]
[TD]Had a first shot at this, it went fairly well. Got some changes to make![/TD]
[/TR]
[/TABLE]

Thanks for those sending encouraging PM's, it's really appreciated.

Follow me on Twitter, I've been posting updates and cool info as I go, would love to hear from you!

- Ell

 

Was just reading more on Voxeland today and came across this: http://forum.unity3d.com/threads/187741-Voxeland-Voxel-Terrain-Tool/page3

It sounds like Voxeland is 'cubic' based with smoothing and not marched, so the cellular automata calculations might be more easily adapted -- but you might be forced into calculating occlusion mapping if just working off of their 'pipeline.'

I think if you wanted to make a multi-engine-compatible liquid, you should approach it two ways:

- cubic style
- density style

For density style, you would have to extend into a GetFloorFromLoc(X,Y,Z) feature of the terrain engine to find the fluid floor, and then you would build a new density of fluid values that is marched separately by the fluid engine according to those boundaries. The fluid engine would have its own chunk size/alignment setting.

My current water implementation is basically like this and works fairly quickly and can flow water between neighbors appropriately. The movement of density generates a waving effect, but generally the water mesh itself is static other than trying to move down and averaging from left/back. I update the water mesh every Nth advection frame and if the water sees greater than N changes, I mark the fluid as dirty for a re-march in a separate FluidMC implementation, use that as the collider and then perform a quick smooth for the rendered mesh. If the water is out-of-frame, I advect (forward, one pass into a temporary buffer) but do not update the mesh (ignore the dirty value until it comes back in frame). When I run through the temporary buffer to apply the advection results, I track the differences and make decisions on sculpting/carving the terrain based on a fluid flow/volume threshold.

Then I use a water/ocean/wave shader to visualize flow (averaged per chunk) in specific directions, bump mapping, wave displacement, shoreline effects for a real-time look/feel.

But my goals may be different .. I was after something that would let me cover the entire terrain (goal of 32x16x32 active (but not necessarily visible) chunks in the world of 16x16x16 blocks each) with water and have it pool down into natural rivers/lakes very quickly and run normally during play with LOD features like scaling the rendering frame rate. My focus for the moment has turned back to representing the underlying terrain at that scale instead, and optimizing access (KD-tree/octree/RLE?) to 67 million voxels in 16? 32? LODs .. 32 would give a working set of 2 million 'approximated' voxels at full distance would should be workable if I can compress memory and manage GC/pools appropriately.

 

Hi Jason,

Tried to respond to you this morning on the phone but it kept ringing!

Your thoughts on cubic/density is exactly the plan. Ideally I'd like to also base my simulators on different methods as well, such as "Cubic Vector Flow" and "Cubic Automata" etc. I'm really being very strict on myself here with scope creep for this initial release though, that way I get it into people's hands early and they can shape the direction.

I really appreciate your description of your simulation, it really helps to chat and bounce ideas off people. I've found the topic of fluid simulation to produce such wildly different approaches and solutions, it's super interesting. Yours sounds quite optimised and has some really good rendering delays in there, I'm impressed. Mine does have minimum thresholds that must be met before it will send things off to be rendered, and I do have a dirty block setting to ensure i'm only working on blocks that really need it; but that's about it for optimisations at the design level at the moment. Most of the optimisations so far are in early terminate logic (drop out as soon as just enough work as been done on a single voxel) and ensuring the objects I use are as light weight as possible.

Your out of frame rendering stuff sounds really good. It's a little more elegant than my first run now where I bind the simulation to chunks, and recommend that when people unload (or just FoV the chunk away) they also stop calling updates to the simulator for those chunks. I think once I do add a smooth (density) simulator, i'm also going to have to write my own mesh renderer, at which point a lot of what you've said is absolutely going to be possible.

How are you storing your water data, is it within your terrain engine or are you using a separate data structure?

- Ell

 

I have nothing else to add than this looks super cool! Great Job

 

lol! Thanks! dude, all encouragement is welcome too
It's what keeps this project going, as it's certainly not the prospects of being a cash cow like NGUI or something like that is. Fully aware of how niche this one is. hehe.

- Ell

 

Hi Ellandar!

Really cool stuff you're doing. I got your email and replied back with a copy of Voxwell and some explanation. Really interested to see what you can do with it!

Thanks David! You are too kind!

Voxwell is definitely less about generating large terrains - you are already doing an excellent job of that with Cubiquity!

It is much more about hand building levels and props very very quickly. With that in mind, it's architecture might be a little different from other voxel engines.

It's still ultimately just arrays of 'voxeltypes' though - and you do have direct access to those arrays, so it should be possible to do pretty much whatever you want with that.

In theory, changing a voxel at some position is just setting an integer in one of these arrays, and telling the voxel structure/chunk to redraw. You can call SetVoxel(position, voxelType) as many times as you want in a frame, and then only redrawing the affected structures. A 16x16x16 voxel structure takes anywhere from 10ms to 100ms depending on how many exposed faces there are.

In any case, I'm really excited to see what you can do with it. Please don't hesitate to reach out with any questions or comments.

I'm don't want to hijack this thread, so if anyone is reading this and wants to know more about Voxwell, you can contact me on Twitter @DarkMeatGames or check it out on the asset store: https://www.assetstore.unity3d.com/en/#!/content/14989

 

Great, so Cubiquity is now the bottleneck I'll get to work on a faster version!

 

Thanks for the copy of Voxwell, It's been a 12+ hour day at work today so far so it'll be late tonight or tomorrow before I get home to open up Voxwell and see what I've gotten myself in to
It sounds like with a little effort this will work, I'll just have to make sure we are a little careful with the updates. There are probably some neat implementations here around the different voxelTypes that we could use (different shapes, or colored water etc).

I'll give it a good go, there's no harm in trying!

Hehe David. I'm still quite impressed at how well Cubiquity holds up under that many updates!

I've nearly finished with the restructure of LiquidVoxels to allow setup of the simulation wholly in the inspector; once complete I'll look at an implementation of the simulator that runs up a second cubiquity volume just for the water updates. I'm keen to see what happens when the mesh updates are just the water mesh and doesn't deal with the large terrain mesh. Plus then I can write some cool water shaders eventually (perhaps even use shaderforge if I can work out how to make it work with no uv's).

I also have a memory leak problem I need to track down, I don't think it's in cubiquity but I don't have a good enough profiler to know for sure. In fact I'm almost certain it's in my code somewhere; please don't go digging for something that probably isn't there! I wish unity provided their profiler as a separate purchasable item in the asset store. I'd put a couple of hundred down for it no problems!

- Ell

 

PM sent with my recommendation. Thanks for tackling the water aspect of Voxels...

 

Hi Vic,

thanks for your recommendation. I will absolutely be looking at TerraVol once I start working on my smooth terrain solution.
There are a couple of challenges when it comes to smooth terrains, as it's not as easy as cubic terrains to determine where the surface is (even when there's density in a voxel, there's even a chance it's just the tip of an overhang, so a few edge cases to deal with).

The initial plan is to get this first cut of the cubic simulator out there; and then i'll add the smooth terrain simulator to the mix. If the cubic goes fairly smoothly then I expect to begin work on the density/smooth engine early to mid June. They tend to come together quite quickly, it's the polish that takes the time.

Terravol is certainly a good candidate, it seems to be quite a solid engine, thanks again for your recommendation.

- Ell

 

Ok, I'm back again.

With the kids tennis and a 2 hour visit to the show(carnival in US speak I think), I was worried I wouldn't get some quality programming time in. Don't you hate it when quality family time > quality programming time, I have some wife faction to work on I think!

Anyways, managed to squeeze in an hour of programming and was very pleased at how quickly the integration with voxwell occured! Voxwell has some good public methods which made this entire process a walk in the park. I already see some good optimisations that can occur to make LiquidVoxels faster in Voxwell too!

Two videos:

Added some music this time to help things flow better. I love puns, I fully expect them to cost me followers

Thanks again for the copy of Voxwell to try this out!

- Ell

 

Today's update:



Edit: Sorry had to remove, new forums killed my updates and google cache (for a screenshot) couldn't save me either


No new videos apart from the ones posted above. Things are coming along OK, had a bit of a brutal week at work so things slowed down a little in Liquid Voxels. It'll pick up again this week, and then drop to 0 the week after whilst I'm out of the country.

Never fear, we still look on track for end of May Beta release!

Status of the vote
I received quite a few requests for the same engines over and over again, coupled with the fact that I had to remove the smooth surface simulator from the short term plan; I'm going to just list the engines below that I'd like to have support for on Beta Release.

Cubiquity: Of course! Go try it!
Voxwell: Not quite a terrain world engine, but a nice water feature in a prototype would never go astray!
Uniblocks: I haven't contacted the author for a copy to try integrating with yet, so this is tentative.

As for future plans of integration (for smooth terrains), it's looking like this would be the order of implementation:
Cubiquity: Supporting the voxel engine that got me started on this.
Terravol: Requested a lot.
Voxeland: Second most requested.
Ruaumoko: Third most requested.

This is just a rough order of implementation; I've yet to come up with detailed plan on my implementation to smooth terrains. I may end up building my own Meta Balls/Density system and render it myself using marching cubes; then it would probably integrate with almost any system.
Also, I haven't contacted any of the authors yet, so I may not get copies of the engines either.

That's me for today's update.

- Ell

 

I made a couple of modifications to the way LiquidVoxels asks Voxwell to update it's mesh and now we can run 4x as many voxel updates as before. Looking good!

Time to start bedding down the classes, writing a little doco, getting serialisation sorted and look at sending it out to the masses

Getting close now.

- Ell

 

Instead of being a good person and re-factoring/optimising and cleaning up ready for release, I decided to investigate how to create meshes and use marching cubes algorithms.

It didn't take long to stumble upon THIS which seemed to be a great starting point.
So instead of a nice list of completed items for today, I have to confess no core progress on the list but I hope the sexy smooth voxel demos below will calm the angry mob

After seeing the results in a smoother world, it has highlighted that I probably need to at least double the resolution of the water simulation for smooth worlds to ensure droplets and separate water streams get shown nicely.

Enjoy! (yes, I really should add music to my videos, sorry!).

Sorry about the end of this one, my memory leak (which I made worse not reusing the mesh every update...) stomped all over me at the end in the form of a Out of Memory error. The sysadmin in me just wants to throw more RAM at it!

- Ell