GPUParticles2D not random

[pmoosi]

Tested versions

• Reproducible in current master [ee4acfb], 4.4-beta2
• Not reproducible in 4.4-beta1

System information

Godot v4.4.beta.mono (3979c17) - Ubuntu 24.04.1 LTS 24.04 on Wayland - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - integrated AMD Radeon Graphics (RADV RENOIR) - AMD Ryzen 7 5800H with Radeon Graphics (16 threads)

Issue description

GPUParticles2D spawn always in the same 'pattern', even when ranges are set (e.g., initial velocity or spread). It's as if they use a fixed seed.
This also applies to one-shot emitters.

Steps to reproduce

In the mrp there are two GPUParticles2D nodes that spawn one particle with a initial velocity of 50 - 100 and a spread of 180. When run, both nodes always emit the same particles as each other.

Minimal reproduction project (MRP)

mrp.zip

[AThousandShips]

Can confirm, will bisect

[AThousandShips]

Bisected to #101688, which would be a natural consequence of the changes there but doesn't seem to have been intentional

CC @TCROC

[TCROC]

Fascinating. @QbieShay @clayjohn @Calinou it appears that the very thing we hoped to prevent was introduced with that PR 😅.

There was A LOT of back and forth about what needed to be done to prevent this very thing. 😅

@AThousandShips does this mean we actually do need to randomize the seed when we call set_one_shot?

[AThousandShips]

I'm not sure what changed specifically, as the seed value is not randomized on construction as the documentation shows, so I'm unsure when it was randomized in 4.3 and between the fixed seed feature was added and this change, worth going through those changes

[TCROC]

Didn't we have to make sure it wasn't randomized in order to make the pipeline happy?

#101688 (comment)

[AThousandShips]

Yes but that just means the seed was randomized later after construction, or the documentation would have been changed on CI before this, so the way the seed was initialized after construction must have been different, but I'm not familiar enough with this code to know what it did differently back then

[AThousandShips]

One theory I have is that the seed in the server is random on initialization, and that the now explicit call to set_seed(0) sets it upstream but the stored seed value in the class is not set, we could confirm this by fetching the seed value of the particles on initialization before the changes (but after the fixed seed addition and adding seeds to the particle class itself)

In that case the original behavior in 4.4 was undefined behavior arguably, but we still need to restore that as there's otherwise no way to not have a fixed seed

I'd say that the solution would be that we make it so the seed is random on construction, but have a property default of 0 to make it display it correctly in the documentation, but we'd have to check that it doesn't break saving the value etc.

Edit: The proper solution would be to set the property of the seed but leave the seed value in the server random, or call the server version with a random value, that way the property remains 0, but the behavior remains random (as per the documentation the seed is not effective otherwise)

[TCROC]

Discussed in the rocket chat here: https://chat.godotengine.org/channel/vfx-tech-art?msg=39GFd2JQHTrScmSPu

@QbieShay knows the issue and is working on a fix :) Thanks Qbie! :)

[bakana808]

Encountered this the other day too but with GPUParticles3D. In the meantime while waiting for the fix, this can be worked around by randomizing the seed manually on ready with something like $GPUParticles3D.seed = randi(). FWIW