Orbiter simply takes the projected areas of your objects and applies a drag coefficient that is usually a function of Mach number. It does the same with wings, applying lift and moment coefficients. These coefficients are all empirical, you have to go dig through literature to find test data for a body similar in shape to your vessel.
In Orbiter, you can actually take a mesh in the shape of a brick and write a dll to give it the flight qualities of a glider. You'll find that a lot of add-ons fly exactly like the DeltaGlider, because they were made by someone with great graphics skills but not such a great understanding of the aerodynamic coding requirements.
I recall a couple of years ago, maybe back on M6, that someone was working on a compressible flow solver that would accept a *.msh file, mesh it and determine the lift, drag, and moment coefficients for use in .dlls. I forget who it was, but I worked with them about the numerics. They got it running after a fashion, but it was not polished by any means.
I used to do computational fluid modeling when I was in industry. It really is computationally intensive, and the code really needs to be run by someone who has an understanding of the underlying numerical methods and fluid physics or else you will get wrong answers (that can look correct!) or NaNs. Compressibility, turbulence modeling, heat transfer, variable densities...these are all modeled differently and one needs to know in which situation which model is appropriate.
Much of my consulting work involved walking into a low-budget engineering firms and yanking the CFD software away from the fresh-out-of-college engineer assigned to use it who couldn't solve anything with it. Many companies think because they have a CFD license that they know what they are doing. There are many companies bleeding R&D money because they truly don't know what they don't know.
