JOODE: Fluid Dynamics

Game Mechanics
#1

Hi all,
Im confident we can get fluid dynamics in JOODE (although I havent see the architecture for JOODE). The grid based approach would work the best, since its basically a velocity field in a big 3D grid, im assuming you can integrate momentum in some way to achieve dr/dt rather than going down the u = dr/dt approach since that doesn’t take into account mass.

Or does the LCP integrator deal with momentum anyway? Im not sure…

If anyone is interested, let me know, i’ll get something working, but I can’t do it on my own…

DP

#2

it’ll be real cool to have fluid dynamics in ODE :slight_smile:

but unfortunatley I’ve nearly no knowledge about that LCP stuff, so I can’t tell you how hard it will be to add it to JOODE.

I only know, that there were no fluid dynamics in ODEJava. But that shouldn’t keep us from trying, right?

Arne

EDIT: Your cloud stuff also sounds very interesting :slight_smile:

#3

the only real problem is that the grid based approach (what I think is the better fit for JOODE) stores the velocity at each field, not a force. Thus if you put a tennis ball, or a ball of lead, they both travel at the same speed which is a bit unrealistic.

The only way I can think of solving this is to cheat and assume that the velocity field is actually a momentum field, divide by the mass of the object to obtain the velocity.

Or, if anybody knows how to, multiply the velocity field by the mass to obtain the momentum and somehow integrate the momentum directly to position without going through the velocity = dPos/dt method.

DP

#4

I see the overall picture but I’m not sure I entirely understand your specific problem. First of all you may want to take a look at Joode’s source code…

#5

JOODE’s source code is irrelevant at the moment…

The problem is solving momentum straight to position.

The naive way of solving numerically from force is this:

a = F/m
a = dv/dt

Then doubly integrating acceleration results in:

r = a/2tt + v0t + r0

whereby v0 = pervious velocity, and r0 = previous position

Problem is that I already know the velocity, but that velocity is for a mass of, thus the momentum is different…

DP

#6

mmh I still don’t really understand you (where do you want to put the balls?)

and one thing, which isn’t clear to me: are you also able to handle to collisions of the fluid with rigid bodies? (you seem to be, becasue else that comment with the ball would be even an greater mystery to me :wink: )

mmh lets remember how JOODE manages collisions…

  • first it uses a space to detect collisions
  • then it calculates penetration depth and Contacts
  • and then applys forces to the bodies

mmh we could delegate the collision-result-management to the geoms themselves, this would ease step 3 a bit I guess - dunno how this’ll work.
then we would only have to deal with the fluid getting updated regularely (mmh a collsion with itself…)

BTW (If also collisions with rigid bodies are allowed): I don’t think there’s a different effect, if a lead ball hits the surface of the fluid or a tennis ball. It’s only the ball, that get’s slowed differently - which ofcourse shows differen’t results in the next frame… aehm - tennisballs swim on water, don’t they? - This gets really tricky.

#7

sigh

Imagine a 3D grid, each cell has a vector representing velocity and this velocity changes according to the naiver-stoke equations and all is great. The fluid looks good…etc. Now you drop a tennis ball in the velocity field, the only information that is available to move the ball is the velocities in the grids that the ball is colliding with. Now say you put a lead ball (the lead ball is still less dense than water, this is computer games afterall, but denser than the tennis ball) on the velocity field, obviously, the lead ball is heavier and thus the velocity wont affect it much, so someway, somehow, we need to add mass into the equation.

Unless im mistaken and because it a fluid they both move at the same speed :slight_smile:

viscosity is a different problem, that requires densities. Also, balls on the surface is a completely differnent problem too…

DP

#8

I one thing I 100% sure of, we’ll also need the surface! mmh I did calculate once the airfriction of a train in my physics class. Let’s think - ahh yes and we’ll also need a paramater describing how easily fluid can flow around it. I believe that parameter is close to impossible to calculate (air dynamics I believe are still a very complicated physical research area).
But we could of course let the user enter these values (e.g like it’s done with the moment of inertia matrices)

I’ll look, if I can find the formula :slight_smile:

#9

Ok - here it is:

