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...

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.

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 )

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.

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

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

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)

F: Force of the frictionA: Area confronting the fluid directionD: the fluids densityC: The friction-coefficient (only dependend on the shape and the direction the fluid is moving around it)V: Speed

F=0.5*A*D*C*V^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=-6*PI*a*n*r*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)

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 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

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)

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.

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

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

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.

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...

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).

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.

yeah but the renderer will have to be able to access the data for rendering and we'll have to support that in JOODE.

Just a note: as stated above, the two friction formulae correspond to laminar (friction propertional to velocity) and turbulent flow (friction proportional to square of velocity), respectively. Determining which kind of flow is present can be done by means of the Reynolds number, http://en.wikipedia.org/wiki/Reynolds_number . Of course there is a transition between the two kinds of flow where neither description is correct, but it could perhaps prove useful.

yeah but the renderer will have to be able to access the data for rendering and we'll have to support that in JOODE.

What data? Its not as if we have a heightmap that represents the surface and the user needs to get that, what we have a 3D grid that only contains data needed for the movement and physical simulation ofother objects. If the user put a bunch of particles in the velocity field, then they can render those particles as if they were just any object.

Speaking of particles, JOODE really needs a point primitive, its useful for alot of things

Jesus Christ guys. You guys are crazy. I wish you all the best of luck, um, but what I would say if you want to intergrate fluid dynamics then you shoul make sure you invest in the architecture first.I have harped on allready about a interceptor pattern for objects that allows behaviours to clip on. (and also get destroyed when the object has its detroy() method called). any fluid dynamics should be implemented as one of these clip on behaviours.

Gravity is implemented. It works fine, but I don't like the way it is just a hardcoded feature (Should be a clip in).

Right .... gotta write my robot report..... speak to you all soon

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org