Hey what a great airplane! Thanks for giving aerodynamics a try, I’m glad it worked out for you.
Regarding units, you might want to check out this post to see how units can be converted between Roblox and metric. The default Roblox gravity is quite a bit higher than “Realistic”!
We recommend simulated constraints (e.g. hinges) to actuate control surfaces, Motor6Ds don’t work well with aerodynamics.
We are considering ways to expose the wind profiles (i.e. Air Density at different heights). What exactly do you mean by “in a number sequence”? It would be good to hear what you (and others) think a good way of exposing Air Density at different heights could be.
Hmmm… we have considered exposing specific Aero forces through something similar to the Sensor approach we have used in the past. See: SensorBase | Documentation - Roblox Creator Hub
Would something like that work for your use case?
Yes it does! Take a look at Example 3 in the initial post for an example of this
We are hoping to take a closer look at Hydrodynamics (Drag forces in water). It turns out that the Aerodynamic force model approach we used for this release can be mostly applied to water as well. Stay tuned for this.
This is certainly on the long term vision. No promises here but it is very aligned with where we would like to go. Note: If you get a chance, take a look at the recent “Engine Innovations” RDC talk where we talk a bit more about the Aerodynamics / Fluid Dynamics roadmap. (The session videos might not be public yet but hopefully will be soon)
Thanks for your interest in the aerodynamics model! We really appreciate your giving it a try. At a high level, you can think of it as a local model for the forces on a body given its linear velocity, angular velocity, and the ambient wind. This localized force model is integrated over the entire body, incorporating the geometry, to get the total force and torque. It is not a lifting line method (specific to wings), nor is it a panel method (which can be expensive). We are constantly looking for ways to improve the Lift/Drag model where possible. No promises, but stay tuned for some potential updates.
Along with the force model, we have a bunch of additional math and code to make it both fast (real time) and stable. Would there be interest in a longer post that goes over the model in some detail?
I’m aware this model is in beta is probably has lots of issues to resolve, but is there any ETA when this will be rolled out outside of studio to Roblox? Id be really keen to go forward with a interesting game idea using this model
Good question. We are not able to promise a firm date yet since we would like to ensure we:
a) Have a lift + drag model we are confident will meet the needs of a variety of scenarios
b) Have enough time to optimize performance for the scenarios we see people building (make sure to send us any reports of performance issues so we can take a look at them!)
c) Provide a bit more help to creators to debug Aerodynamic forces so things are more usable
In the mean time, we wanted to get the APIs out there so folks like you could start building their experience, getting things ready and provide us feedback so you have a head start when Aerodynamics moves from a studio-only beta to an Open beta (i.e. publishable places)
Minor modifications to the number sequence system would allow developers to select altitude vs density percent, and the values could be linearly interpolated between the points. The downsides of such a system is that it is not an exponential graph and would be inaccurate without lots of points. Another idea is letting developers express the altitude and density percent relation as a function however that is not intuitive and somewhat limiting when compared to the number sequence method.
So a sensor base is like a value but it outputs selectable additional data about the part? If so that would work great for what I need. I would definitely appreciate having access to more backend engine numbers like the air density percent, aero force/torque, and total force/torque acting on a part.
I would be interested in a post that goes over the details.
I would say a large voxel grid with 16x16x16 voxel size containing data about wind direction and air density within the voxel(could even forgo wind direction and have just pressure using pressure to calculate wind direction and speed).
This approach would make fluid simulation easier to implement into the aerodynamics model and offer Developers a high level of control being able to have worlds that aren’t boring flat plates and instead actual realistic planets that are spherical.
EDIT: if 16x16x16 is too much data then maybe go up to 32x32x32 maybe give Developers control over it with voxel size settings 8x8x8, 16x16x16, 32x32x32, 64x64x64.
@LaAeroooo and @lukethebestpug Thanks for this discussion! This feedback is what we need from the Studio Beta, and we’d like to improve the experience of using the aerodynamic system.
Regarding welds, and assemblies in general, as @chefdeletat said, the aerodynamic force model was designed to use the constraint system to handle assemblies in relative motion.
Here are some addition details on what does/doesn’t affect aerodynamics on assemblies. Of course, please let us know if this does not work as advertised, we’d like to fix any bugs. We appreciate your feedback, it really helps us improve the model.
Does not affect aerodynamics:
Motor6Ds do not affect an assembly’s aerodynamic force. If you want to change the relative position of parts, and have that affect the aerodynamics, please use the constraint system.
Changing a Weld’s C0 or C1 will move parts relative to each other in an assembly, but we currently don’t catch this in the aerodynamic processing. If this is an important use case we can look at catching this operation.
Does affect aerodynamics:
Changing the assembly structure by adding/removing Welds or WeldConstraints will trigger the aero preprocessing and a change to the aero force computation. However, this can become costly on very large assembles especially when done rapidly repeatedly.
Changing a part’s position directly via its CFrame in an assembly connected with WeldConstraintswill trigger changes in its assembly aerodynamic force computation. Again, doing this rapidly on large assemblies can be a performance issue, so we recommend that if parts need to move relative to each other they should be connected using the constraint system.
Personally this is quite important for my usecases, since when using hinges, even with max force set to huge numbers, and locking the max and min angle, the surfaces slightly flutter at higher speeds causing the planes to also flutter.
edit - the fluttering in my case was because the control surfaces were massless and had mass set to near 0, increasing the mass and disabling massless fixed it for me. Thank you @kckhem for debugging!
Interesting, I have not been able to generate flutter with a servo hinge (went up to 1000 studs/s and air density of 10). A reproducer would be very helpful if it is not too much work.
Thanks again for trying this out and providing useful feedback!
a lot of games like navy simulator use welds to actuate control surfaces on aircraft, personally i find it easier than using hinges and a lot less buggy. maybe we could get a offset property for weldconstraints?
along with this im also curious, what is the optimization for fluidforces and aerodynamics? where does it yield? i asked the developers of navy simulator if they planned to use fluidforces and they brought up that it wasn’t optimized and they would stick to their own physics.