2D Liquid Simulation Engine

I'm wondering if this 2D fluid simulation engine could be ported or replicated for Construct:

I believe it is open source, but I'm not sure if it could actually be put into Construct as I'm not a programmer. It looks like it could run pretty fast, but I haven't tried the demo myself. Apparently the engine has already been ported to C++, Unity, and other things.

I know I mentioned already in chat, but for the sake of the topic making sense: it can already be done using physics and quaziblobs, which if I can remember correctly works something like this:

http://www.amirai.net/forums/liquidexample.zip

Yes, I've done it also a while ago, with physics and a special blob shader:

http://www.scirra.com/forum/viewtopic.php?f=8&t=7037&p=55148#p55148

It isn't very complicated.

I posted a somewhat long reply after Arima posted, but I get signed out of the forums a lot (something with my internet) so it didn't post.

Summary: I'm looking for a faster way to do it than physics + shaders like with quaziblobs. I know it isn't complicated to do with blobs, but performance is my main concern. I'm also wondering if there's a way to do it with blobs that's faster than some of the examples I've seen. For example, with the demo of that fluid engine, if I set it to render points rather than metaballs (which I think may be slowing down on my IGP), it runs at over 120fps with 500 particles.

Tulamide, your example looks pretty cool. I can't seem to find what the fps is after the simulation actually starts but it shows fps at 60 first when it measures and the max particles is 380.

On my machine with my example with 500 sprites, deactivating the colourise shader only gets 1 extra fps per sec at unlimited (69 to 70). Reducing the simulation steps on the physics from 10 to 1 boosts it quite a bit more to about 135.

AFAIK there isn't any other solution to having piled objects like what you're looking for that will be any faster.

I'm looking for a faster way to do it than physics + shaders like with quaziblobs. I know it isn't complicated to do with blobs, but performance is my main concern. I'm also wondering if there's a way to do it with blobs that's faster than some of the examples I've seen. For example, with the demo of that fluid engine, if I set it to render points rather than metaballs (which I think may be slowing down on my IGP), it runs at over 120fps with 500 particles.

You could try and apply the metaball effect to rojo's example.

http://www.scirra.com/forum/viewtopic.php?f=2&t=8050&hilit=water+minecraft

After that there's Lucids fluid dynamics plug, although I doubt it would behave much faster with sprites.

I guess it could be adapted to use a distortmap.

Tulamide, your example looks pretty cool. I can't seem to find what the fps is after the simulation actually starts but it shows fps at 60 first when it measures and the max particles is 380.

It runs at v-synced rate the whole time. As soon as the frame rate (that was measured at the beginning) drops, the spawning of sprites is stopped until the frame rate is up again (normally just a few ticks) The physics use 10 simulation steps and there are some calculatons that are done in an "for each" loop on every spawned sprite on every tick (for testing purposes). I'd say, with less calculations and lower simulation steps you could reach 600-1000 sprites. But the physics object seems to have problems with too many sprites that use custom collisions. I ran into serious issues with a collision shape using more than 5 points when having more than ~500 sprites on screen.

