Some bugs and performance issues I noticed while playing around with the new version of AO.
Player builds are failing due to references to UnityEditor in non-editor scripts.
Assets\AO\Scripts\Flow\FluidVolume.cs(446,13): error CS0234: The type or namespace name 'EditorApplication' does not exist in the namespace 'UnityEditor' (are you missing an assembly reference?)
Assets\AO\Scripts\Flow\FluidVolume.cs(32,30): warning CS0109: The member 'FluidVolume.collider' does not hide an accessible member. The new keyword is not required.
Assets\AO\Scripts\Flow\VortexNode.cs(32,21): error CS0234: The type or namespace name 'EditorApplication' does not exist in the namespace 'UnityEditor' (are you missing an assembly reference?)
Assets\AO\Scripts\Flow\VortexNode.cs(48,62): error CS0103: The name 'HandleUtility' does not exist in the current context
Assets\AO\Scripts\Flow\UniformFlow.cs(97,40): error CS0103: The name 'HandleUtility' does not exist in the current context
Assets\AO\Scripts\Flow\UniformFlow.cs(99,13): error CS0103: The name 'Handles' does not exist in the current context
Assets\AO\Scripts\Flow\UniformFlow.cs(100,13): error CS0103: The name 'Handles' does not exist in the current context
Assets\AO\Scripts\Flow\AreaSource.cs(108,13): error CS0103: The name 'Handles' does not exist in the current context
Assets\AO\Scripts\Flow\AreaSource.cs(113,21): error CS0103: The name 'Handles' does not exist in the current context
Assets\AO\Scripts\Flow\AreaSource.cs(117,21): error CS0103: The name 'Handles' does not exist in the current contextThese can be fixed by adding #if UNITY_EDITOR blocks around the references to UnityEditor things.
2. The localFluidVolumes.RemoveAll call in FlowAffected.cs is allocating a lot of memory every frame. This can be fixed by using a for loop instead.
for (int i = localFluidVolumes.Count -1; i >= 0; i--)
{
FluidVolume item = localFluidVolumes[i];
if (item == null || FlowInteractionManager.IsInteractionIgnored(interactionID, item.interactionID))
{
localFluidVolumes.RemoveAt(i);
}
}3. When using LiftingBodyWake, it is constantly Instantiating and Destroying GameObjects every frame. It would be much more efficient to use ObjectPooling for this or use data structures outside of GameObjects entirely.
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