PDA

View Full Version : Realtime fluid dynamics

mattclary
08-10-2007, 01:22 PM
OK, NASCAR seems to have this, how long before LightWave does? :rolleyes:

http://arstechnica.com/journals/science.ars/2007/08/10/real-time-modelling-of-fluid-dynamics-why-race-fans-should-care

loki74
08-10-2007, 02:24 PM
I'm not sure how "realtime" this is...

We also assume a set of example velocity fields {u_i}, forming a representative basis U of the interactions expected in the system. These example states typically are snapshots drawn from a set of off-line, full-dimensional fluid simulations. We also assume that the velocity fields in U all satisfy two important properties:
1. The states are divergence free: nabla · u_i = 0.
2. The states satisfy free-slip boundary conditions: for all fixed surface points x with normal n, we have u (x) · n = 0.

http://grail.cs.washington.edu/projects/model-reduction/41-treuille.pdf

Enforcing mass conservation (property 1 above, nabla dot u_i = 0) is actually one of the most difficult (time consuming) steps, so if the offline data is already divergence free, I'm guessing the new sim data can become so in much fewer iterations... but if the offline data isnt there....hmm.

Granted, I've only skimmed the paper, and Treuille et al ARE a very capable bunch of folks (I think he was actually involved with a keyframe controlled simulation of smoke and water--very cool stuff!!), so I wouldn't be surprised if this is some pretty revolutionary stuff...

StereoMike
08-10-2007, 04:19 PM
Watching a sample on the espn page I had the feeling it loops. So my guess is, they parent a pre-computed particle flow to a car. The graphics card has only to do particle translation (and rotation) and keep it in place.
I say fake.

my 2 ct theory.

RedBull
08-10-2007, 07:40 PM
Realtime is exactly that a shortcut way of faking things, so i don't want game level CFD, while a low res high interactivity is desired it's unlikely to get realtime CFD of any worth anytime soon..

