Lift and drag of arbitrary polyhedron in arbitrary direction

Started by
9 comments, last by John Schultz 17 years, 11 months ago
How do I calculate the lift and drag (or total combined force) of a polyhedron moving through the air in an arbitrary direction? Can this be represented as a 3x3 matrix used to transform the relative air velocity? Can this also be done for motion in other fluids, gas and liquid? The intention is to make a very simple simulator. No turbulance, cavitation, etc is necessary.
Two things are infinite: the universe and human stupidity; and Im not sure about the universe. -- Albert Einstein
Advertisement
This is the method for calculating lift/drag on wings:
http://www.aeromech.usyd.edu.au/aero/perf/perf_ac.html
also, here:
http://raphael.mit.edu/Java/

While even that isn't trivial, it's just a very special case.

For a generaly polyhedron, you'll probably need to build a 3D fluid simulator, and establish your properties from running the simulation. This would probably be easier, than trying to calculate everything analytically. All these methods are general, so you can apply them to any liquid. Look here: http://en.wikipedia.org/wiki/Computational_fluid_dynamics for overview.

You could also try an approximation, by making cross-section slices of your object, and applying simpler methods on them, then merging them to get final values.

Depending on how much accuracy you're looking for, it can range from reasonable to extremly complex.

Also, "arbitrary" is too general. In many cases, models are broken down into simpler shapes, which are considerably easier and faster to evaluate, or are even to some extent approximated. Even NASA,airplane/car manufacturers have trouble building virtual wind tunnels and still use real things.
After further thought about my problem, I realized a 3x3 matrix would not be suitable.

Quote:This is the method for calculating lift/drag on wings

Unfortunately, because of the nature of my program, it wont know which objects are "wings". In fact, an object may not even have been created with the intention of being flight worthy and my program will also not know which objects are meant to fly.

A little more on the nature of the problem:

An object to be simulated will not be a single rigid entity, but likely multiple polyhedrons connected by constraints. Therefore each polyhedron must have aerodynamic forces applied to it. I am not concerned with the air flow around one object effecting airflow around other objects. Basically, each object will have the dynamics applied to it as if it was independent. Once drag and lift are calculated for each polyhedron the forces will be applied to the rigid body simulator.

I am thinking that I will do CFD (if my intellect permits) and store results of various orientations/velocities as a table. Also, due to the nature of my program, these tables would have to updated whenever the user changes the polyhedrons before simulation. Would this create a significant period of time that the user is waiting for the simulations data to be prepared?
Two things are infinite: the universe and human stupidity; and Im not sure about the universe. -- Albert Einstein
See my links and Steve Broumley's references in your previous thread.

My first flight sims circa 1989 used a rigid body with FluidSamples (see the links) placed on key points of the rigid body. The system was not a flight simulator per se: the rigid body properties combined with the FluidSamples interacting with fluid (air/water) generated highly realistic flight behavior. Austin Meyer's X-Plane uses the same concept (so called "blade element theory") (while I had not heard of this technique in 1989, I spoke with a Boeing engineer who was well aware of this technique many years before). My (Amiga/PC) implementations were pretty simple, fast, and stable (used 32/64 bit fixed point, ran at 30Hz (486, 680x0)). On modern PC's with floating-point support, the motion is even more accurate (and the floating point code runs faster than fixed point).

By placing FluidSamples on each triangle of a polyhedron (scale values from triangle area, etc.), you can make arbitrary objects "fly" or "float" (or not fly if they are inherently unstable). For example, if you model a dart using these techniques, and "throw/launch" the dart backwards, it will automatically and realistically turn around and wobble until stable (just like a real dart thrown backwards).

Modeling the objects with connected-by-constraint elements will work, but will be expensive to compute (not a problem if only one vehicle, may be a problem with many vehicles). It would be more efficient to model the object as one piece (unless the object must flex), as breakage could be modeled without real time constraints. Unless you have an existing physics engine that models constraints efficiently, you might want to look at using a full featured physics engine. If you can get by without complex constraints, you can reasonably quickly create an impulse-based rigid body simulator for flight/boats using FluidSample techniques for fluid motion (constraints and object stacking are far more complicated).

Using the FluidSample method with a working rigid body simulator (can be basic), you can have a "stick" airplane flying in a few hours (one fluid sample per wing, one per horizontal stab, 1 for rudder, perhaps 2 for fuselage; later add fluid samples to moveable control surfaces).

