Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (489)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (555)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  JOODE: Fluid Dynamics  (Read 4043 times)
0 Members and 1 Guest are viewing this topic.
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Posted 2006-03-30 11:42:59 »

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

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #1 - Posted 2006-03-30 14:37:13 »

it'll be real cool to have fluid dynamics in ODE Smiley

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 Smiley

:: JOODE :: Xith3d :: OdeJava ::
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #2 - Posted 2006-03-30 14:56:45 »

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

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #3 - Posted 2006-03-30 16:36:59 »

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

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #4 - Posted 2006-03-30 16:42:10 »

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/2*t*t + 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


Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #5 - Posted 2006-03-30 16:48:28 »

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.

:: JOODE :: Xith3d :: OdeJava ::
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #6 - Posted 2006-03-30 17:09:57 »

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

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

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #7 - Posted 2006-03-30 18:01:04 »

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 Smiley

:: JOODE :: Xith3d :: OdeJava ::
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #8 - Posted 2006-03-30 18:25:27 »

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

:: JOODE :: Xith3d :: OdeJava ::
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #9 - Posted 2006-03-30 23:35:00 »

Whats the name of the second equation?


Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #10 - Posted 2006-03-31 09:42:11 »

It's called Stokes' Law.

:: JOODE :: Xith3d :: OdeJava ::
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #11 - Posted 2006-03-31 10:20:32 »

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

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline hdietrich

Junior Member




Harald Dietrich


« Reply #12 - Posted 2006-03-31 14:57:54 »

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 = m*g (m: mass of the body, g: gravitation)
FL = d*V*g (d: density of the fluid, V: volumn of the body, g: gravitation)
FR = 0.5*d*c*A*v2 (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 = 6*PI*r*n*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   Grin
I hope with this information I can contribute something to your discussion (even if I am no specialist in fluid dynamics computations)  Wink

Harald
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #13 - Posted 2006-03-31 21:21:57 »

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

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)

:: JOODE :: Xith3d :: OdeJava ::
Offline hdietrich

Junior Member




Harald Dietrich


« Reply #14 - Posted 2006-04-01 09:02:04 »

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)
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #15 - Posted 2006-04-01 09:41:30 »

Ok - good - seems now, as if we've got now all the physics. Now we've only have to integrate it into JOODE Smiley
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 Grin

:: JOODE :: Xith3d :: OdeJava ::
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #16 - Posted 2006-04-01 11:03:08 »

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

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline hdietrich

Junior Member




Harald Dietrich


« Reply #17 - Posted 2006-04-01 15:23:22 »

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

Senior Member




money is the worst drug- we should not let it rule


« Reply #18 - Posted 2006-04-01 15:51:56 »

ok convinced Wink

:: JOODE :: Xith3d :: OdeJava ::
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #19 - Posted 2006-04-01 16:07:33 »

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

:: JOODE :: Xith3d :: OdeJava ::
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #20 - Posted 2006-04-01 19:33:33 »

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

Senior Member




Go Go Gadget Arms


« Reply #21 - Posted 2006-04-02 00:28:48 »

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.

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

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #22 - Posted 2006-04-02 09:18:38 »

ok hmm thats the way then

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #23 - Posted 2006-04-02 15:20:58 »

Quote
Keep it as simple as possible.
bahahaha

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

Senior Member




Go Go Gadget Arms


« Reply #24 - Posted 2006-04-03 00:08:04 »

Interceptor pattern being a bunch of interfaces for "beforeX" and "afterX" that get called before a certain thing happens?

Or am I thinking of something else?

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #25 - Posted 2006-04-04 18:29:46 »

ya thats exactly it. Put one before the step world method, maybe step body, create body,  create joint, destroy joint etc.

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

Junior Member




Harald Dietrich


« Reply #26 - Posted 2006-04-06 09:20:10 »

What about having something general like a force field, which will be applied on bodies passing this field?
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #27 - Posted 2006-04-08 14:55:13 »

Yeah, implementing potential feilds is a great idea I have had in my mind for a while. Simple and useful (so you can have galactical scale gravity etc.)

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (10 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (27 views)
2014-08-22 19:31:30

atombrot (40 views)
2014-08-19 09:29:53

Tekkerue (38 views)
2014-08-16 06:45:27

Tekkerue (34 views)
2014-08-16 06:22:17

Tekkerue (24 views)
2014-08-16 06:20:21

Tekkerue (34 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (47 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!