Meanwhile check out Blenders upcoming new "Magic Fluids" (technically it's already built in, but has not been activated in the release version)

http://www10.informatik.uni-erlangen.de/%7Esinithue/ani_mfc/

Also if your interested in the Siggraph papers in particular the Fluids and Physical Simulation topics covered on Thursday at Siggraph for 07, there is some good stuff to read and watch in regards to these topics here...
http://trowley.org/sig2007.html (as there is every year)

I notice that CSIRO which is our national science research labs, (just down the road) is making a Maya plugin for the fluids paper given at Siggraph.

Also check out www.cfd.com
which has just about every known CFD software simulator listed..

loki74
08-10-2007, 08:46 PM
Meanwhile check out Blenders upcoming new "Magic Fluids" (technically it's already built in, but has not been activated in the release version)

http://www10.informatik.uni-erlangen.de/%7Esinithue/ani_mfc/

Yeah, but its still LBM, right? Personally, I've never been fond of the behavior/appearance of LBM...but thats probably just me.

08-10-2007, 08:53 PM
maya has nr realtime fluid/particle dynamics i remember alias chap who made it also wrote a 2d version for his palm pc way back ''just for fun''...not had the opportunity to look into maya's unlimited's capabilities myself mind you.

loki74
08-10-2007, 10:27 PM
maya has nr realtime fluid/particle dynamics i remember alias chap who made it also wrote a 2d version for his palm pc way back ''just for fun''...not had the opportunity to look into maya's unlimited's capabilities myself mind you.

jos stam?

he actually released the source in one of his papers... I made it into a realtime 2D gas java applet once, which was fun.

08-10-2007, 10:28 PM
that's the chappy!

lilrayray77
08-11-2007, 05:33 PM
Meanwhile check out Blenders upcoming new "Magic Fluids" (technically it's already built in, but has not been activated in the release version)

http://www10.informatik.uni-erlangen.de/%7Esinithue/ani_mfc/

Looks interesting, although, from the example, the water seemed rather viscous, but my eyes could be deceiving me. All the more reason to start learning that trademark blender interface :help:...

loki74
08-12-2007, 02:31 PM
Looks interesting, although, from the example, the water seemed rather viscous, but my eyes could be deceiving me. All the more reason to start learning that trademark blender interface :help:...

That's a result of the simulation method they use, Lattice-Boltzmann (LBM). IMHO, it looks goopier and not as good as the other methods. Also, lower viscosities take longer to simulate using LBM, so that could contribute...

Anti-Distinctly
08-12-2007, 02:44 PM
That's a result of the simulation method they use, Lattice-Boltzmann (LBM). IMHO, it looks goopier and not as good as the other methods. Also, lower viscosities take longer to simulate using LBM, so that could contribute...

It could also be the surface recontruction that they use. The isosurface that is reconstructed looks as though it has the same resolution as the LBM grid, implying that it just uses a marching cubes style algorithm only. To get proper real nice Fedkiw style surafaces you ahve to use the level set technique.
This is all supposition of course :D

loki74
08-12-2007, 02:48 PM
It could also be the surface recontruction that they use. The isosurface that is reconstructed looks as though it has the same resolution as the LBM grid, implying that it just uses a marching cubes style algorithm only. To get proper real nice Fedkiw style surafaces you ahve to use the level set technique.
This is all supposition of course :D

Ah, level set is actually a volumetric signed distance field--it still has got to be triangluated with marching cubes (or some other meshing method).

But you make an excellent point--using a lower or equal-to resolution with marching cubes compared to the simulation grid could contribute to the blobbiness!

Anti-Distinctly
08-12-2007, 05:15 PM
Ah, level set is actually a volumetric signed distance field--it still has got to be triangluated with marching cubes (or some other meshing method).

Totally true, but with marching cubes only you're resolution is limited by the resolution of your LBM grid (I think, I'm not too hot on the LBM), but if you use the results of the LBM on a level set, you can have that evolve on a grid of much higher resolution.
Again, I'm just making assumptions, but the fluids in Blender I thought was someone's implementation of the LBM. Not sure how concerned they were with the surface extaction. Level sets can be a ***** apparantly too, so marching cubes would've saved a lot of headaches :)

RedBull
08-12-2007, 06:40 PM
LBM does suffer in memory consumption, but personally i prefer it to the NS solvers I've used in applications like Realflow and Maya.

To remove the blobbyness which i don't personally mind too much anyway.
you need to use a large resolution. (I Believe Glu3D used LBM too, and i also like it over standard Maya)

I do have the optimized AMD SSE3 64bit version of Blender, so i must say over standard Blender release I'm able to render larger quality now and much faster speeds.

And for this reason it's fairly good to me, and it took a day to master...
(it's just that awkward Blender interface.. :) I seem to get much faster calcs out of Blender than Reaflow, and Blender isn't multithreaded for it's calcs.

Houdini finally has the old http://www.myrtlesoftware.com/ fluids solver built in 9.0, (also note that Maya has Myrtles 5x5 Voxel Renderer coming, (goodbye Hypervoxels) And they are rewriting Digital Domains "Storm" Renderer..
I'm getting jealous of the FX of others. :)

I have not tried the Houdini one, although i have loaded the Beta. Don't know what algorithm they use it that one... (I Believe it's N-S)
I believe the CSIRO are making a SPH plugin for Maya.

As for some more Realtime stuff, that was originally the link i meant to post
I don't know why i posted the magic fluids link... :) As it was a little old anyway.

http://www.cemyuksel.com/research/waveparticles/

Some of the boats and boxes look good for realtime, but the way the edges of waves interact with sides of some of the tanks, doesn't convince me...
But still cool to look at...

loki74
08-12-2007, 11:35 PM
Uh, wouldn't RF use some form of SPH? Unless its solving a NSE velo field and simply advecting particles around in that....

Anyway... I guess we'll just have to agree to disagree on this one. I have never in my life, at any resolution, seen LBM that didn't look somewhat viscous. The fact is, most of the comlex liquid behavior (as far as basic liquids, so excluding viscoelasticity, combustion, foaming, melting, etc) is in the small scale turbulence observed in very low viscosity liquids (ie, water), as well as the breaking wave situation.

The fact is, LBM sucks at both low viscosity high turbulence simulations, and I've yet to see a breaking wave simulation with LBM.

You've already mentioned the RAM problem, but at super high resolutions, this does become a serious problem. And, as you've stated, high resolution is needed for very good results.

But all in all, by BIGGEST beef is that while neither NSE or LBM are very easy to implement, the concepts behind NSE are MUCH easier to understand. Even with Mr. Thurey's psudeocode, I can't seem to wrap my mind around LBM. NSE on the other hand, is a very clear process, as Stam proved in his 100-line realtime sim code.

=====

Anti-Distictly--I don't completley get LBM... are you referring to using LBM to calculate velocities, but actually tracking the fluid on a LS grid? Up resing the LS grid compared to the velo grid can be nice, but you will end up with disconnected pieces of fluid affecting each other's motion without contact as a result (this happened in Gokteken et al's viscoelasticity paper...)

But either way, I think its less of an issue if you just use eulerian NSE from the start--that way you'll be using a level set anyway! (~_^)

RedBull
08-13-2007, 02:42 AM
Uh, wouldn't RF use some form of SPH? Unless its solving a NSE velo field and simply advecting particles around in that....

Anyway... I guess we'll just have to agree to disagree on this one. I have never in my life, at any resolution, seen LBM that didn't look somewhat viscous. The fact is, most of the comlex liquid behavior (as far as basic liquids, so excluding viscoelasticity, combustion, foaming, melting, etc) is in the small scale turbulence observed in very low viscosity liquids (ie, water), as well as the breaking wave situation.

The fact is, LBM sucks at both low viscosity high turbulence simulations, and I've yet to see a breaking wave simulation with LBM.

You've already mentioned the RAM problem, but at super high resolutions, this does become a serious problem. And, as you've stated, high resolution is needed for very good results.

Not saying it's the ideal method, I'm sure Realflow provides better results, i just get the results i need quicker out of Blenders LBM calcs...
NS is not without it's memory and performance problems too.

But let's face it no algorithm fits all, Lagrangian and Eulerian, Incompressible and Compressible fluids, SPH/LBM/NS are all far from perfect and there is much wrong with all of them in real world terms. SPH doesn't off course bring consistent results of Newtons 3rd law (Equal and Opposite), which tells me we aren't adequately solving this well as yet.

Where else except Blender have you seen many LBM based renderings with the viscosity issues? Would be interesting to know why this occurs.

Technically Houdini's 5x5 Fluids is a 2D and 3D Navier Stokes solvers, a Level Set Simulator, ripple and wave generators and a bunch other production tricks. Hope to get a chance to play with it tomorrow, as it sounds the business...

But all in all, by BIGGEST beef is that while neither NSE or LBM are very easy to implement, the concepts behind NSE are MUCH easier to understand. Even with Mr. Thurey's psudeocode, I can't seem to wrap my mind around LBM. NSE on the other hand, is a very clear process, as Stam proved in his 100-line realtime sim code.

Remembering that 100lines of a 2D OGL app, is not a 3D Solver.... :)
As Thuereys says himself, he chose LBM because it basically sits in between N-S and SPH in terms of technical trade offs....

He sure has done a lot of work with LBM since 2001 or so....
Lots of publications using LBM, even a new realtime breaking waves...
http://graphics.ethz.ch/~thuereyn/ntoken3/Publications.html

I Believe companies like CafeFX have said on record, they prefer Glu3D's SPH results compared to realflows results, for many a movie, as have Blur Studios..

I was going to contact them as they often give free licenses for people willing to show there results for the product.. And i just love using CFD... :)

You can see that Next Limit also use SPH or something NL now call XPH (Extended Particle Hydrodynamics) a more optimized and refined version...
http://www.nextlimit.com/xflow/xflow.pdf

PS... Anyone know what software was used for the waves in Surf's Up?
I know they were going to do a presentation at Sig07 about it...

Anti-Distinctly
08-13-2007, 08:35 AM
=====

Anti-Distictly--I don't completley get LBM... are you referring to using LBM to calculate velocities, but actually tracking the fluid on a LS grid? Up resing the LS grid compared to the velo grid can be nice, but you will end up with disconnected pieces of fluid affecting each other's motion without contact as a result (this happened in Gokteken et al's viscoelasticity paper...)

But either way, I think its less of an issue if you just use eulerian NSE from the start--that way you'll be using a level set anyway! (~_^)

I dont get it either. The math's just went too far for my liking in the LBM paper I read. But yeah, you have the general idea; however you get your velocities, either from LBM or NS, it doesnt really matter as the advection of the level set is a kind of independent process. It just recieves the velocity grid and updates itself based on that. The LS grid can be any size really (as far as I understand it) as one of its properties is that it'll smooth itself. Any grid points that dont lie directly on your velocity grid points are trilinearly interpolated.

loki74
08-13-2007, 11:28 AM
Not saying it's the ideal method, I'm sure Realflow provides better results, i just get the results i need quicker out of Blenders LBM calcs...
NS is not without it's memory and performance problems too.

But let's face it no algorithm fits all, Lagrangian and Eulerian, Incompressible and Compressible fluids, SPH/LBM/NS are all far from perfect and there is much wrong with all of them in real world terms. SPH doesn't off course bring consistent results of Newtons 3rd law (Equal and Opposite), which tells me we aren't adequately solving this well as yet.

Where else except Blender have you seen many LBM based renderings with the viscosity issues? Would be interesting to know why this occurs.

Well, I think we can agree that for liquids (and laminar gases), Eulerian is much better than Lagrangian, if nothing else for the sole reason that you can get a laminar surface much easier. I'm not a huge fan of SPH either. (for the record, I do not like RF very much)

If you say Glu3D uses LBM, then that would be another example of LBM results I do not like. Their examples do not look nearly as viscous as blender's, but I still feel that the behavior of most of their sims looks very unnatural.

Remembering that 100lines of a 2D OGL app, is not a 3D Solver.... :)

The program's power and complexity is not my point. My point is that having taken not a single calculus class in my life, I can understand how a basic NSE solver works. As a result, I am also able to understand (to some degree) most papers that are based on NSE solvers...Fedkiw's DSD paper, the viscoelasticity paper, the BFECC paper, the fluid control by direct wind field paper...

If I can get good results from the algorithm, then I wouldn't care as much about how it works. But I look at LBM--I can't get good results from it, I haven't seen any results from it which I like, and I can't grasp how it works. As an artist, it doesn't suit me. It's just that simple.

I like the breaking wave sim, that is cool. But I'd like to see a non-realtime one designed for realism. I thought the 2-way coupled rigid bodies was nice as well, but I don't get how they're jumping all over the place like that...The progress made with LBM is impressive, yes, but I still don't think that any of the stuff done with LBM compares in quality to its NSE counterpart.

=========

Anti-Distinctly--okay I see what you're saying.

RedBull
08-13-2007, 03:56 PM
If you say Glu3D uses LBM, then that would be another example of LBM results I do not like. Their examples do not look nearly as viscous as blender's, but I still feel that the behavior of most of their sims looks very unnatural.

No in fact Glu3D uses SPH (my mistake).

And in fact Glu3D and Realflow are both from the same creators and use fairly similar algorithms. Realflow sued 3DAliens once before and lost....
And most 3D companies like Blur/CafeFX prefer it to Realflow.... (but each to their own)

So not liking LBM because of Glu3D is a little silly, being that it's SPH...
So you would have to convince me of LBM being crappy with some examples. :) Like i said apart from Blender I'm not aware of any LBM simulations.

