pouët.net

i was refering to tobe_mjj btw.

yeh archee, go do that waterthing in 4k! :)

I doubt that at least a quarter of the scene coders have the mathematical knowledge to implement this kind of stuff.

All they need is the power of reading, then the power of patience to implement it :D

For a start, a *single* coder with the mathematical knowledge and optimizing skills would be sufficient.

maali: best. 3dmark soundtrack. ever.

gloom: yeps, teque <3

iq, lostsoul: this is definetly NOT realtime, and even if it was then NOT on a standard PC.
and the exact opposite for the code complexity is the case: it isn't much of a deal code-wise. it may sound very complicated (and in fact are awfully and most of the time incomplete presented in the graphics papers), but the core routines needed are pretty simple and should be fairly easy to optimize. the problem is, that even (most) of the (already cool) presented demos do not look like real water, but more like oil or something the like. and this simply means that the simulation needs even lot more of particles/gridcells (whatever your favorite simulation method is).

of course it IS: http://www.nzone.com/object/nzone_boxofsmoke_home.html. It a PC (standard as long as you don't think on the 8800 as being alien technologie of course)

Now, for the voxel resolution I agree we are still limited to low sampling rates, indeed.

I was actually about to work on fluids with metaballs for rendering, I'm targeting more or less things like this, with some ideas for optimisations... well I have cubic windowing to fasten the metaballs. Then for water particles, any trick to get the neighbour particles would do it (3D table at higher level). But maybe "Finite element method" could lead to a better result... or maybe a mix of particle AND Finite elements. :-)
I hesitate between coding some physics or coding some sound generators... and between redesigning some engine. Brrr too much work for a lazy guy.

FIRE
WATER

I am the god of hellfire
And I bring you...

Fire, I'll take you to burn
Fire, I'll take you to learn
I'll see you burn

You fought hard
And you saved and earned
But all of it's going to burn
And your mind, your tiny mind
You know you've really been so blind
Now's your time burn your mind
You're falling far too far behind
Oh no, oh no, oh no
You gonna burn

Fire, to destroy all you've done
Fire, to end all you've become
I'll feel you burn

You've been living like a little girl
In the middle of your little world
And your mind, your tiny mind
You know you've really been so blind
Now's your time burn your mind
You're falling far too far behind

Fire, I'll take you to burn
Fire, I'll take you to learn
You're gonna burn
You're gonna burn
You're gonna burn, burn
Burn, burn, burn

Fire, I'll take you to burn
Fire, I'll take you to learn
Fire, I'll take you to burn

however you never hesitate posting bullshit and crap

iq: this isn't half as good as the tech-demos on the previous page and only a simple extension of the already published 2D-demo. apart from that, smoke is much simpler to look "good" than water (especially if the simulation is particle-based).

256: no, actually, I also hesistate positing bullshits and craps... but of course when I finally do not, you can't know it. Phylosophically interesting: What we know from each other is seen through a filter where doubts and hesitations are flushed by the nature of a clear communication.(...)

So, anyway, here is another point: water is an uncompressible fluid.
Interesting applet I like very much.. "Water particles" are bound to have approximatively a same number of neighbours...

not half as good, but hundred times faster. I agree it's not the perfect solution, but it's an improvement. Going from 2D to 3D is one of the major obstacles in this kind of regular grid based algorithms, so this shows we are approaching the point were it will be all real-time (the lack of video memory will be main obstacle I guess). Anyway, indeed this is not groundbreaking; however not many coders are able to do even this "simple extensions" as you called it to already existing papers/demos. Or maybe we are just lazy don't care about codeporn anymore (as for the raytracing case), who knows.

noouch: thanx for the link.. i somehow totally missed that one! great stuff!

check also vorticity by mfx (?)

for a grid based solver, the 2d and 3d versions are almost identical except for an extra loop and some extra cells to take into account. the 2d one is pretty doable on ps2.0.
the biggest problem extending the 2d smoke solver to 3d on the gpu was that gpus dont support render to volume slice. when i tried it i had to do a lot of tricks with texture lookups and 2d rendertargets to make it work at all, and i ended up with something that wasnt any faster than my carefully optimised cpu version.
(the 8800 solves the 3d issue by actually supporting the required features. shame i dont have one to play with yet.)

the problem with a cpu implementation is the sheer amount of memory bandwidth and floating point ops you need to make it work at a decent res on a 3d grid. doing it on a powerful gpu solves both of the problems - it's a lot faster than any cpu for float ops, and it's really well setup memory-wise for doing convolution-style operations. it's still not perfect though. after calculating it, it's hard to have enough power left to light it or anything like that. the nvidia smoke sim suffers from that. you can blow as much power on rendering the volume nicely as you do calculating it in the first place.

there is still room for a democoder to do something in this field. the guys doing the research arent often the best coders. of course, you might get 2x the speed by optimising, but you could get 10x the speed by improving the algorithm, so it's an uphill struggle. :)

That's the thing that puzzles me the most. I can't find any paper or anything on nvidia's site where they mention, how they managed to do it.