Danny Chapman created a free flight simulator (with source) that sounds like it uses the same concepts. In the future I'll release the sourcecode to VR Slingshot (might be useful for handheld/portable development (fixed-point physics, CFD, etc.).

[edit: Danny- why can't you blow up the yellow guy? [wink]]

[Edited by - John Schultz on April 23, 2006 9:24:13 PM]
Quote:Original post by coder0xff
After further thought about my problem, I realized a 3x3 matrix would not be suitable.

Quote:This is the method for calculating lift/drag on wings

Unfortunately, because of the nature of my program, it wont know which objects are "wings". In fact, an object may not even have been created with the intention of being flight worthy and my program will also not know which objects are meant to fly.


Yes, I know. I suggested this, because it can be used in connection with what I suggest at the end.

Slice your object, then apply the aforementioned method to each section. In the end, use the forces obtained to affect your rigid body.

This is not a perfect solution. Depending on the type of geometry, it might be highly unsuitable. But if you're trying to approximate some for of aircraft, it works adequately.

I also mentioned it because I applied this approach to simulating a parachute. The canopy could deform, strings would change the airfols unevenly across the wing, and there was no real way to use exact methods. I ended up slicing the canopy into several vertical sections, then calculating individual forces treating them like an airfoil individually. It worked more that sufficiently for what I was trying to simulate, but I wouldn't put those numbers to test by really flying such a parachute.



See also my GDC2006 talk, which discusses some of this:

GDC2006 Proceedings

Look for "Dancing with the Wind" and my name.
Graham Rhodes Moderator, Math & Physics forum @ gamedev.net
I must say that I'm very impressed with the ideas from the GDC presentation "dancing with the wind".

If you are just looking for a really quick and simple way (perhaps too oversimplified) to have different amounts of drag in different directions depending on the shape, then you can try:
http://www.melax.com/anisodrag/

If you have a serious application, such as an aerospace engineering simulator to test your airfoil design, then obviously the simple technique described here wont be adaquate.

There are a couple of other simple approaches that i've seen such as just precomputing the cross sectional area for each major axis and using that to scale the linear damping according to the current direction of motion.

Even a small step up above isometric linear damping can provide a more realism in a game. i.e. there's a definite difference in drag (object slowdown) when you throw a flat object parallel to the flat side versus perpendicular.



[Edited by - melax on April 27, 2006 11:00:35 AM]
Interesting idea Stan, sounds kind of like a Drag Tensor equiv. of inertia tensor (symmetric matrix, etc.).

Quote:Original post by melax
Its not feasible at runtime to iterate over the surface of an object each frame. The direction and speed are changing constantly. Therefore we rearrange the equation to isolate the dynamic variables from the internal part of the summation:


With just a few FluidSamples, you can iterate over a very rough approximation of an arbitrary object and get extremely realistic flight/motion. A net force is generated for each fluid sample (lift, induced drag, skin/parasitic drag, etc.). Try it: it only takes a few minutes to implement and test (if you already have a working rigid body simulator). FluidSamples can be extended beyond flat plate sections: cylinders and spheres are also easy/fast to implement.

Quote:Original post by melax
I must say that I'm very impressed with the ideas from the GDC presentation "dancing with the wind".


Thank you for the comment! I've implemented the system in our game engine, which unfortunately I cannot share freely.

These ideas are still evolving. I believe I will have to go to an approach where I explicitly model the torque generated, rather than try to model some aerodynamic center. Reason being, at high angles of attack the aerodynamic center is nonexistent (if you buy the MP3 audio from gdcradio you'll here my comments on the presentation) and to try and represent force as being applied at some nonexistent point just adds complications that are hard to deal with. I believe it will be far easier to add a simple torque model, which should require less tweaking than the current system. The Anderson reference from my talk has some discussion about modeling the torque explicitly.
Graham Rhodes Moderator, Math & Physics forum @ gamedev.net
Quote:Original post by John Schultz
... sounds kind of like a Drag Tensor equiv. of inertia tensor (symmetric matrix, etc.).

Hey, That's a very clever term 'drag tensor'. Technically it fits perfectly too - independant of chosen reference frame, symmetric, etc.

Mind if I use that?
(ill mention it was your idea)

This topic is closed to new replies.

Advertisement