Hi Michele, Sorry for the confusion here, we've released the flow primitives update since this discussion so it should now be much easier to produce these effects. You can now create a flow primitive and add that to your scene. Flow primitives have the same "VelocityFunction" that fluid zones have. We separated the volume/zone and the flow behaviour into two classes for clarity in their use, this means that a flow primitive will affect everything in a scene unless it is contained inside a Fluid Volume, i.e. it is a child of a game object with that component attached. An example flow primitive script would look like this: using UnityEditor; using UnityEngine; namespace AerodynamicObjects.Flow { public class FlowRoundCylinderDemo : FlowPrimitive { public AeroObject cylinder; public float freeStreamVelocity = 1; public override Vector3 VelocityFunction(Vector3 position) { // Get the position relative to the cylinder's position position -= cylinder.transform.position; // Assuming the cylinder is extruded along the z axis for simplicity float radialDistanceSquared = (position.x * position.x) + (position.y * position.y); float radialDistance = Mathf.Sqrt(radialDistanceSquared); float cylinderRadius = 0.5f * cylinder.dimensions.x; // Non-physical, we're inside the cylinder if (radialDistance <= cylinderRadius) { return Vector3.zero; } float cosTheta = position.x / radialDistance; float sinTheta = position.y / radialDistance; float omega = cylinder.rb.angularVelocity.z; float circulation = -omega * cylinderRadius * 2f * Mathf.PI * cylinderRadius; float rr = cylinderRadius * cylinderRadius / (radialDistance * radialDistance); float vr = (freeStreamVelocity - rr) * cosTheta; float vtheta = (-(freeStreamVelocity + rr) * sinTheta) - (circulation / (2f * Mathf.PI * radialDistance)); return new Vector3((vr * cosTheta) - (vtheta * sinTheta), (vr * sinTheta) + (vtheta * cosTheta)); } } } Please note that I haven't been able to test this - if you have any issues with it please let me know and I'll look into it in more detail. Best wishes, Conor

Hi Scott, Thank you! A ground effect is quite difficult to implement as a general tool as I'm sure you can imagine. We would love to include something in the future but for now it's on the long term list of "nice to have". If you wanted to implement your own ground effect, I would suggest creating some kind of reflection of the flow using the surface of the water as your mirror. I.e. any flow primitives you have that are above the water, create a copy of them the same distance below the water and flip their direction. You could add some damping to the reflections as well. Ultimately I think this would become a reflection probe primitive which would do all of this automatically for a set of flow primitives, but for now I don't have the brain power to fathom it. Good luck! And I'd be really interested to see some of the work you're doing in AO if it's possible to share Conor

Hi skaughtx0r, Thank you so much for your report and efforts! I have uploaded your suggested fixes on the asset store, they may take a few days to go live as Unity need to approve them. I have considered object pooling for the wake shedding and this will be used in a future version of the wake tools. The lifting and bluff body wakes are still quite new, the main obstacle we're working on with them is how to properly tune the wake "fidelity" so that it is shed sensibly for a range of wind speeds. Right now, because of the lifespan of the shed vortex nodes, an increase in wind speed will lead to an increase in the number of nodes in the wake. We wanted to create the wakes using the flow primitive tools to demonstrate how they can be used as building blocks to produce complex flow structures. In a future update we will bring a more optimised wake structure tool which will treat its nodes more like the particle system managers rather than using game objects and suffering the overhead of creating/destroying/updating them. Thanks again and all the best, Conor

Hi Skaughtx0r, Apologies, we've been battling with scope creep on this and the update has become quite large. It means a lot of new features are coming to the core package but it's taking longer than we had hoped. We've set a hard deadline of the new year with the main things left to do being documentation and tutorials. Best wishes, Conor

Hi Skaughtx0r, Thanks for your interest! We're hard at work putting the tutorials together and fixing a few bugs in the update. We're aiming for the update to roll out mid September after a couple of unexpected delays. The update will be applied to the existing asset on the asset store so if you already own Aerodynamic Objects you will receive the update at no extra cost. Please note that due to the scale of the update we can't guarantee backwards compatitbility so previous projects may require a few minor changes to work with the update. Best wishes, Conor

Hi Wei, Apologies for the delay. Simulating airflow around generic/irregular shapes is a job for a CFD package and is a bit beyond our aerodynamics tools. You can make an approximation in our tools by adding simple shapes together which would be enough to get a reasonable wake behind a vehicle etc. If you are feeling brave you could create functions for the flow around complex shapes and include them in a custom fluid zone, perhaps by modelling data from experiments. Best wishes, Conor

