Any Plans for Liquids?

[Julio Jerez]

Ok, just started to work on SPH for real.
First impression is MPM seems overall better, both regarding realism and performance,

umm, I do no thing so.

SPH is a serious discretization of Eulerian mechanics.
https://en.wikipedia.org/wiki/Smoothed- ... rodynamics

while MPM, at least form what I read, is just hacking solution, simulate to what our nvidi expert do with the position base physics.

what you see in the SPH is just crus approximation, but once you have a working version, you can them add refinements to get more accuracy and features and you can approach real like behavior. while those other method need more hacks.
I do not think I will spend any time on MPM.

[JoshKlint]

I really like your ideas. The Earth sciences people will love this too.

[JoeJ]

while MPM, at least form what I read, is just hacking solution, simulate to what our nvidi expert do with the position base physics.

I don't think it's more of a 'hack' than SPH.
The only difference is MPM interacts with a velocity field instead of particles, but this field is generated form the particles, and the smoothing generated from the grid discretization is comparable to the averaging using SPH smoothing kernels. Just, with MPM all particles use the same amount of smoothing (or interaction radius). If we want different radii to model different materials, we would need a multiresolution grid. With SPH we can just set a different radius per particle, which is easy (but not practical either, because iterating more than 3^3 cells is just too slow). On the other hand, MPM gives you a 3x3 matrix to model directional pressure, which eases up modeling different materials behaviors.
Another MPM advantage is: No jitter as adjacent particles enter or leave the radius.

In their basic forms both methods have no robust volume preseravtion. Both are the same kind of computer animation toys imo.

But that's not what i tried to say.
Currently, using adjacency lists, you need even more memory per particle than i do for my fat MPM particles.
With the optimization i proposed, no more list is needed, because we can do all adjacency interactions while finding the neighbors. We need it just once, so no need to cache it. Huge win! And we can't expect real world accuracy anyway. It's a toy, no serious simulation like rigid bodies, and performance is all that matters.

But i have a hard time to make a decision. Using density from the previous timestep is clearly wrong, but i have no advanced simulations yet to judge the error. Likely i should keep both methods around for some time, to see if in some cases a difference or problem shows up...

Regarding collisions with static world, i also voxelize the geometry. But i don't represent it with particles. Instead i use a density volume with gradient for normals. Sparse grid is nice to compress this.
Thinking about doing this in realtime to support dynamics... ugh. Wake me up when people can afford the shiny next generation of 100tf GPUs

[Julio Jerez]

No Joe sph is a toy in the way it is use for game.

Sph is one of the method use if super computers to simulate a wide range if effects.
From galaxies, granular material, or fluids.

But in any case. I may have a bias because sph is the only method I tried so far. And I haven't even get a good implementation yet, just a proff of concept.
Maybe after that, I experiment with some others.

In any case, if you can get rid of the pair that could be a great saving if it get the same results.

In the method I choose, of physically forming the pairs in an array.
It does used a lot more memory yes, but in gpus does not uses more bandwidth, not at least until gpus have smart cache.
A grid hash the algorithm has to iterate over the hash map many time for the same particle, while the sorted array read the location just once. So bother method has a
O (k) time complexity but the k is a lot smaller fir the array.
Here is the interesting part.
Gpu are made such that memory access maximizes when many cores read adjacent memory locations. So that's my rational for going with the array.

But you are again correct, in the cpu implementation my version saturates the cpu so it does not get any faster with more than 2 or three threads.
I measured it using intel v tune, and it pins the memory at about six gbyte per second regardless of the core count. In fact it gets slower with 16 threads, the maximum I allowed in the engine.
Gpus has about 20 time or more that bandwidth so that's what I am going after.

[JoeJ]

But you are again correct, in the cpu implementation my version saturates the cpu so it does not get any faster with more than 2 or three threads.

