Vanilla particle shaders intermittently read all uniforms as 0 (Globals + DynamicTransforms UBOs)

[MR-CHOO]

Bug Description

Summary

At certain world positions / camera rotations, vanilla particles drawn through assets/minecraft/shaders/core/particle.fsh see most uniforms from the Globals and DynamicTransforms UBOs read as 0. Other render paths (entities, terrain, GUI) are unaffected. I've observed this bug on both of my PCs, a 3060 + i510600k build and a 3070 + intel i7 7820x build, meaning it's a bit less likely to be due to a specific driver or setup issue.

Key findings (observed)

• Certain world positions + camera rotations cause most tested uniforms from the Globals and DynamicTransforms UBOs to read as 0. Which are affected seems to be inconsistent, however GameTime is consisntently affected in every instance.
• Which spots are affected can change - sometimes after a pack reload, occasionally a previously-broken spot becomes fine on its own, though that's rare.
• Whether uniforms read correctly is inconsistent between game instances. Reloading the game or world can yield different results- sometimes uniforms are populated most of the time, sometimes they're almost always 0.
• The player's FOV also influences it - changing FOV can make broken areas start working, or vice versa.
• The freeze isn't isolated to the particle fragment shader - it affects upstream pipeline stages too. Uniform reads in assets/minecraft/shaders/include/*.glsl includes (which run before particle fsh) showed the same zeroed values in the same broken positions. Whatever leaves the UBO bindings in a bad state happens before the particle shader runs; however, it somehow only affects the particles.
• For example, a projection.glsl edit that applies a transform only on the 0th tick (gated by GameTime) causes particles to stay stuck in the transformed state forever, while everything else cycles correctly. In certain working spots, particles start cycling normally again.

Reproduction Steps

1. Minecraft 1.21.11, Sodium mc1.21.11-0.8.7 (also reproduces on 0.8.10), Fabric Loader 0.19.2, Fabric API only - no other mods required.
2. Resource pack overriding assets/minecraft/shaders/core/particle.fsh with this debug shader (turns particles white when uniforms read correctly, turns particles black with zeroed UBO field):

Gametime uniform particle test.zip

#version 330

#moj_import <minecraft:globals.glsl>

uniform sampler2D Sampler0;

in vec2 texCoord0;
in vec4 vertexColor;

out vec4 fragColor;

void main() {
    vec4 color = texture(Sampler0, texCoord0) * vertexColor;
    if (color.a < 0.1) discard;

    // White = GameTime is reading correctly.
    // Black = GameTime is zeroed (bug firing on this fragment).
    fragColor = (GameTime == 0.0) ? vec4(0.0, 0.0, 0.0, 1.0)
                                  : vec4(1.0, 1.0, 1.0, 1.0);
}

3. Spawn any particles and look around. In broken positions, particles render black, meaning that the GameTime uniform is broken and passing 0. In positions where it works, the particles render white.

4. Test on vanilla to observe the correct behaviour, all particles render white.

Log File

latest.log

This could be relevant?

[21:19:45] [Render thread/INFO]: Resizing Dynamic Transforms UBO, capacity limit of 2 reached during a single frame. New capacity will be 4.
[21:19:45] [Render thread/INFO]: Resizing Dynamic Transforms UBO, capacity limit of 4 reached during a single frame. New capacity will be 8.
[21:19:46] [Render thread/INFO]: Resizing Dynamic Transforms UBO, capacity limit of 8 reached during a single frame. New capacity will be 16.

Crash Report

My keyboard has it'd RGB toggle on F3+C, I can't manually crash a clean install unfortunately... here's my latest crash log, it should still include the hardware and software info thought it's polluted by mods haha.

crash-2026-04-27_20.13.26-client.txt

[douira]

Does this also happen on 26.1? Do you know as of which Sodium version this issue started happening?

[douira]

I can reproduce this on 26.1.

[douira]

Please test whether the GH Actions build from this PR fixes the problem for you #3637