search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
91.48k stars 21.26k forks source link

GPUParticle3D stops rendering in editor under specific circumstances #97680

Open AtlaStar opened 2 months ago

AtlaStar commented 2 months ago

EDIT: more information as to how to properly reproduce this bug have been discovered, and as such updating the reproduction steps.

Tested versions

4.4.dev

System information

Godot v4.4.dev (76a135926) - Windows 10.0.19045 - Multi-window, 1 monitor - Vulkan (Forward+) - dedicated AMD Radeon RX 6650 XT (Advanced Micro Devices, Inc.; 31.0.24033.1003) - AMD Ryzen 7 3800X 8-Core Processor (16 threads)

Issue description

When the Fixed FPS is set to 0 for a GPUParticle3D, the material assigned to it's mesh has billboarding with the keep scale flag enabled, and lastly the ParticleProcessMaterial's Display->Scale setting is set to use a curve which starts with a value of 0, new particles are no longer emitted. Changing between nodes will briefly cause a burst of particles. New particles also seem to spawn while the editor is minimized or briefly whenever a tooltip on any GUI component appears.

Is related to #97621 as the default for a CPUParticle3D's Fixed FPS is 0, so on swapping to a GPUParticle3D, and having a mesh material that has scaled billboarding enabled, the already emitted particles will render as normal but no new particles will be added to the system, which may briefly appear as if the wrong amount of particles are being generated.

Steps to reproduce

As described above:

Minimal reproduction project (MRP)

I have been using the same MRP as was submitted on #97621, which I will include here again. New.Compressed.zipped.Folder.zip

AtlaStar commented 2 months ago

Tried to find a possible solution, but as I am not familiar with the render system I was unable to find the offending area of concern, but the fact materials and particles are both involved, my hunch is possibly a shader is to blame.

AtlaStar commented 1 month ago

Also forgot to note that attaching a visual studio debugger and breaking inside of the particles_storage class showed that the particle count was correct in functions pertaining to setting up the buffers for the render device, which is what led me to believe that the issue exists somewhere in shader land in addition to the fact that certain material properties are required to cause the improper behavior.

AtlaStar commented 1 month ago

More weird behavior discovered; hovering over any GUI element that can update to display a tooltip will briefly cause the particle node to burst some particles while it is in the errored state of not drawing particles.

AtlaStar commented 1 month ago

Making as a separate comment because it is relevant; the original test used as a ParticleProcessMaterial that has a curve assigned to its display scale. This plus a Fixed FPS of 0, and billboarding for the material set to keep scale are all required to display the behavior described if the curve is set to start at a scalar of 0. Working theory is that when the fixed FPS is set to 0, interpolation over the curve does not occur, and that the keep scale setting used for billboarding is required to be set in order for the processing material to utilize the curve

AtlaStar commented 1 month ago

Alright, so I found that something about the previously mentioned series of events is causing the M11 minor of each particles transformation matrix to all be set to NaN

FireCatMagic commented 1 month ago

Thanks for all of this, it seems like you found the real issue that was causing my issue

AtlaStar commented 1 month ago

Yeah, it is a tricky one and basically a perfect storm of multiple things that are all required in order to cause the issue. Trying to find a more permanent fix but having trouble figuring out where the transform data is being modified to NaN since the buffer where those values exist is opaque in the visual studio profiler and only shows as an ID.