Any Plans for Liquids?

[Leadwerks]

Wow, yes, that is what I want.

[Julio Jerez]

Darn Joe, that's really impresive.

Yes the biguess draw of the sph is the density computation.

On average each particle can be a nieborgh of a rather large number of particle.
On an amd gpu presentation they show a demo tha limit the max to upto 32 , because of the gpu arch, but you can see the elastic behavior. It looks good for high reynold liquid like
Oil or lave, but not for stuff like water, or my wish gasses.

I have done most the infra structure work to do all that, and so far I get a good speed for a block of 32k that when building the block results on a vector from 256 to a million entry to buil the blocks.

This is a much as it can get with four core, under 16 ms.

But if this MPM method have a way around to calculate the density, than does not require nieborgh, that's about an order of magnitu speed up, maybe ever faster. Wich means is possible to target 64k particles for real time and not make just a check box demo.

I will take a good look at that parper and see if I can retool the method. Since I have all the infrastructure set up I can just add a new particle type.

BTW check out newton 4, I have made few solver improvement and the solver is now lock free, for the first time I see avx2 been really faster than sse.
In 3.14 this difference is only marginal because the atomic counters usage.

[JoeJ]

But if this MPM method have a way around to calculate the density, than does not require nieborgh, that's about an order of magnitu speed up, maybe ever faster. Wich means is possible to target 64k particles for real time and not make just a check box demo.

Yeah, MPM models all particle interaction with the momentum background grid. That's what's so attractive about it. To me it seems SPH is pretty much dead after that.

On an amd gpu presentation they show a demo tha limit the max to upto 32

I had GPU in mind, and though about limitations and issues. It would be like that, using MPM:

Code: Select all

workgroup per block:

ivec4 momentumVolumeInLDS[6*6*6];


for each particle in parallel:
{
do dynamics math // Heavy 3x3matrix stuff. Register pressure expected. Multiple materials no option on GPU - need a generalized material instead.

for each cell of 27 (or 8 for games) neighbors
{
distribute weighted particle momentum to background grid cells
atomic_add (momentumVolumeInLDS[cell], convert_float_to_int(pm)) // i think AMD still lacks floating point atomics. Not sure about precision issues, but clipping velocity could be necessary for other reasons anyways.
}
}
finally write LDS volume to video memory.


No video memory access in inner loop. I think it would work very well and fully saturate GPU.

BTW check out newton 4

Yeah... i planned to integrate to editor and combine with fluid sim, but too much work for now - need to focus other things first.
So i'll probably look at it only when working on engine runtime for a little demo game. ...still months away (if i'm lucky).

So no feedback for now...

[Julio Jerez]

well I download the github zip and does really compile in windows. It seems to requires lot of extra stuff. apparently is linux only so I give up on that.

I like to read the paper, but somehow every link to the paper gives 404 error.
no sure what to make of that.
they say the solver is 88 lines but I do not really undertand what is that it is doing.

I mean, I do see the videos, so it seems the evidence for the is strong, but I can't see any concrete evidence of the theory behind it.

I never heard of MPM, so I will do some research to see if I can find some papers.

[JoeJ]

well I download the github zip and does really compile in windows. It seems to requires lot of extra stuff. apparently is linux only so I give up on that.

Yeah, the code is incomplete - maybe on linux it would download the missing parts, but the important stuff is there.
Though, it took me more than a week to port it (mainly because my matrix transpose wrapper function did return the original matrix instead, sigh )
The 88 line 2D demo compiles and runs on windows, so i started from there. I had to look up a working implementation of SVD decomposition: http://pages.cs.wisc.edu/~sifakis/project_pages/svd.html
I also had to swap matrix order, deal with other math syntax and convention issues, one off errors, paranoia... all the nice things.
Biggest problem was lacking understanding of math - you would have it easier here.

Paper is here:https://yuanming.taichi.graphics/publication/2018-mlsmpm/mls-mpm-cpic.pdf
Talk:

The method itself is pretty old, but the MLS addition from above os both simplification and optimization.

[JoeJ]

Oh sorry, i just saw i remembered sparse grid costs very wrongly. It's 27%, so i would agree it's probably not worth for realtime. But it's not that easy to say...

Attached my profiler output:

mpm perf.png (24.58 KiB) Viewed 10321 times

