GPUParticles3d.emit_particle() EMIT_FLAG_COLOR does not work

[thmasn]

Godot version

4.2 RC1 and 4.2 RC2

System information

macOs 13.5.2

Issue description

when spawning particles on a GPUParticle3D Node via gdscript by calling emit_particle, different properties of the particle can be set.
the EMIT_FLAG_COLOR does not seem to register, and the spawned particle is not colored in the specified color.

according to the docs, the flag 8 should set the color, but it doesnt respond. the flags for position (1) and velocity (4) work.

Steps to reproduce

• create GPUParticle3D
• set up material to use vertex colors
• spawn a particle via code and set the color and flag
• the particle does not have the specified color

Minimal reproduction project

minimum project with a GPUParticle3D and a script spawning particles with color red:
https://github.com/thmasn/ParticleTest

[clayjohn]

It looks like the color is getting set correctly in start(). But in the process() function it is getting overridden:
https://github.com/godotengine/godot/blob/fa4a65387ea41506ecc519fc61a06da110dce51c/scene/resources/particle_process_material.cpp#L1053\

This will require a little bit of discussion. In 4.1.3, the emitted color is never used. That's just a design of the particles_process_material. You could use it in a custom shader and it would work fine.

In 4.2-rc2 the color is correctly reset (or not) depending on the EMIT_FLAG_COLOR flag, but then the color value is ignored in the process function. So the end behaviour is the same.

I think it makes sense to incorporate the emission color into the particles_process_material. But we need to discuss how we would do so. In the particles_process_material color is a dynamic thing that can change from frame to frame, so its not clear how the emitted color should interact with the dynamic color (should it multiply? should we have a new mode where color is not updated after emission?)

CC @QbieShay

[QbieShay]

Huh. I don't know honestly how to make it work or how it is supposed to work. Did it work before?

COLOR is an accumulation variable so then it wouldn't work with color over life.

[clayjohn]

@QbieShay this is essentially a new behaviour request. It's not that it "worked" or "didn't work". The particles_process_material has always ignored the color of the emitted particle. But the OP is (rightfully IMO) surprised the the emission color is ignored.

We need to figure out if it is worth adapting particles_process_material to use the emission color.

[QbieShay]

Depends what OP is trying to do. Unless there's a specific usecase then im not sure it's worth the memory cost to save the initial color.

[thmasn]

the specific use case is in a racing game:
i have a particle emitter spawning smoke particles at the wheel. i want the particles to match the color of the ground.
for this, i want to check the current colliders, get the mesh color (or collider layer), and then spawn an according particle.

the alternatives i see is either having many particle systems for each color, or write a new particle system from scratch.

"You could use it in a custom shader and it would work fine" - this sounds like a good solution, but how would i access the initial emission color?
and, if this is the way to go, a note in the docs mentioning it would be a helpful addition.

[QbieShay]

Assuming it all world as I expect it to, you'd find your color in COLOR

[thmasn]

i guess the current behaviour it is fair to most use cases, and modifying the ParticleProcessShader to make it work is commenting out two lines, so it is ok as is.
i made the above pull request 85717 to update the documentation. hopefully this will avoid future troubleshooting for other people.

[YuriSizov]

Should we consider this closed now?

[clayjohn]

Should we consider this closed now?

I think so. Its clear now that the current behaviour is intended for the ParticlesProcessMaterial, and now its documented as well.

If someone really wants to add emission color into the ParticlesProcessMaterial, we should encourage them to open a proposal with a clear description of what behaviour they want.