Hi Wei, Sorry, I understand what you're asking now - thanks for bearing with me! Our demo for flow around a cylinder uses a custom FluidZone, not the default one. We wrote a velocity function specifically for that demo which looked at the cylinder object and created a flow field based on the free stream velocity and the rotation of the cylinder. That particular code wasn't released with the AO package and my colleague is on leave at the moment so I don't have access to the code he wrote. We are working on releasing more features and tools for flow simulation in the next update to AO. I have thrown together a quick example of how you can go about this. Please only consider this as an example, I can't guarantee that it's accurate and working for all cases but it does give something that looks appropriate. The example code: using AerodynamicObjects; using UnityEngine; public class RotatingCylinderFluidZone : FluidZone { public AeroObject cylinder; public float freeStreamVelocity = 1; public override Vector3 VelocityFunction(Vector3 position) { // Get the position relative to the cylinder's position position -= cylinder.transform.position; // Assuming the cylinder is extruded along the z axis for simplicity float radialDistanceSquared = (position.x * position.x) + (position.y * position.y); float radialDistance = Mathf.Sqrt(radialDistanceSquared); float cylinderRadius = 0.5f * cylinder.dimensions.x; // Non-physical, we're inside the cylinder if (radialDistance <= cylinderRadius) { return Vector3.zero; } float cosTheta = position.x / radialDistance; float sinTheta = position.y / radialDistance; float omega = cylinder.rb.angularVelocity.z; float circulation = -omega * cylinderRadius * 2f * Mathf.PI * cylinderRadius; float rr = cylinderRadius * cylinderRadius / (radialDistance * radialDistance); float vr = (freeStreamVelocity - rr) * cosTheta; float vtheta = (-(freeStreamVelocity + rr) * sinTheta) - (circulation / (2f * Mathf.PI * radialDistance)); return new Vector3((vr * cosTheta) - (vtheta * sinTheta), (vr * sinTheta) + (vtheta * cosTheta)); } } I hope that's helpful! A side note, the communication between AeroObjects and FluidZones is one way, i.e. an AeroObject gets flow information from a FluidZone but a FluidZone does not get information about AeroObjects. Best, Conor

Hi Wei, The fluid zone should only have a trigger collider attached to it: The Unity collision system gets a little bit complicated when using triggers. To make sure it all works, the AeroObject must have a RigidBody component and a regular Collider (with IsTrigger set to false). The FluidZone must have a trigger Collider attached (IsTrigger set to true) and doesn't need a RigidBody component. If the AeroObject is still colliding with your FluidZone, check that there are no Colliders in the children of the FluidZone, or other Colliders in the scene which could be causing the collision to happen. Best, Conor

Hi Wei, I'm not sure I understand what you mean when you say "the wind direction does not change based on the objects I come into contact with". The demo you shared has a fluid zone which is connected to the cylinder by a public reference, i.e. public AeroObject cylinder; We then used properties of the cylinder in the VelocityFunction to create a mathematical representation of the wind speed in the space around the cylinder. A separate Flow Field Particles object is then placed inside that fluid zone and each particle has its velocity set by the zone's VelocityFunction, using the position of the particle as input. Best, Conor

Hi Wei, That's a use case I hadn't considered before! I suggest you go into the FluidZone class and change the OnTriggerEnter function defintion (line 62 I think) to be: public virtual void OnTriggerEnter(Collider other) Then in your fluid zone class you can override the OnTriggerEnter function and add your logic for detecting objects entering the wind field. If this is something that needs to persist you can also add an OnTriggerStay to update your values. MAKE SURE you keep the base.OnTriggerEnter(other); line in your override otherwise the fluid zone functionality will break. Best, Conor

Hi Wei Lin, Apologies, we are working on better documentation and tutorials for this part of the tool kit so things are a little sparse. You should have a "DefaultFluidZone" script in AO > Core > Scripts which shows how to inherit the FluidZone class and overrides the VelocityFunction to produce a prevailing wind which can also have turbulence applied based on the position of the object. Let me know if you need any help understanding it! Best, Conor

Hi Wei Lin, The current package can be used to do the same thing, we don't have tutorials set up properly for wind conditions just yet but the functionality/framework is there. Our upcoming update will include some classic models such as doublets, vortex blobs, fillaments etc. For now, you will need to create a new class which inherits from the existing FluidZone class and then override the VelocityFunction to provide your model of the wind field as a function of position. For example, you can add a prevailing wind by creating a FluidZone which returns your desired wind velocity no matter what position is provided to the VelocityFunction. Note that for a fluid zone to be detected by an AeroObject, you need to have a trigger collider on the fluid zone and a collider + rigid body on the aero object for Unity to produce the OnTriggerEnter and OnTriggerExit events which are used by the base fluid zone class. Best, Conor

Hi Wei Lin, Thank you for your interest! We are currently working on a big update for the flow visualisation tools which will include more demos, tutorials and features. The update should be out in the next couple of months and will be part of the core AO package so no need to purchase any extras! Best, Conor