The program's power and complexity is not my point. My point is that having taken not a single calculus class in my life, I can understand how a basic NSE solver works. As a result, I am also able to understand (to some degree) most papers that are based on NSE solvers...Fedkiw's DSD paper, the viscoelasticity paper, the BFECC paper, the fluid control by direct wind field paper...

If I can get good results from the algorithm, then I wouldn't care as much about how it works. But I look at LBM--I can't get good results from it, I haven't seen any results from it which I like, and I can't grasp how it works. As an artist, it doesn't suit me. It's just that simple.

Fair enough too...

loki74
08-13-2007, 04:15 PM
No in fact Glu3D uses SPH (my mistake).

And in fact Glu3D and Realflow are both from the same creators and use fairly similar algorithms. Realflow sued 3DAliens once before and lost....
And most 3D companies like Blur/CafeFX prefer it to Realflow.... (but each to their own)

now that's interesting...

So not liking LBM because of Glu3D is a little silly, being that it's SPH...

well I guess I'll have to amend my opinion: I dislike SPH because I don't like what is see from Glu3D.:tongue:

So you would have to convince me of LBM being crappy with some examples. :) Like i said apart from Blender I'm not aware of any LBM simulations.

Exactly--Blender being the only example of LBM I can find, and me not liking Blender's results... essentially means I dislike (or at the very least, am extremely skeptical of) LBM.