I have this same situation when reordering the particles in memory so they are sorted by grid order. Basically just copying memory, and here two threads already saturate BW. In a situation where we can no do a lot of math on the data we shuffle around, we are just *.

All other tasks have very good scaling. Often i even get a speedup higher than 8 on my 8 core.
But sadly, only if the workload is massive. For realtime stuff like games we want small workloads and it becomes much harder to saturate cores and have good scaling.

I got all those fancy material models from the MPM github project. Snow, sand, honey, even concrete. The math of this stuff is pretty heavy. Many matrix ops, singular value decomposition, transcendental ops. The extra cost of this isn't that high, comparing with the simple water material. It seems, similar to GPU, we can do a lot of math for free when/while accessing memory. So maybe we can get a better cost / benefit ratio by using more complex materials.

Though, what i would desire the most for games would be just smoke and water. Big bodies of water would enable interesting mechanics, like puzzles, where you flood parts of a cave to reach higher places.
And smoke / fog would be really awesome for visuals and atmosphere. But seems just not practical. I think about faking it, e.g. having billboard particles with some 2D simulations, interacting with each other, so from the camera it looks right. But it's hard to get beyond some vague ideas i guess, and efficient lighting alone already is super hard.

Well, even in the distant future, there always remains work for us...

[JoeJ]

Oops, i have to take back my optimization proposal.
Turned out i forgot to disable some position correction filter to keep MPM particles apart from each other, and this did dominate the simulation and had a heavy damping effect.
After turning this off, i can see now my idea does not work. It causes turbulence and oscillations.

Maybe i can make it work by reversing the order of the two passes, but i guess not...

[JoshKlint]

What are your thoughts on mesh construction? Do you think this should be done on the CPU or maybe the particles should be converted into a volume texture and a mesh should be constructed in a compute shader?

[Julio Jerez]

I am torn on the options.
There is particles scene proof of concept in the SDK.
the simulation runs in cpu, and is at the edge of what is practical.
the most unexpected part of the entire experiment is the problem of rendering the mesh.

there are two ways,
1-rendering particle and do rendering tricks.
2-buidl an iso surface.

believe or not rendering the particles became many times over more expensive that the rest of the simulation.
The reason is that loading 6 points, per particle to draw a quad, becames very expensive.
so I reduced to just one point and using geometry shader to make a quad,
but even them, loading the date is the bottleneck.
so that leaves the particle draw as a debug option only.

the secund option is the more attractive, but harder.
there iso surface code already. and I will go back to it next year.

The answer is that the reason I am exploring the GPU, is that that kind of things, required visual representation, and because they rely on big data, it is better to have them be on GPU.
so that one of the goal to have a GPU solution.

yes, CPU are big theses days, but not everyone has them, while almost everyone has a decent GPU.
and when you go to Mobiles and Console, those big GPU will never make to that ecosystem.

at the beginning of the year, I tried to experiment with intel CYCL
https://community.intel.com/t5/Intel-on ... -p/1353852

but I guess I was too early. there was not way to test, unless you have an intel embedded GPU,
and windows support was almost non existing.
I have not really hope that there will even be windows support, but they are claiming support of other devices and OS is more develop, so that's worth trying.

I them switch to CUDA, and it is still as disappointed as it was in the pass.
yes, you can probably get something going but the amount of dedication and willing to bend you nvidia demands is not something I will ever do.

so the answer is that I next year I will try sycl again, and is that goes fine, the on windows we can always do DX12.

[Julio Jerez]

one reason to try again with sycl, is that back when I try, there was no intel hardware.
but now we have a competitive GPU the ARC A750 and other, which can be use for testing in windows.

and I count on the cross port on other OS as they say.
https://www.intel.com/content/www/us/en ... -gpus.html

so write once and try on many other hardware.
but as I said before, I take all those promise with a huge grain of salt,
there is a lot of misleading information out there.

[JoeJ]