I could send you the cap and the blob shader (that isn't very gpu heavy, it works on a layer not on every sprite) if you are interested.

> Tulamide, your example looks pretty cool. I can't seem to find what the fps is after the simulation actually starts but it shows fps at 60 first when it measures and the max particles is 380.

>

It runs at v-synced rate the whole time. As soon as the frame rate (that was measured at the beginning) drops, the spawning of sprites is stopped until the frame rate is up again (normally just a few ticks) The physics use 10 simulation steps and there are some calculatons that are done in an "for each" loop on every spawned sprite on every tick (for testing purposes). I'd say, with less calculations and lower simulation steps you could reach 600-1000 sprites. But the physics object seems to have problems with too many sprites that use custom collisions. I ran into serious issues with a collision shape using more than 5 points when having more than ~500 sprites on screen.

I could send you the cap and the blob shader (that isn't very gpu heavy, it works on a layer not on every sprite) if you are interested.

I'd very much like to see it. I also didn't know you were using custom collision shapes. Is ellipse slower? I'm thinking for an actual game I'd probably set the simulation steps to 1. I'm not sure how much that effects how "real" the water looks, but in one of quazi's examples it seemed just as good as 10. I'm also wondering if the physics plugin does any other calculations that really aren't necessary liquid, or at least, don't make a big difference.

I'd very much like to see it. I also didn't know you were using custom collision shapes. Is ellipse slower? I'm thinking for an actual game I'd probably set the simulation steps to 1. I'm not sure how much that effects how "real" the water looks, but in one of quazi's examples it seemed just as good as 10. I'm also wondering if the physics plugin does any other calculations that really aren't necessary liquid, or at least, don't make a big difference.

Using custom collision was a neccessity because of the nature of the shader. What you see of one "water drop" is just about 5% of its actual size. If I'd used ellipse, the drops would collide although they are visually still far away from each other. I'd bet the standard collision shapes are faster.

From my experience the lowest simuation steps are better for liquids. Maybe it is a kind of "tree lookup depth", but whatever it is, the liquids feels more natural with less steps.

Here is the link to the same project as the exe you were already testing, but as a .cap plus the needed effect: fluid.rar

When i first started making fluidy things my computer was pretty slow so i did a lot of testing on collision types.

it seems plausible at first that having a custom collision polygon with less side# would make the simulation faster, but thats not exactly the case. the physics doesn't have trouble handling points/ edges etc, rather the collisions between objects/points/edges are what cause slowdown. having a triangular or square shape can cause the "particles" of fluid to catch each other and make extremely large slowdown spikes when "compressed", not to mention unrealistic stacking behaviour.

using ellipses actually fixes EVERY problem, circles seem like "higher fidelity" shapes to process, but the reverse is actually true, an ellipse is very simple, and can be defined and have collisions tested against it with one simple distance check, and a few trig functions like sin and cos. checking if two spheres at any angle collide is as easy as checking the distance to see if its less than the sum of the two radii.

you can have WAY more circular colliding physics objects than any other shape, because they're so simple to process and check, so put on those ellipses!

the only problem with this method is the ellipse shape in the physics plugin assumes you want the ellipses to have the width and height of the graphic, the way around this to get the quaziblob effect to work is by using one object for the physics, and putting a separate graphic sprite thats larger in a container with the physics object, then setting its position to that of the physics objects every frame.

like tul said, this is because the visual effect is only 5% the size of the meta-gradient graphic that makes the whole effect work

QuaziGNRLnose, tulamide and any others who have contributed.

Thank you for your efforts.

There are people out there (like me) who really appreciate this fluid simulation.

As you can see by the post count (as of now, 2) I'm new to this. But thanks to you guys (and some lost sleep reading tutorials and forum), I think I have all the major stuff to get my game running.

Now all that I need is just one tiny little matter of getting-decent-art-intead-of-placeholders-and-music-and-let's-not-forget-sound-fx-also-different-levels-probably-save-file-and-not-mandatory-but-i-really-really-wanted-a-level-editor-for-the-player and I'm done!

i can propably point you to the right direction if you would need music and maybe SFX.

As for graphics - depends what do you need.

Quazi,

thanks for the tips. I pursued the same approach, trying to use a dummy physics object with ellipse collision and setting the blobs to the dummy's position. But I used an id-system and whatever went wrong (can't tell, because I can't find that test cap), the result was that after a few hundred sprites the physics refused to work correctly. Suddenly the framerate went down to under 10fps and objects fell through "solids", etc.

Didn't think of containers. After reading your post, I retried and the container trick works perfectly, as can be seen here:

(Left: custom, Right: ellipse)

Note: The only change is to spawn one dummy with ellipse collision check and one blob sprite, instead of just one blob sprite with custom collision check. Although having double as much sprites, I could double the max particles.

Now I finally have enough fluid to form my game idea to something playable. Yeah

Quazi,

thanks for the tips. I pursued the same approach, trying to use a dummy physics object with ellipse collision and setting the blobs to the dummy's position. But I used an id-system and whatever went wrong (can't tell, because I can't find that test cap), the result was that after a few hundred sprites the physics refused to work correctly. Suddenly the framerate went down to under 10fps and objects fell through "solids", etc.

Didn't think of containers. After reading your post, I retried and the container trick works perfectly, as can be seen here:

(Left: custom, Right: ellipse)

Note: The only change is to spawn one dummy with ellipse collision check and one blob sprite, instead of just one blob sprite with custom collision check. Although having double as much sprites, I could double the max particles.

Now I finally have enough fluid to form my game idea to something playable. Yeah

this looks mind blowing O_O

irbis,

Thanks for the offer. I will first work out more stuff (still on my first week of this) and get me my first complete level working (it's not really complete, but it's playable). Then I'll worry about all that other stuff I said I "just needed".

tulamide,

I'm also working on a game that uses lots of water, but probably completely different. I can work with the fluid .cap that you graciously uploaded, and I made some changes to it (removed the darkening over time), but I'm still wet behind my ears (pardon the pun) to get that ellipse collision going on.

Can I get another .cap with more liquid stuff please?

Is it ok to ask for caps of liquids to strangers in your countries? In my country it is not illegal but it is impolite and a sign of alcoholic dependency. Ah well, I'll buy you a beer if you come to Portugal. This way it's not begging for booze. It's having a party!