F: Force of the friction
A: Area confronting the fluid direction
D: the fluids density
C: The friction-coefficient (only dependend on the shape and the direction the fluid is moving around it)
V: Speed

F=0.5ADCV^2

EDIT: mmh seems this Formula only really works for gases.
For fluids there is:

r: characteristic measurement of the body (dunno what exactly)
a: some factor close to 1 (dunno what)
n: viscosity of the fluid

F=-6PIanr*V

In my physics book here it says, that both types of friction are always present, but in fluids the second is much larger than the first, so the first can be left away and vice versa for gases. Ohh yes - for very high speeds the first will never the less gain more importance (V^2 instead of only V)

#10

Whats the name of the second equation?

#11

It’s called Stokes’ Law.

#12

I could only find:

F = 6PI * radius * fluid viscosity * velocity

and that accounts for the movement of a sphere with r radius in the fluid. Maybe the mass really dont have an effect and its just the surface area?

* darkprophet goes of to try it at his pond

DP

#13

You have a whole bunch of forces that affect a body in a fluid:

  • FG: gravitational force (Newtons law)
  • FL: static lifting force
  • FR: resistibility
  • FF: frictional force (Stokes law)

Furthermore you must make some assumptions:

  • laminar flow
  • the body will be all handled like spheres (drag coefficient 0,45)
  • dynamic lifting forces will not be taken into consideration

If you take into consideration that there should be a balance of forces you can solve the equation to determine the movement of the body.

FG = mg (m: mass of the body, g: gravitation)
FL = dVg (d: density of the fluid, V: volumn of the body, g: gravitation)
FR = 0.5dcAv2 (d: density of the fluid, c: drag coefficient = 0.45, A: force facing area of the body = 2 * PI * r, v: velocity of the fluid)
FF = 6PIrn*v (r: “radius” of the body, n: viscosity (e.g. 1.0 for water), v: velocity of the body)

Directions the forces are acting:

FG down
FL up
FR direction of fluid movement
FF up

Calculation I leave up to you ;D
I hope with this information I can contribute something to your discussion (even if I am no specialist in fluid dynamics computations) :wink:

Harald

#14

mmh

gravitation already existed in ODE (so it should also be in JOODE - dunno, if it’s already there - yes it is! but I don’t know, if it works)

resitibility (FR) is my first formula, Stokes Law seems also be pretty the same - mine only seems to be a bit more general.

Yeah that static lifting force is also important - if we make it also apply while it’s in the fluid, we’ll also be able to have swimmimg objects :slight_smile: mmh we’ll only have to tricks a bit around, if it’s only partially in the water.

[quote]Furthermore you must make some assumptions:

* laminar flow
* the body will be all handled like spheres (drag coefficient 0,45)
* dynamic lifting forces will not be taken into consideration

[/quote]
non laminar flow is much to complex (I think) - so we’ll simply ignore it.

it’s only that Stokes Law that requires the body to be a sphere, but because the more general one (from my physics book) doesn’t require the body to be a sphere (It didn’t mention anything like that in there) I think, we simply can use it. They weren’t that different, were they? We’ll only have to find an appropriate radius for non Spheres (another method in Geom will do, I think).

what do you mean by dynamic lifting forces?

I think FR and FF will be both in the direction of fluid movement (or against the movement of the body, if the body moves), or have I missed something? (I’m wondering, because you said differently, hdietrich)

#15

You are right, I made a mistake. FF is acting in the opposite direction of body movement.

FR is excactly the same you described before in your formular besides Stokes law.

The assumption that the body is a sphere just makes it easier to calculate the area for resistance force (and of course its a restriction made in Stokes law). I think it’s too complex to calculate the area facing the fluid movement for abitrary bodies. So an approximation of the body to be a sphere is a valid approach.

Dynamic lifting forces are for example forces action on the wings of a plane or the sail of a sailing boat. A precise definition of the lifting foces can be found at Wiki http://de.wikipedia.org/wiki/Auftriebskraft (sorry, only german Wiki has an appropriate definition, the english page http://en.wikipedia.org/wiki/Lift_%28force%29 is describing only the special case of a plane)

#16

