2D Liquid Simulation Engine

New releases and general discussions.

Post » Sat Jan 08, 2011 11:39 pm

I'm wondering if this 2D fluid simulation engine could be ported or replicated for Construct: [url:17xu0zjq]http://www.youtube.com/watch?v=0bL80G1HX9w[/url:17xu0zjq]

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.
B
2
S
2
G
2
Posts: 372
Reputation: 1,794

Post » Sun Jan 09, 2011 12:29 am

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
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Sun Jan 09, 2011 1:11 am

Yes, I've done it also a while ago, with physics and a special blob shader:
[url:1gv8dxwz]http://www.scirra.com/forum/viewtopic.php?f=8&t=7037&p=55148#p55148[/url:1gv8dxwz]

It isn't very complicated.
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

Post » Sun Jan 09, 2011 3:34 am

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.
B
2
S
2
G
2
Posts: 372
Reputation: 1,794

Post » Sun Jan 09, 2011 5:01 am

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.
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Sun Jan 09, 2011 6:05 am

[quote="Mr Wolf":1t9e5vw4]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.[/quote:1t9e5vw4]

You could try and apply the metaball effect to rojo's example.
[url:1t9e5vw4]http://www.scirra.com/forum/viewtopic.php?f=2&t=8050&hilit=water+minecraft[/url:1t9e5vw4]

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.
Image Image
B
161
S
48
G
90
Posts: 7,356
Reputation: 66,767

Post » Sun Jan 09, 2011 6:46 am

[quote="Mr Wolf":9fz9lgpo]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.[/quote:9fz9lgpo]
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.
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

Post » Sun Jan 09, 2011 4:01 pm

[quote="tulamide":n22orfgl][quote="Mr Wolf":n22orfgl]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.[/quote:n22orfgl]
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.[/quote:n22orfgl]
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.
B
2
S
2
G
2
Posts: 372
Reputation: 1,794

Post » Sun Jan 09, 2011 6:45 pm

[quote="Mr Wolf":27pgcalc]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.[/quote:27pgcalc]
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
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

Post » Tue Jan 11, 2011 5:21 am

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
B
52
S
7
G
6
Posts: 1,945
Reputation: 7,610

Next

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 1 guest