RedBull
08-13-2007, 04:25 PM
well I guess I'll have to amend my opinion: I dislike SPH because I don't like what is see from Glu3D.:tongue:

LOL, Fair enough then..... I really have not played with Glu3D, I'm hoping Pwrapper and Glu3D comes to XSI soon as it's meant to coming soon.

Exactly--Blender being the only example of LBM I can find, and me not liking Blender's results... essentially means I dislike (or at the very least, am extremely skeptical of) LBM.

Yes, but I'm not so sure I would take one example of an LBM implementation, and claim it's crap, if i could see another one or two LBM simulations, i might tend to agree with you.

But i think NS is used far more because of it's ease of understanding (especially as a 2D Solver) and it's well known publicity from Maya and Stam. than of it's technical superiority. But as long as the calcs are fast and the results are good..... It's good enough for me.

loki74
08-14-2007, 10:05 AM
I really have not played with Glu3D,

Just for the record--neither have I. I'm basing my opinions just on their demonstration videos, so I may not be the best qualified critic.

Yes, but I'm not so sure I would take one example of an LBM implementation, and claim it's crap, if i could see another one or two LBM simulations, i might tend to agree with you.

But i think NS is used far more because of it's ease of understanding (especially as a 2D Solver) and it's well known publicity from Maya and Stam. than of it's technical superiority.

You've got a point. It's probably not fair to judge LBM having seen only one implementation. However, I don't think its any more fair to discount the comparative technical superiority of NSE having seen only one implementation of LBM...

But as long as the calcs are fast and the results are good..... It's good enough for me.

haha, I don't think there's anyone who could disagree with that!