Aero by collision mesh or by model

[LORDPrometheus]

Just a quick question are aero effects calculated based off the collision mesh or off of the model

[panzer1b]

I believe collision, as it uses bounding box stuff for drag/aero.

there are MANY MANY shortcuts they took though, especially when it comes to occlusion. For occlusion essentially the 1st part in a stack takes full drag, the middle pats take occluded drag (its actually near 0 if you arent flying at an angle), and the rear part has like 50% drag or something like that. This means occlusion doesnt do much if anything when you have just 2 parts, it lowers drag on the rear part by some, but not by much. Occlusion ONLY kicks in when you have 3 or more items stacked. One way to exploit this is to make a stack of stuff, and place a cubic strut on the front and back. this gives the entire middle FULL occlusion, AND cubic struts have basically 0 drag anyways, so im pretty sure you can guess what that means when it comes to drag for the whole stack.

Btw, if you havent already figured it out, occlusion DOES NOT CARE about relative size of parts that are behind/in front. This means that a cubic strut will occlude anything including a 3.5m tank FULLY!

Javascript is disabled. View full album

While teh new aero still beats the old one by a long shot, if you know how, you can exploit the crap out of the new aero (it still behaves plausibly with conventional craft though). One tip that i have though (if u want to cut down drag) is to place a cubic strut behind a rapier, itll take the rear drag and rapier gets full occlusion from it.

[NathanKell]

Nope, it's by entirely by mesh, does nothing with bounding box or colliders. What panzer1b's screenshot shows is a bug in the occlusion logic.

The mesh seems to be broken down into six faces (it is called DragCubes after all) and the area of the mesh (vs a full face) in that direction is kept, as well as how rounded/tapered the mesh is in that orientation.

[sumghai]

Nope, it's by entirely by mesh, does nothing with bounding box or colliders. What panzer1b's screenshot shows is a bug in the occlusion logic.

The mesh seems to be broken down into six faces (it is called DragCubes after all) and the area of the mesh (vs a full face) in that direction is kept, as well as how rounded/tapered the mesh is in that orientation.

Just to clarify, will we need to define a new, dedicated DragCube (or equivalent) submesh for our parts, or will the existing part colliders / mesh renders suffice?

[Sandworm]

there are MANY MANY shortcuts they took though, especially when it comes to occlusion. For occlusion essentially the 1st part in a stack takes full drag, the middle pats take occluded drag (its actually near 0 if you arent flying at an angle), and the rear part has like 50% drag or something like that. This means occlusion doesnt do much if anything when you have just 2 parts, it lowers drag on the rear part by some, but not by much. Occlusion ONLY kicks in when you have 3 or more items stacked. One way to exploit this is to make a stack of stuff, and place a cubic strut on the front and back. this gives the entire middle FULL occlusion, AND cubic struts have basically 0 drag anyways, so im pretty sure you can guess what that means when it comes to drag for the whole stack.

I found the above so preposterous I had to test it. Like, um, wow. Four years of development on an aerospace-related game and that's the best they could come up with? Checking for disparities in size between stacked parts and then adjusting a drag variable accordingly is not a major coding issue.

And people were worried that the days of aero exploits were over!

Edited May 1, 2015 by Sandworm