TurbulentWake performance issue

[Amerio.Stephane]

Hello,

For one scenario, we need to have about 20 boats, most are large stationary or with a low velocity, some would be moving very fast (speedboats).

We have a very bad performance issue when we have more than a few b5bc2e35716c7e097fb9ed77a1ce15f24ada6c5b8.htmloats. The TurbulentWake component consumes up to 10ms on some frames, which is clearly way too much.

Attached a microprofile extract.

What can be done to improve this? 

[silent]

Hi Stephane,

Thank you for the MicroProfile capture; it is quite useful.

As far as we understand, you currently have 21 boats updated in the scene. Could you please also let us know how many speedboats you have?

So far, it appears that each individual boat is doing its best to update. However, for multiple objects, an additional optimization layer is needed, which is currently not present.

Our QA team and devs will try to reproduce this behavior first to understand what we can do here.

For the 2.19.1 release, I believe the best approach is to reduce the number of turbulent components for slow-moving boats or temporarily disable some boats to achieve better overall performance. This adjustment can be made until we determine a more effective method for rendering such a large number of objects.

Thanks!

[Amerio.Stephane]

Hi,

With just 4 moving boats, the total frame time of KelvinWake+TurbulentWake reaches around 8ms (all other boats have been made static), which is way too much. The problem here is we can't deactivate the remaining wakes, as the whole purpose of the exercise is to check the ability of the crew to found the fast moving boats, and the only hint is their visible wakes...

Is there any way this can be optimized on our side? (eg. by deactivating the call to update() for certain nodes on certain frames?)

[silent]

Hi Stephane,

In the previous microprofile dump that you've sent us there were 8ms for 20 ships and now it's 8ms for 4? That's quite strange. 4 ships should be around 1.5-2ms.

Is there any additional logic that you are using? Maybe you can show us a video where we can see the exact use case and how boats are performing?

Thanks!

[Amerio.Stephane]

Sorry, I'll be more specific. In the previously shared dump, there is around 20 boats, with only 4 moving boats. So I initially assumed that all boats wakes were actually consuming a lot of time.

Then, I implemented some logic to disable all nodes with a turbulentwake and kelvinwake property but with no velocity. This leaves only 4 boats which should really consume some time. But the end result is also that just these 4 boats consume around 8-10ms. So effectively disabling nodes for static boats is not an improvement (apparently).

Each boat as also a Ground clamp component, but I timed it and its negligible compared with the wakes.

I'll try to make a test scene.

[silent]

Hi Stephane,

We have identified areas where performance is below expectations. Some improvements on the CPU side have already been implemented in our internal builds. We are currently awaiting the implementation of the GPU component (bindless resource) to continue our optimizations on GPU side as well.

If you could also provide a test scene (within a month or two, no rush here), we can test it after implementing all our changes to see if it makes a difference in your case.

Thank you!

[bmyagkov]

Hello Stéphane,

It appears that this behavior might be effectively addressed by some additional adjustments on the content side. A subtle point to note is that the performance impact from dynamic mesh decals depends on the angle at which the camera views the wake trail. In the worst-case scenario—when viewing multiple trails from a grazing angle—the performance cost of the component settings can increase by about twice as much or slightly more. Performance can be further adjusted and optimized depending on the specific use case.

The most significant settings affecting the wake trail relate to the density of the mesh paths. For example, in the screenshot, the “step distance” parameter in the TurbulentWake component and the “segment step distance” in the KelvinWake component are key. Increasing these values results in a sparser mesh grid and thus better performance; however, this may cause the trails on the water to appear more angular or fragmented. We recommend setting these values as high as possible while maintaining acceptable visual quality.

Would you be able to try these adjustments and let us know how it goes?

Thanks!

[Amerio.Stephane]

Great info, I'll have to test these, but most probably I'll test directly with 2.20 in the upcoming weeks. For the record, most of the trails will be viewed at a grazing angle, and with a (very) narrow FOV, so it's the worst case...

Note that for very distant trails, we don't need the trail to actually displace the water, just the decal on the existing water mesh would be enough (not sure if this is relevant with your implementation).