The tabbed timings listed above 'UpdateSparseGrid' are subtasks of that. I guess simple regular grid could be 2-3 times faster (unfortunately i don't have it anymore).

I need to add, my algorithm requires exact particle binning every frame, otherwise other optimizations would break. But having loose binning distributed over time would be another interesting idea of optimization.

IIRC, the cool realtime sim on YT uses 32^3 grid, maybe 64.
That's pretty large, and we can not simulate so many particles in realtime anyways.
There is also the related question: How many particles per cell do we want or need?
Unfortunately i have just started with experiments and i'm still unsure about that. But i would say one particle behaves somehow poor, 2^3 particles seems just fine.
With 8 particles we would get a 'geometrical resolution' of max 128^3 particles.
More than enough for puddles of 'slow motion water'

But can we do lava? Floating over the whole level or some larger area?
Well, assuming one lava particle has a size of 0.25m,
we get a real world domain size of 64*(0.25*2) = 32 meters. Not so much.

So that's why i think it's worth it even if cost is high, but if so it's easy to add later on. It's not much work either - took me only a day to implement and use the sparse grid, making the update multi threaded maybe another day or two.

[Julio Jerez]

the point I am trying to make is that, putting so much effort in a spatial data structure for particle is not really worth the effort for the kind of effects used in games.

the same method that apply to small set of object also apply to medium set of objects.
take for example sorting. a quick sort is faster than a bubble sort or insertion sort for medium to large arrays. but for array that are almos presorted or for small array a brute force method is much faster.

for the particle system, when we are talking of arrays of 50 to 100 thousand elements. all of equal size. when you cluster then in cells. a very simple calculation will reduce a 100k points to 10k clusters. assuming 10 particle per cluster of average.
with today's cpu, that's a perfectly manageable work load.

now if you are talking of a large scale simulation of the order of million to then of millions of points, then yes, you are right a spatial data structure is justifiable.

now if you add to that, that video games are not really scientific simulations. in video game is more important to look good than to be acurate, so a simulation for a lave flow with particles that are .25 of a meter in radius is useless for game interactions and the simulation will still look really horrible.
these are part of the reasons why all those nvidia demos fail. they look impressive in a contrive setting but when a designer try to use then on any Game, that pitch does not pass the first meeting.

this is why my plan is to limited to a max of 32 to 64k particles, of small enough size that can simulate a convincing effect. but keeping with a small scope.

stuff like small fluid spill that are primarily 2d. small volume of water, smoke puff, and stuff like that.

in my book I am not even consider reading any paper by any yahoo inventing the next spatial data structure. to me a sign of a paper not to read if when they has to count of hardware resources like manipulation virtual pages. that's just a no, no in my book.

what I am going to do is read teh paper and maybe some of the one cited in the references to learn more about MPM methods before I put any effort, but there is not question that the demos look extremally promising.

[JoeJ]

so a simulation for a lave flow with particles that are .25 of a meter in radius is useless for game interactions and teh simulation will still look really horrible.

For lava it would work i think. I actually can turn particles into mesh instances or SDF primitives, blend them together, extract isosurface. Using a simple metaball primitive would be fast. I'll make a screenshot sometime if i have a scene that suits the discussion...
I would hope the dynamics of motion make it look nice, even if the surface is blobby.

Ofc. the work to render such stuff can become more expensive than the simulation itself, i guess. My isosurface extraction guarantees manifolds so it has extra complexity and i can not predict perf. for a realtime version without that. But IIRC we saw realtime marching cubes decades ago already.

TBH, fluid sim in games still feels much too expensive to me. It's also hard to come up with applications other than for visual decoration. Lava could be an exception here, but it's not really that awesome to have slowly floating stuff. I could imagine something interesting if i could remove some rocks, making a hole, and then the lava drains out, illuminating the cave we are in, setting some enemies on fire, etc... Cool, but still very costly just for that.

There is also the idea of surface only fluids: http://www.cs.columbia.edu/cg/surfaceliquids/
No idea if this could model bodies of water for games eventually.

[JoeJ]

I still think it's worth for you to add some fluid anyways. Can be fun, and fun > visuals.
Personally i want to use your particles mainly to model dynamic foliage.

[Leadwerks]

Right now I have seen my users using colliding particles for rain, bullet ricochets, and simple liquids and gases, like steam or water coming out of a pipe and bouncing off the walls and the floor.

We likely could use a more capable particle system for semi-serious simulations, the kind of stuff where real-time interaction is more important than exact accuracy, like astronaut training. If we had the ability to model particles from a fire extinguisher for firefighter training, that realistically could be a differentiating feature that wins contracts. I saw a competing division at a large company I work with that made a training simulation where the particles were just a dumb visual effect and my team could do much better with the technology you are describing. I'd also like to make a VR bartending game that measures spillage and teaches you to make drinks with the correct ingredients.

I don't know if this would be appropriate for aerodynamic testing, but it could open up a new category of things that can now be done in real-time that could not previously be done in real-time, like very rough testing of aircraft dynamics on-the-fly as the parts are designed.

There's a lot of weird stuff that uses fluids and particles no one has ever been able to simulate in real-time before, and I'm sure we could find uses for it, maybe sacrificing accuracy for the convenience of real-time feedback, and then switching to a slower more accurate model when it is needed.

[JoeJ]

alienplanet.png (219.12 KiB) Viewed 10299 times

Just had first success on generating something that looks like terrain, which is my primary goal for this.

So we have NASA spaceships, discovering the surface of strange alien planets, with lava draining through deadly canyons. I'm in

[Leadwerks]

I talked to some colleagues and they are interested in having something like this to model rocket propulsion, planet formation, and other some things. @joej I will send you a PM.

[JoeJ]

After having added particle emitters which i can move around, i can get some sense of realtime fluids. It feels pretty fast and fun. Large timesteps are possible with water.
Here's perf., using 10k particles:

10k.png (87.98 KiB) Viewed 10221 times

You see my sparse stuff really tanks with lower particle counts. But physics is good, and i did not really try to optimize this yet. It also looks 10k particles is pretty detailed, though...

[JoeJ]

isosurf.jpg (192.94 KiB) Viewed 10221 times

... using some simple metaballs thing, it's quite blobby.

[Julio Jerez]

Yes from 10 to maybe 32k particles is about what I a targeting for small effects.
Making it sufficienly small should be good for some reliable particle effect like bucket that contains fluid, spills, splashes alflames, and stuff like that.

I have been so busy with work that I have not have time to complete the effect, but I will resolute maybe in a week or two.