Does *anyone* have knowledge about calculating drag-coefficients? The only info I've found so far points at having to digest and understand the entire complexities of Navier-Stokes differential equations, which look pretty horrific.

...even a pointer to any "simple introduction to Navier-Stokes" would be immensely helpful.

Sadly, 99% of web resources say "look it up in a book" - which generally seems to mean "I'm too damn stupid/lazy to understand it myself, so why should I bother learning just to explain it to you?"

(PS, in case you don't know, the drag coefficient is uniquely different for every different shape. Hence, "look it up" only works if every shape you want to create is listed somewhere in a book. Unsuprisingly, very few shapes appear to be listed (compared to all possible shapes!))

Correct me if I'm wrong, but aren't most drag calculations pretty computationally intensive? Most flight sims use pre-calculated windtunnel models to simulate flight. The only game I'm aware of that ever tried real-time flight dynamics was a flight sim from LookingGlass called "Flight Unlimited". They *claimed* that if you plugged in the 3D model for a lawn chair, it would fly like a lawn chair and not like a Mig-22. They might have (probably) exagerated their accomplishment, but there you go.

I would expect so, given that it seems the closest mathematical estimations we have seem to be based on diff eqs (Navier-Stokes) - which are almost always computationally intensive to work with.

But unless it takes days to calculate the drag for a single model on a 1ghz PC, I don't see a problem here...

Quote

The only game I'm aware of that ever tried real-time flight dynamics was a flight sim from LookingGlass called "Flight Unlimited". They *claimed* that if you plugged in the 3D model for a lawn chair, it would fly like a lawn chair and not like a Mig-22. They might have (probably) exagerated their accomplishment, but there you go.

That doesn't sound like it has anything to do with "real-time flight dynamics", just another pre-calculated drag-coefficient; which is precisely what I need to do.

Do you have any references for details on flight-unlimited? e.g. where did you find the claim about the chair?

Thanks a lot; the links have already provided some additional search terms for me to shove into Google .

I love the one with the quote (LGT = Looking Glass Technologies):

"If LGT can really do the calculations described in (2) they are wasting their time with mere PC games. They have achieved in a few years what has not been done in decades by thousands of people working at Universities, Government Departments, and private organizations (such as Boeing). A similar achievement in medicine might have the headline 'doctor performs open heart surgery with nothing but his bare hands and two band-aid strips'."

I have experience running fluid dynamics simulations based on the Navier-Stokes equations.

The key question is: how much resolution do you need? Do you want to simulate the turbulent motion in the logarithmic sublayer under different Richardson number (stability) regimes or do you just want to make a lumpy, rough object like a lounge chair fly differently than a streamlined airfoil?

You can use a very simple parameterization (equation) to increase your drag coefficient as the surface roughness of an object increases. In flow over mountains, for example, something simple like this is used:

Cd = .001 + .006*z/(1+z)

where z is the surface elevation in km. This accounts for the increased form drag/surface roughness as you ascend the mountain. (This is a cloud's point of view. In your case, the object will be moving instead of the air, unless you want winds.)

I have experience running fluid dynamics simulations based on the Navier-Stokes equations.

The key question is: how much resolution do you need? Do you want to simulate the turbulent motion in the logarithmic sublayer under different Richardson number (stability) regimes or do you just want to make a lumpy, rough object like a lounge chair fly differently than a streamlined airfoil?

Quote

Requirements of accuracy:

- everything is approximately correct, according to the rough expectations of a human observer. If I take a sphere, and add big spikes, it should probably have higher drag. - ...EXCEPT: special cases are allowed. If there are ways to "fool" the algorithm and they aren't TOO extreme, that's OK. I don't mind people discovering equivalents of the golf ball - where an action that would appear to make the drag increase actually does the opposite. They just mustn't be too unbalancing on gameplay. - ...but it just has to fool most people, it doesn't need to honestly reflect reality.

Quote

You can use a very simple parameterization (equation) to increase your drag coefficient as the surface roughness of an object increases.

My current plan was to decide if the body was most similar in shape to: sphere, hemisphere, plane, cone, parabolloid, and estimate the Cd based on the known figures for those shapes. Then add on an estimate of the extent to which it deforms from one of those shapes.

Repeat for every convex section of the object (I'm expecting people will often make a body out of several convex sections, joined by braces).

Or, alternatively, ignore Reynolds and Cd, and estimate the fundamental drag forces individualy, and then interpolate with a secret equation of my own between laminar and turbulent flow (and making most CFD experts break down and cry in the process, because it's so utterly inaccurate). I'm only considering this because I can actually estimate some of the fundamental causes of Drag rather well - and perhaps if I get those right, I can just tweak an estimation equation for the bits I can't do.

One project uses a simulated wind tunnel to test their physics models. Stick the model in and run the tests to compare with real world results. Not sure how hard it is to code, but it may be easier to simulate wind tunnel tests, rather than trying to "guestimate" a Cd

There are only 10 types of people, those who understand binary and those who don't!

One project uses a simulated wind tunnel to test their physics models. Stick the model in and run the tests to compare with real world results. Not sure how hard it is to code, but it may be easier to simulate wind tunnel tests, rather than trying to "guestimate" a Cd

I'm not quite sure I understand you: Are you saying that you put a virtual object in a virtual wind-tunnel? How does that give you any information about how it "compare with real world results"?

I'm having trouble thinking of useful calculations involving a single object that DON'T look like a wind tunnel - wind-tunnels are, after all, the state-of-the-art in car and airplane design - presumably because they provide ALL the relevant data about that object? I.e. I can't see why "simulating a wind tunnel" would be any different from "simulating fluid dynamic forces on an arbitrary object".

From my understanding, if you can simulate a wind-tunnel, you've solved the problem that CFD researchers have been trying to figure out for decades - c.f. the "doctor performs open heart surgery with nothing but his bare hands and two band-aid strips" quote.

Thinking about it they have a physics model which they use to simulate flight and vehicle dynamics. I'm sure their "wind tunnel" is their physics model, "hooked up" to some measuring devices, so they can put their virtual model in their physics model and run tests to see what forces are generated.

It is quite a detailed model, but is not the same type of thing you are doing. They are taking their modelling information along with their physics model and verifying it versus real world data to check for errors. Not the same beast at all.

There are only 10 types of people, those who understand binary and those who don't!

Just a few points to hopefully add some additional value to this topic.

The drag coefficient is dependent not only on shape but also on a dimensionless number called the Reynolds number (among others) - the Reynolds number is a function of the fluid properties, velocity and characteristic dimension of the object.

For the majority of cases there are two main contributions to the drag of an object pressure drag and viscous drag. Viscous drag and fluid compressible effects only starts to become important at higher speeds, usually over Mach 0.3 (about the top speed of an F1 car on current race circuits), however for an efficient aerodynamic design this can rise to about 0.5-0.6.

Two computational approaches have developed in the field of Computational Fluid Dynamics (CFD) for solving these types of problems, the first, appropriate for inviscid problems is the Panel Method (more formally known as the Boundary Element Method, BEM) which solves a reduced form of the governing equations called the Euler Equations, and the second for viscous problems which solves the full Navier-Stokes equations.

Which approach you should "ideally" use is therefore dependent on what the problem is. The inviscid panel method is used by most Auto/F1 teams for the bulk of their aerodynamic calculations, however, viscous calculations are perfomed in conjunction with inviscid calcs in the aerospace industry.

However, for game development, solving the Navier-Stokes equations in game-time even on the fastest of PC's available is not really possible as even the very simplest of 3D problems consisting of several hundred calculations points can take a noticeable amount of time to solve, if infact a solution is obtained. A typical industrial CFD problem would consist of several hundred thousand calculation points for accurate results. Also, baring in mind that the drag AND drag coefficient will change depending on what the object is currently doing and therefore will have to be updated frequently. Thats assuming the average game developer can code what is essentially one of the most complex software applications on the planet.

Performing game-time calculations using the Panel method would be feasible since the computational cost of such calculations is considerably reduced due to the simpler form of the equations used and the fact that the method only requires a 2D surface description of the object (your polygon model for example) as opposed to a 3D computational domain for the full equations. Again you just have to code it!

Just a few points to hopefully add some additional value to this topic.

The drag coefficient is dependent not only on shape but also on a dimensionless number called the Reynolds number (among others) - the Reynolds number is a function of the fluid properties, velocity and characteristic dimension of the object.

For the majority of cases there are two main contributions to the drag of an object pressure drag and viscous drag.

The project I'm doing this for has had to go on hold for a while, due to time constraints, so I'm a bit rusty right now. In the particular case I was looking at, ISTR that wave-drag was often dominant (I was simulating shapes moving at a boundary between radically different liquids, of which the most obvious example is probably sailing). Is that one of the two you name, or is it a third form of drag?

It would be great if you could also give a layman's definition of what problems are considered "inviscid"?

Inviscid flows are where the effects of fluid viscosity are negligible, as opposed to viscous flows where the effects of viscosity are significant.

The Reynolds number gives an indication as to the flow regime you are operating in i.e. if the flow is laminar or turbulent. For an aerofoild section the transition from laminar to turbulent flow occurs at roughly 0.5E6 and for a sphere at approximately 50.

Inviscid flows are where the effects of fluid viscosity are negligible, as opposed to viscous flows where the effects of viscosity are significant.

Sorry, I assumed that much would be clear, and I thought it might help to have some idea of when/where viscosity tends to become significant. Since you stated that the choice of algorithm depended largely on this characteristic...

When I get back to this project, I'll post some info on how much fudging I was able to get away with, and typical processing times. Fortunately for me (as I stated earlier) offline calculation is fine, as long as it doesn't take too long. For anyone familiar with game development, I'm happy to have something akin to a BSP offline level-compilation step: over the years it's become clear that players are happy with 0.5-25 hours for that kind of process (assuming the time taken is proportional to complexity, and typical times are less than 5 hours).

A characteristic length would be the wing chord length, or for a sphere the diameter etc

As for your estimates on calculation times, to give you some kind of order of magnitude of the time it would take to solve using the panel method for inviscid flows on a typical home pc, I would be looking at a few minutes rather than hours for a model consisting of 200-300 polygons.

I also neglected to mention that you can also use the panel method for flows where viscous effects are important by including what is known as boundary layer model. The boundary layer is the region next to the surface where the viscous shearing forces occur. This only adds slightly to the complexity and cost of the calculation without having to resort to full viscous calculations.

For hydrodynamic flows similar approaches to the panel method are frequently used in conjunction with boundary layer and wake models. to model the drag on the hull and bow wave pattern generated on the water surface.

For hydrodynamic flows similar approaches to the panel method are frequently used in conjunction with boundary layer and wake models. to model the drag on the hull and bow wave pattern generated on the water surface.

Yup. that's one of the two directions I've been pursuing; unfortunately, I've only been able to find one (!) page on the web describing this approach, by an author of yacht-design software, and only describing a "reasonably good" wake model. Perhaps now that I know the viscid/inviscid terms, I'll be able to find more.

<shows ignorance>I'd actually assumed "viscid flow" simply meant "flow in a viscous liquid", and hadn't realised that this would have any effect on laminar as opposed to turbulent flow.</shwos ignorance> Thanks.

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