Quick 'n Dirty Verlet Fluids v0.1

[Riven]

A Webstart link, for all those lazy bastards out here, eventhough I hate it with a vengeance.
http://www.indiespot.net/files/verlet-liquid.jnlp

There are 8192 particles in this demo. The water has a bit (too much) viscosity, so it will form drops in the air. You can drag the raft around a bit with the mouse. It won't stay afloat for too long, because the water is flowing very rough. The demo tries to make use of multiple cores, but it still doesn't manage to use 100% of all 4 cores of my CPU. On my Q6600 I get 50fps, singlethreaded it gives me 25fps.


If you would tell me your FPS (in the titlebar) and your CPU type (and how many cores) it'd be nice!

[DzzD]

If you would tell me your FPS (in the titlebar) and your CPU type (and how many cores) it'd be nice!

Intel 2 core CPU T7500 2.2Ghz - Java 6-u14 - 30/35 fps - 80% of cpu usage

[Jono]

I get between 10 and 15 fps. Using Athlon X2 4000+ (that's two cores, both being used by the demo).

Edit: It uses 130-140% CPU, and if I minimise the window (so no rendering) then I get around +8 fps.

Games published by our own members! Check 'em out!

[Riven]

Thanks for your reports.

I fear I will have to totally rethink the datastructure to improve the performance significantly.

It may be fast enough though for your average simulation.

[SimonH]

A Webstart link, for all those lazy bastards out here, eventhough I hate it with a vengeance.

So... maybe an applet? I'm more lazy that that! 

<10fps (& jerks a bit) 1 core . Looks nice though, suspect my crud GPU is to blame.

[Riven]

So... maybe an applet? I'm more lazy that that! 

Ha! Applets are infinitely worse! I'd hate to crash your browser.

<10fps (& jerks a bit) 1 core . Looks nice though, suspect my crud GPU is to blame.

So.. what's the CPU and what's the GPU?

[DzzD]

Ha! Applets are infinitely worse! I'd hate to crash your browser.

no no no, and even if Applet + opengl may be worse wich I dont believe is true, webstart sucks even a direct link to an executable jar is better than webstart. NB: I have tested this demo cause it come from you and I wouldn't have if it was not from a known JGO member.

and sry to be off topic

[Epitaph64]

8-15fps on 3000+ 1.8 ghz single core with 8800GTS 320 MB.

[Riven]

@DzzD

Yeah, let's not derail it too much. Basically saying that Webstart has major problems, and applets have too. Even these days my browser(s) sometimes crashes on them.

If it makes you happier, the jar the jnlp refers to, is executable:
http://www.indiespot.net/files/verlet-liquid.jar

[Ranger]

That's cool!  28-38fps Intel Core2 2.0Ghz.  No different when minimised.

Wish it was an Applet 

Games published by our own members! Check 'em out!

[bobjob]

thanx for making it a webstart

minimum FPS: 28
Average FPS: 32

WinXP DualCore E5200 @ 2.50Ghz
2GB ram

do you have any gaming plans for the physics?

[Alric]

I get about 35FS on a dual core T7500 2.2Ghz, 8700M GT graphics.

[Orangy Tang]

About 50fps here with a Core 2 Duo @ 3Ghz. Looks really cool, very turbulent.

[Mr. Gol]

Around 30-40 FPS on a MacBook with a 2.1 Ghz Core 2 Duo.

[Riven]

do you have any gaming plans for the physics?

Nah, I'm not really artistic, nor creative for that matter. I love to do designing and optimising, but don't expect me to release something playable.

About 50fps here with a Core 2 Duo @ 3Ghz. Looks really cool, very turbulent.

Wow, well, it seems like the algorithm still takes more advantage of the clockspeed than the amount of cores.

The turbulence is just a side effect if the integrator, not really hard work Another nice thing is that the current algorithm works in 3D too - I'd only have to change 1 line of code - basically assigning a z-value (instead of 0.0) to every drop and watch it go. I'm just not really into writing a 3D renderer in Java2D, and going to LWJGL is a bit out of scope of this probject.


The only problem with the current algorithm is that large liquid bodies tend to get unstable at the bottom, due to the massive stress and conflicting constraints. The problem is that I can't relax the collision response (or releasing tension of springs), because then the liquid becomes compressable, which causes 'global resonation' - the fluid falls in on itself, then explodes, in an infinte loop - besides that, real fluids are not compressible anyway, so relaxing is not how I should be solving the stress problem anyway. I already slightly hacked the verlet code to handle fluids differently from your average sphere/sphere collision, but there are still some drops shooting out like fireworks.

[princec]

Vista64, about 70fps, 8 cores (i7), uses about 30% CPU - think it's the 32bit VM though.

Cas

[Riven]

Vista64, about 70fps, 8 cores (i7), uses about 30% CPU - think it's the 32bit VM though.

Cas

Eight virtual cores (hyper threading) I guess?

I hope that Runtime.getRuntime().availableProcessors() returns 8 in this case.


I also have Vista64, and there is no fps difference between the 32 and 64 bit JRE in this demo, it only uses a bit more memory due to the larger pointer size.

[CommanderKeith]

Cool demo, 35 fps running at 85% on a dual core intel 2.16gHz laptop, 3GB RAM, NVidia 8600 GPU.

Reminds me of that sand, water and elements games where you burn up the sand.

[Riven]

Cool demo, 35 fps running at 85% on a dual core intel 2.16gHz laptop, 3GB RAM, NVidia 8600 GPU.

Reminds me of that sand, water and elements games where you burn up the sand.

Except that those games have very bad physics They are only acceptable because the gameplay is so much fun!

[CommanderKeith]

True, my little brother spent ages on those games - i never understood why because there was no objective at all but he liked it.

So let us in on how your verlet physics works - does it use circles or squares for collisions? 8000+ things colliding with each other is quite a lot.

And is most of the CPU time spent doing physics or rendering because I notice that the window is pretty big

[Riven]

The collision is both squares and spheres.


Every tick() this happens:

• a simple (empty!) rectangular grid (cellSize is determined) is created/reused
• the grid is filled, by taking the center of each drop, calculating the cell[ x ][ y ] where the drop should be added
• another cell2[ w ][ h ] is filled, and for each cell, it adds the current cell and all neighbouring cells

         ==> now cell2[ x ][ y ] has roughly ~9 times the cell[ x ][ y ] drop count
         ==> for each cell[ x ][ y ], we now have all potential colliding drops in cell2[ x ][ y ]

• traverse the grid, and for each cell[ x ][ y ] collide each drop with every drop in cell2[ x ][ y ], except itself

         ==> only this part is multi-threaded

• clear all drops from both cell[ x ][ y ] and cell2[ x ][ y ]

The grid.cellSize is adjusted automatically (in steps of 10%), by measuring its own performance. It basically does some trial-and-error and after N iterations, approaches an optimum (hopefully not a local optimum) and kinda stays there. When the location of large sums of particles will change, it is likely that the grid will also converge to another optimal cellSize.

[CommanderKeith]

Interesting, so how big is the grid, 1 cell per pixel? It appears that the droplets compress and end up in the same cell so I guess the cells are smaller than a pixel? How do you chuck the big boat in there which is obviously bigger than a cell?

[Riven]

Well, in each cell2[ x ][ y ], the following drops will be added:

cell[ x - 1 ][ y - 1]
cell[ x + 0 ][ y - 1]
cell[ x + 1 ][ y - 1]
cell[ x - 1 ][ y + 0]
cell[ x + 0 ][ y + 0]
cell[ x + 1 ][ y + 0]
cell[ x - 1 ][ y + 1]
cell[ x + 0 ][ y + 1]
cell[ x + 1 ][ y + 1]


The drops in cell[ x ][ y ] can only collide with the drops in cell2[ x ][ y ], so naturally, the cellSize must be greater than the dropRadius, because otherwise the potential colliders wouldn't be in cell2[ x ][ y ]. The current dropRadius is 2,75. Typically, the cellSize ends up at 12..16 pixels (on my CPU, in this scene), which basically means that in cell2[ x ][ y ], the drops are gathered that are found in a (12..16)*3 = 36..48 pixel square.

Regarding the boat, it is not interacting with the liquid grid (cells) directly. I calculate the bounding sphere (rendered as a grey circle) of the boat. Then I query the grid for all cells that intersect that bounding sphere. I sorta took a (slower) shortcut, by calculating the boundingbox of the boundingsphere (is too big, I know), calculated the minimal x,y and maximal x,y cell coordinates in the grid, corresponding with that boundingbox, then subtract -1,-1 cell from the minimum, and add 1,1 to the maximum cell (adding the neighbouring cells), and grab all drops in that rectangular group of cells. Then I collide (pure Verlet) all drops (basically spheres) with all spheres in the boat.

[markus.borbely]

I have a 5 year old laptop. It got an Intel celeron M 1.4 GHz CPU.
Framerate: 10-12


I also got a year old stationary. It got an intel core 2 duo 3.16 GHz.
Framerate: 35-39

[Spasi]

Win7, JRE v1.6.0_15, Intel Q6600 (quad core, 2.4GHz), getting 50fps @ ~60% CPU usage.

[swpalmer]

OpenSolaris 2009.06  64-bit, Intel Core i7 (4 cores with Hyperthreading = 8 CPU), nVidia GTS 250 GPU

50fps at about 21% CPU

Thanks for the WebStart link ;-)

[Bonbon-Chan]

Between 50-35 fps average around 42

Core 2 Dui E7400 @ 2,8Ghz, Windows XP

[ManaSink]

About 40 - 45fps
CPU% = ~ 120%  (linux style, looks like about 60% per core)

Linux CentOS 5.1
Intel(R) Core(TM)2 Duo CPU     E6550  @ 2.33GHz
NVIDIA GeForce 7600 GS
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)

[Eli Delventhal]

Intel Core 2 Duo 2.4 ghz, around 30 fps, about 95% of cpu. At one point I randomly was getting 2 or 3 fps, I think it was when the raft was buried.

[ewjordan]

Looking very good, I'm impressed you're getting that many particles going at once without too much slowdown.

Going to release code, too?