Jump to content
  • Advertisement
Sign in to follow this  
tasseloff

dynamic of splashing fluids

This topic is 5106 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, i am currently working on a water simulation based on Yann's lectures http://www.andyc.org/lecture/viewlog.php?log=Realistic%20Water%20Rendering,%20by%20Yann%20L and the article http://www.cs.berkeley.edu/~job/Papers/obrien-1995-DSS.pdf if I use the water solver Yann created (the link is in his lecture) it seems to work perfectly, however i wanted to create it myself from scratch so i based myself on the article by Obrien (which is the one Yann based himself on), everything seems to make sense, however, in the article they use this summation to update the volues: http://pallots.kicks-ass.net/planarreflect/summation.jpg and in Yann's solver he seems to just make a summation of all the pipes of the column, i don't understand where Yann's calculation comes from...but when i use them it seems to work, however if i use the summation in the article my simulation blows up :/ anyone build a simulation from that article??? maybe i just mis-interpreted the summation in the article but in my mind it just takes the flow in a pipes at time dT and t+dt, while Yann doesn't even take the last dt into account... this is a somewhat complicated post to understand but if you've coded the simulation based on that article im sure you'll see what i mean... any help would be greatly appreciated... tks

Share this post


Link to post
Share on other sites
Advertisement
hmm ok im gonna try to make my question a bit clearer.
In his lecture, Yann says to calculate the volume like this :
DeltaVolume(i,j) = dt * SUM(grid)(Flow(i,j -> k,l)(t+dt))

and in his small example program he does it by doing this :

*cv += TIMESTEP * (p_HPipes[a] - p_HPipes[a+1] + p_VPipes - p_VPipes[b+p_xres] + p_LPipes[a] - p_LPipes[a+xsp+1] + p_RPipes[a+1] - p_RPipes[a+xsp]);

where the pipes array contain the Flow(i,j-k,l)

however in the article, it says to calulate it with this summation:
http://pallots.kicks-ass.net/planarreflect/summation.jpg

which seems to need the last and current pipe Flow (Qij->kl)
and divides it by 2....i don't see no divisions in the code i pasted above......i just can't see where it comes from :/

Share this post


Link to post
Share on other sites
im gonna bump this if you don't mind, right now im still using Yann's technique but i really wanna know how he came to it based on the article...:|

Share this post


Link to post
Share on other sites
its not because Yann uses the absolute values and the example uses the delta and accumulates elsewhere? (or the other way around).

Share this post


Link to post
Share on other sites
hmmm im really not sure, cause the thing is in the article, they use the flow at "t" and "delta t" while in his example he doesn't even use the the flow at "t" only the one at "delta t" so im really not sure where he takes it from....:/

Share this post


Link to post
Share on other sites
OK, the difference lies in the integrator. The equations that update the flow rate Q(t+dt, ij->kl) and the volume dV(ij) are two combined continuous differential equations. The flow is updated by the acceleration over dt, and the volume is updated by the flow over dt. Since we can't use a continuous differential time dt in our simulator (a timestep would take an infinite amount of time to update :), we have to integrate the equations over a discrete timestep delta_t.

Now, I used a simple Euler integrator for this task. I did this for two reasons: first, it is easier to understand. In that lecture, both simplicity and time were of the essence, so I wouldn't dwelve into the depths of ODE solvers. An Euler integrator is basically the simplest way to integrate a continuous differential equation over a discrete timestep.

For the volume equation, imagine this situation: you have a plexiglas cylinder with a certain amount of water. You can measure this amount, and it will stay the same over any amount of time, as long as no water is added or removed. Connected to this cyclinder are several pipes that can either pump water into the cylinder, or remove water. They do this at a certain flow rate over time, and you can measure the rate for each pipe individually.

So, let's assume that the flow rate - even if different for every pipe - is constant over time. If you wanted to know the amount of water in the cylinder at a certain point in time, all you need to do is sum the flow of all pipes over the required time span. You then add this total flow to the original volume of water in the cylinder, and voilà, done. Unfortunately, the assumption of constant flow rate doesn't hold in our scenario. In fact, the flow rate changes continuously, and that's what makes the whole thing a differential equation. Since we can't solve the flow equation at differential time (ie. infinitesimal time intervals), we have to discretize the solution. And we need an integrator for that.

And that's were personal preference, accuracy requirements and stability issues come into play, ie. welcome to the messy part ;) Think of these two equations as pluggable modules: you can basically plug in any type of integrator, as long as the two important quantities are updated over the given time step. But they will significantly differ in accuracy, stability, complexity and performance. As I mentioned earlier, I used the most simple one there is: an Euler integrator. The advantages of this method are the very fast execution times, and the intuitive structure, which is easy to understand and explain. The main drawback of Euler is that it evaluates the derivative only at a single point within the time interval, which leaves us with a rather large error term. This can lead to serious instability, especially at larger timesteps.

O'brien used a different integrator in his paper. I'm not entirely sure what he was trying to do, frankly. The first equation uses a standard Euler approach over timestep delta_t. The second one seems to use a somewhat stripped down version of Runge-Kutta order 2, but not really either. RK2 would require to evaluate both Qdt and Vdt at the midpoint, in order to estimate the derivative using two points (one at delta_t/2). This eliminates the second order error term, and makes the equations more stable. But he doesn't do that, since there is no evaluation at dt/2. A little strange.

Anyway, back to your case. I would suggest staying with Euler, as long as it works. It's easy, fast and more or less stable. From a signal processing poitn of view, O'briens version actually acts as a low pass filter (maybe he tried to reduce high frequency noise that way ?). But in my epxerience, it was less stable than Euler. If you need more stability and don't mind added complexity, I would suggest Runge-Kutta order 4 (RK4). This is a pretty robust integrator, that won't blow up so easily, even at larger time intervals and lots of simultaneous activity on the water surface. Keep in mind that it will take significantly more performance, though. You could even go higher order, but that would kill off anything realtime.

Using implicit integration ala Verlet might be another option. Although some of those integrators might require substancial changes to the structure of the algorithm, due to the way they work (implicit derivation of the acceleration and flow rate using two points on the interval, no more explicit integration as with Euler or RK). They are usually very stable.

It's basically up to you. Consider all your requirements, and select an appropriate integration method based on these assertions.

Edit: damnit, I almost forgot my password... OK, this one was it, he ;)

Share this post


Link to post
Share on other sites
ahhhh ok....it all makes more sense now, i had read a bit about the euleur integrator but wasn't sure how it was used in the article

its all a lot more clearer :)
tks a lot!

on a sidenote...it wouldn't be possible with a NSE system to add volume to the water eh? like if im simulating rain falling on a lake, it wouldn't be possible to add the volume of each drop to the global volume?
it'd be very interesting to do but i guess maybe i'd have to go in full 3d simulation with particles for that :/

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!