Just had some discussion, and heard about this 'cross-vendor' SYCL implementation:
https://github.com/illuhad/hipSYCL
Likely restricted to Linux, at least for AMD, but maybe useful.

[Julio Jerez]

yes, I read that too.

but now that intel has real assessable and affordable hardware, we can develop in windows.
and then we can test on linux systems.
maybe one day someone decides to do support windows and osx,
although I guess it requires support from Microsoft and Apple.

but one thing that I see happening is that the mobiles devices are becoming very strong.
so a Linux support is not a bad idea.

but that is a project for next year anyway. I order an arc 750 from amazon, but I done have it yet.
I do no put my hope high, it may very well be possible the intel drive dot not even recognized.
I had that problem at the beginning of the year with embedded intel, so I had to get a newer version that only work with VS 2019.

but I guess it is how things are when you rely of these free tech.

[JoeJ]

> I order an arc 750

I'm very excited about Intels GPUs. On paper it's by far the best offer since many years. Seems they almost sell this at a loss, saving PC gaming with low prices.

I'd get one too, but i have to pick up some RDNA2 to estimate console performance instead...

[Julio Jerez]

The one thing that is happening to the gpus world is that normal graphics raterization is not longer driving it.
This is one of the reasons new hardware makers are putin silicon on other things..
Dedicated matrix vector multiplier for neural net, which in my opinion is just a huge mistake since those cores are utterly useless for normal lineal algebra operation.
They are also adding silicon to video compression, and image smart scaling.
Also dedicated silicon for Ray tracing.

We are probably getting very close to the maximum that is possible fixable for a consumer gpu, since there is not real reason for anyone to get one to play games anymore.
There is still room in the world of super computing.

The other point is that what drives the performance of a game is not the high end gpu or cpu, studios spent the large majority of time optimizing for the lowest common denominator. The data shows, that the large majority of people who buy these games, still have older GPU.

All of that is the result of video game not longer been capable to max out an even mid end video card.

These reason are sufficient for me to just get a mid range intel arc gpu. To me, the prospect that I could program in the same cpp language has far more value than what a top of the line gpus offers even if the performance could be half or less.

The one thing I am looking to get is one of those intel NUC box.
They come with a 12 generation cpu, and some even have entered Arc 770.
And those are in the same league of nvidia 3050.

Of course this is all my speculation.

[JoeJ]

We are probably getting very close to the maximum that is possible fixable for a consumer gpu, since there is not real reason for anyone to get one to play games anymore.

That would be nice. It's a time of regression, so we want to make games which do not force people to upgrade at all.

But i am very, very pessimistic. NV is very successful with raising expectations and selling snake oil. People believe their fairytales about path traced 20fps games blown up to be playable with AI, running on 2000 bucks / 500W GPUs. Both devs and players believe it. Most of them.
And even if not - they all switch over to UE5, one after another. And sadly, even with Nanite being the right direction and just great, Lumen is a terrible mess. Matrix city demo runs at 20fps on my >10tf GPU. Silent Hill remake is a 30 fps game even on high end PC. It's just too slow.

So we will get high minimum specs no matter what pretty soon. And then not only the games themselves disappoint, but also the unaffordable HW needed to keep up.
Many people will just quit gaming. We'll get another video game crash, i'm afraid.

Devs seem to desperate about getting further gfx progress quickly and for low effort.
Toning down seems no option to them. They rather prefer to crash into the ice berg at full speed and glory.
But i really hope i'm wrong!

[Julio Jerez]

On the new gpu.
I was hoping that Intel made those NUC for 13 generation cpu.
So far the higher the go is 12 Gen, but those do not have a good competitive embedded gpu.

What I like about those small system, is that they are a black box that you use like a console.
They do not need a descrete GPU.

So I see what is available January next year,
If there still not 13 Gen nuc, I will probably get a complete system.
My system is aboutv10 years old already, and I am surprised it still keep up with modern systems.