The flow around control surfaces is quite difficult to model if you are using separate objects as the lifting surface will affect the flow the control surface experiences. I wouldn't advise having two aero objects to model a lifting surface and a control surface. We are working on an aircraft specific update which includes models for trailing edge and leading edge control surfaces which will be released in the summer along with lots of other high level control tools! For now I would suggest having a graphic representation of the control surface which can move and then having the deflection angle of the control surface converted into a control camber value on the main aero object for that section of the wing/tail. Note that you will need to divide up the aircraft so you have at least an aero object for each control surface. You can then use aero groups on objects in the wing and the tail to make sure the aspect ratio correction is appropriate.

Hi Eugene, It's better to have aero objects for each surface that are all connected to a single rigid body for the aircraft. It would still work having multiple rigid bodies, but you would need to join them together and you would risk the joints becoming unstable or adding/removing energy to the system

I can't think of an easy solution to this. AeroObjects generate forces that are applied to Unity's RigidBody component so if you can find a way to slow down time for selected rigid bodies then you will achieve the desired effect. I couldn't find anything on the Unity forums that would give you this effect easily. You could try to adjust the forces acting on the objects so that the resulting accelerations would be scaled down by your time scale, however, Unity makes it really hard to change collision forces, they seem to be applied separately to the fixed update loop so you would end up with janky behaviour during collisions. Another potential solution would to be use multiple scenes and have your slow motion objects in a separate scene which you manually manage the simulation of: https://docs.unity3d.com/Manual/physics-multi-scene.html https://docs.unity3d.com/ScriptReference/SimulationMode.Script.html

Hi Eugene, Scaling an aircraft is quite complicated as different properties are related to the size of the aircraft in different ways. Mass for example is roughly proportional to length^3 through volume and density while most aerodynamics depend on area which is proportional to length^2. Factors you will want to consider when scaling your model are the thrust to weight ratio and the wing loading of the newly scaled model. Keeping those ratios the same as the original model should give decent results. Bear in mind that moments of inertia will also change. Single precision floating points are plenty accurate to work across a scale on the order of 100x. Your main issue will be getting the wing loading correct with the new model. If you have a very small mass but very large aerodynamic loads then the simulation will become numerically unstable and won't be useable.

Hi Zalz, Your fluid properties look fine! If you're using the latest verison of Unity you can look at https://docs.unity3d.com/ScriptReference/Rigidbody.GetAccumulatedForce.html to find the total force acting on a body - you can then compensate for large forces by adding forces in the opposite direction of the accumulated force. Note you would need a script running in a larger execution order to ensure all the forces have been added to the rigid body before saturating them. Check out this for more on execution orders: https://docs.unity3d.com/Manual/class-MonoManager.html For your test, you can check the expected terminal velocity of an object using the following equation: v = sqrt( 2mg / pACd ) Where v is the terminal velocity, m is mass, g is acceleration due to gravity, rho (p) is the density of the fluid (1.23 by default), A is the area (0.785 m^2 for your cube - note we use ellipsoids to approximate bodies) and Cd is the drag coefficient (0.5 is a good approximation for a cube). I get 6.37 m/s for a 1x1x1 m cube at 1 kg. Our drag model is a bit more involved than that equation which will explain the discrepancy, the cube actually reaches 6.33 m/s in my tests. During development we decided it was best to use Unity's physics solver so that our tools are fully compatible with Rigidbodies. Unfortunately, this means that drag can become unstable when the drag force and the weight of an object are close in magnitude. A rough estimate for instability is to compute the value of: 4m / (p S Cd v) (m is mass of an object, rho (p) is the density of the fluid (1.23), S is the largest area on the object, Cd is drag coefficient (in this case use the max of 1.2), v is an expected velocity for the object). If that value is less than the fixed delta time in your simulation, then you will likely have instability and objects will shoot off. The cube experiment for example gives a value of 0.545 so a simulation of that cube falling at 6.33 m/s should be stable with a time step of around 0.5 seconds - though I would advise using a much smaller one! You can ensure stability by either: reducing the fixed delta time, increasing the mass of your objects, or reducing their areas. We have found a good value for fixed delta time to be 0.002 seconds. Hope that helps!

I wouldn't recommend using a group for this application as the panels will be moving separately to each other. The grouping is intended for a rigid wing structure like a typical aircraft. By not using a group you may notice the ellipsoid bodies will slightly underestimate the platform area of the wing. You can make them larger to account for this or see how they perform as is. Generally I haven't found an issue with the slight underestimate!

Hi Zalz, You don't specifically need to add a fluid zone unless you want to control the wind velocity in a local area. Any object will use its own velocity as well as the fluid's velocity to determine the aerodynamic forces acting on itself. For example, an object falling at 10 m/s is the same as an object that is stationary while the wind is blowing at the object at 10 m/s. If you have the wings attached using configurable joints then you can simply add an AeroObject to each wing and set the AeroObject's rigidbody to be the wing's rigidbody and the forces will be applied appropriately. I would recommend enabling Lift and Drag for the AeroObjects, potentially Rotational Damping as well. I would not include Rotational Lift as this can produce inaccurate forces when an object is not in continuous rotation, i.e. when it is oscillating back and forth like a wing would.