DynamicWind Plugin Roadmap and Possibility of Per-Instance Animation

We are running engine version 5.8.2 with the DynamicWind plugin. We know this plugin is still experimental and are generally happy with how this approach is shaping up. We have found some shortcomings with the system and would like to know what is in Epic’s roadmap to tackle and what are possible gaps we might need to fill on our side.

Firstly, we have an in-house weather system with a wind velocity vector that is animated both in speed and direction. The current version of this plugin does not respond well to animated wind values. Animating speed causes violent shaking and animating direction makes a popping bug much more apparent. We have made changes locally to address these issues, but I wanted to flag them here.

Secondly, the current version creates 8 animations of each skeleton based on rotation and each instance chooses the best match. This works well generally, but doesn’t allow for situations like character interaction or localized wind forces. We would like to explore the possibility of a flexible pool of per-instance animations that can be run when needed on specific instances.

Are folks at Epic working on a solution that would allow for player interaction or other localized forces on nanite foliage?

[Attachment Removed]

Steps to Reproduce

To see the problems with an animated wind vector, we’re just using the UDynamicWindSubsystem::UpdateWindParameters() API to set the values on a tick

[Attachment Removed]

Hello,

Thanks for reaching out about the Dynamic Wind plugin. In short, we have made a massive push to improve the plugin over the past few months and expect to bring it to a production-ready state with the 5.9 release, barring any unforeseen issues. As to your first question, how do you author your velocity vectors? We are planning to support Niagara-authored velocity volumes, which should reduce the likelihood of animation bugs.

For your second question, the system now supports simulating up to 1024 bones locally, although a full constraint solver will not be feasible on the GPU. There is an instance promotion/demotion system that determines which bones are moved from the cardinal direction track to a fully-simmed GPU integrator track. Each bone is then simulated locally as two-layered inertial-damped spring oscillators: one underdamped for branch sway and one critically damped for branch flutter. Character interaction can be implemented via capsule volumes and other components that will be made available in a future release.

If you already want to evaluate the new changes, you can check out the code in the UE6-Main stream, with CL 57660154 as the latest change. If you have any further questions, please let us know.

[Attachment Removed]

Our weather system controls a UWindDirectionalSourceComponent that we animate with a “weather sequence” authored in our custom timeline editor. We like using wind source components because then CPU consumers like cloth and GPU consumers like materials and Niagara can all be driven by one authority. We also use the wind sources as localized force volumes, which works out of the box for cloth. We implemented a 3D wind fluid sim using these as inputs, which is how we make localized wind available on GPU.

The animation bug comes from the DynamicWindEval shader deriving the WindWave and WindFlow values simply from time * speed. Lowering the speed has the same effect as going back in time. We had to solve this same problem in materials where we use a scrolling noise texture, basically we just maintain an offset and accumulate from the current wind values.

That’s great to hear how far along you are, we were also thinking a spring-based approach would work best for this. We have a GPU resource already that we use for character interaction in other contexts that I think we could leverage here. I’ll dig into the new changes and will probably have follow up questions.

Thank you for your help!

[Attachment Removed]

Glad to hear that! From what it sounds like to me, your Niagara-based approach is similar to ours, although I have not fully dug into all of the details of our own system. If you find something missing in our current implementation, please let us know, and I can forward your feedback to the main developer on the team. As for the animation bug, I am confident that it has been fixed in the new version, so if you decide to upgrade to 5.9, you should get that fix “for free”.

[Attachment Removed]

Here’s some footage of what we see with the vanilla version:

[Attachment Removed]