Ok - good - seems now, as if we’ve got now all the physics. Now we’ve only have to integrate it into JOODE :slight_smile:
I bet it’s easier said than done :wink:

Ok I’ve thought about it and I think the best way is to create a new geom type (we could call it Environment) which will not only handle one fluid, but all fluids, gases and also solids for Hills. That Geom will span the entire world (we could use an OctTree to get more precision, where we need it). Other Geoms should be able to influence and get influenced by fluid movement - but the spreading of the fluid should not be restricted by the geoms, but only by the other stuff in that Geom (e.g. the Hills or other fluids …).
Ok - it would be nice, if it were possible to build a wall that stops fluid movement (e.g. for damms), but I think it’ll be very hard.
This Environment-Geom should be able to get directly linked to the World, so it can get updated every frame.

We will also have to think about, how we will enable renderers to render it.
For the rendering, I think we’ll have to distinguish between two things:

  • The Surface
  • The Volume

For gases we’ll probably only have to render the volume (darkprophet seems to have found a very nice way for doing this).
For solids and fluids also the surface will be important, too, but there should be also a way - darkprophet also seems to have found a nice way for that, but I don’t know if it will work with the approach I now proposed.

PS: I think we could deal with solids in a way, that solids are like very dense fluids with a big friction coefficient (so they don’t start flowing around) - Ok I don’t know how darkprophets algorithm works, but it’ll cool if this all could work ;D

#17

All current real time fluid solvers cannot do fluid-wall collisions as that requires compressable fluids; thats basically where each cell in the fluid does not have the same fluid density (very hard to solve). Another restriction on the fluid solver is that the fluid is homogeneous, meaning the viscosity is the same for the entire grid; that rules out your plan arne for the Environment geom.

We also have to take into account boundry conditions, so far, ive made an FFT based fluid solver, that means the bounds wrap around (like a torus), but I can make another implementation of this no problem. Im thinking the boundry cells should all be zero no matter what, but there are other alternatives we’ll have to experiment with.

The application of the forces can be a post-process effect, so during a collision with the fluid primitive, forces get calculated then the LCP can solve that, maybe even use a Gauss relaxation method to ensure system stability (im thinking where the velocity field is pointing towards a wall and an object is stuck between), but we’ll come to that when it is a problem…

As for rendering, your thinking too literal, the actual simulation is very abstract and volume rendering is not needed as the fluid is just meant to drive the physical simulation; Its up to the game to render the fluid (if it uses it) in a way it sees fit; ofcourse when I say fluid, i dont just mean liquids, it can be gases/wind…etc. Also, the fluid solver has nothing to do with the surface; air mixing is a completly different problem thats outside the domain of this problem.

Another problem we have (heh, as if we dont have enough!) is if the object lies in a number of velocity grids (say 2x2); the first coloumn’s velocity is much much higher than the second coloumn, an object placed in that field will start to spin, but thats not the case with the simulation at the moment. This can be solved if JOODE has a point-primtive collision detection and response method; I then need to create a completly different fluid solved based on Smoothed Particle Hydrodynamics and move those and collide with them. I think thats how Novodex does it

Also, the solid fluid stuff is not a good solution, there are tons and tons and tons of other ways to generate terrain (ive done most of them!); using fluid to do that is just too much (takes too long, complex to create and wont give stunning results compared to all the other methods).

The fluid dynamics domain is so big, I had to restrict the problem domain alot to get real-time performance.

DP

#18

Keep it as simple as possible. I think it would be interesting enough to have objects reacting on fluid movement without taking too much constraints into consideration. Additional functionality could be added later on…

#19

ok convinced :wink:

#20

yep that would only work, if the general approach with different fluids would work.

[quote]As for rendering, your thinking too literal, the actual simulation is very abstract and volume rendering is not needed as the fluid is just meant to drive the physical simulation; Its up to the game to render the fluid (if it uses it) in a way it sees fit; ofcourse when I say fluid, i dont just mean liquids, it can be gases/wind…etc. Also, the fluid solver has nothing to do with the surface; air mixing is a completly different problem thats outside the domain of this problem.
[/quote]
yeah but the renderer will have to be able to access the data for rendering and we’ll have to support that in JOODE.