Search Issue Tracker

Active

Under Consideration for 6000.6.X

Votes

1

Found in

6000.0.67f1

6000.3.7f1

6000.4.0b7

6000.5.0a6

6000.6.0a4

Issue ID

UUM-134143

Regression

Yes

SpeedTree does not move when using WindZone while using BiRP and having Vulkan or OpenGLES3 as an active Graphics API

Environment Effects

-

Reproduction steps:
1. Open the attached project “ReproProject”
2. Open the scene “SampleScene“
3. Make sure Vulkan or OpenGLES3 is set as an active Graphics API (the option can be checked in Edit -> Project Settings -> Player -> Other Settings -> Graphics API for Windows
4. Enter into the Play Mode
5. Observe the result

Actual result: Speed tree does not react to the wind effect produced by WindZone
Expected result: Speed tree reacts to the wind effect produced by WindZone

Reproducible in: 2023.3.0b8, 6000.0.67f1, 6000.3.7f1, 6000.4.0b7, 6000.5.0a6
Not reproducible in: 2023.1.0a1, 2023.3.0b7

Reproducible on: Windows 11
Not reproducible on: No other environments tested

Notes:
- Does not reproduce with DirectX11 or DirectX12
- Reproduces in a Standalone Player for Windows
- Does not reproduce with URP (fixed for URP in UUM-87614)
- Wind animation works correctly inside SpeedTree Modeler prior to export
- Issue reproduced using both SpeedTree 8 (.st) and SpeedTree 9 (.st9) pipelines
- Issue can be reproduced with multiple different tree assets (not asset-specific)

Comments (1)

  1. JoMoschos

    Feb 18, 2026 17:53

    Thank you for marking this issue as fixed and linking it as a duplicate.

    However, I can confirm that the problem is still reproducible in Unity 6000.3.xx (LTS).

    SpeedTree trees do not respond to WindZone when Vulkan or OpenGLES3 is the active Graphics API. The wind animation only works when using DX-based rendering backends.

    According to the Issue Tracker, this was fixed in 6000.0.36f1 and related 6000.0/6000.1 streams. Since 6000.3 LTS is a later branch, the fix should already be included — but the issue persists.

    Could you please clarify:

    • Was the fix actually merged into the 6000.3 LTS branch?
    • If so, could this be a regression?

    This is affecting both Editor (non-DX backend) and player builds, so confirmation would be greatly appreciated.

    Thank you.

Add comment

Log in to post comment