Implement collision in CPUParticles as a more precise (but slower) alternative to GPUParticles collision #3865
Comments
|
I've started work on CPUParticles3D collision: https://github.com/Calinou/godot/tree/cpuparticles-add-collision However, I get a crash whenever a particle collides with a StaticBody. Testing project: https://0x0.st/oaO_.zip (will crash as soon as it's opened in the editor, since a particle will collide with the box below it) Backtrace – Step [11] is the one in the code I added: |
|
Reading through godotengine/godot#61273 it sounds like the reason this stalled was a lack of support for structs in GDScript. Now it seems that structs may not be too far off: #7329. Hopefully work on CPUParticles signals and collisions can resume soon! Would love to have these features in the projects I'm planning. |
|
I've continued work on https://github.com/Calinou/godot/tree/cpuparticles-add-collision?rgh-link-date=2022-05-22T00%3A08%3A17Z. It now has feature parity with GPUParticles3D collision, though the Collision Use Scale property isn't implemented yet. Collision masks also haven't been implemented yet, although this should be easy to do. simplescreenrecorder-2023-08-10_12.58.56.mp4There's also an issue where particles occasionally sink into the ground due to gravity (despite my best efforts to prevent this), and collisions failing if a single particle hits multiple overlapping boxes at once. I've tried increasing the number of contacts reported by the shapecast, but this didn't fix the issue. Testing project for the above branch: test_cpuparticles3d_collision.zip |
|
Wasn't sure if I should post this here or in godotengine/godot#61273. But thanks for continuing to work on this feature! I substituted Godot Jolt into a build of your engine changes to try to isolate behavior of your code vs built-in physics engine quirks. Particles appeared to clip through surfaces more frequently with Jolt, so I had a hard time determining if the gravity issue or overlapping shape issue persisted. It seems that particle simulation stops much more often because Jolt is causing more frequent clipping. However, I did notice a problem with collision that occurs consistently, both in Jolt and Godot Physics. Here I've switched back to Godot Physics and slowed down the time scale to make this more apparent: unknown_2023.08.10-23.30.mp4Notice how the particles mostly pass through the underside of the green shape before collision occurs. It almost seems like they are colliding with the back face of the surface. I also noticed some slight clipping with the orange shape, but zero with the blue shape. Note that the green shape is an exact duplicate of the other shapes with a different material override. In fact, I can reposition the emitter to drop particles on the "top" side of the green shape, and collision behavior changes: unknown_2023.08.10-23.38.mp4When I reposition the emitter to the underside of the perfectly horizontal blue shape, particles clip entirely through the surface before collision occurs. From the top side, the opposite is true and no clipping occurs whatsoever: unknown_2023.08.10-23.52.mp4I believe this behavior is connected to the individual face normals of collision shapes. This may also be linked to the issues observed with gravity and overlapping boxes. I will play around more with this when I have time. |
This occurs because the raycast destination is moved to account for gravity, so that particles don't sink on the ground. This could be avoided by performing more raycasts, but it would be significantly more expensive to do so (up to 6 raycasts needed per particle, instead of 1). There's some commented out code you can uncomment here if you want to try this: Calinou/godot@2cda412#diff-778bdd2be9e69834044d9ca57a2341cafd149c69e5d48f1b1a98321e93adb4bcR965-R1008 |
Describe the project you are working on
The Godot editor 🙂
Describe the problem or limitation you are having in your project
GPUParticles collision works well, but it requires specially designed nodes to be placed within the level to function. Not only this can take a significant amount of time in complex levels, but the level of precision remains fairly low.
Moreover, since GPUParticles cannot communicate their positions back to the CPU efficiently, it's also impossible to emit a signal on collision with individual particles' positions (or when a particle expires). Emitting a signal on collision allows for many new effects, such as creating meshes, lights or decals at particles' impact points.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Implement precise collision for CPUParticles using the physics server. This is meant to be an alternative to GPUParticles when a high level of precision is needed. Due to the higher CPU usage, this will be limited to low amounts of particles (in the few hundreds at most).
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
CPUParticles collision performance is expected to be better than when using nodes to simulate particles (or even when using low-level servers from scripting), but it will still be significantly slower than GPUParticles.
To reduce CPU usage, collision between particles should be disabled by default. Nonetheless, since the physics server makes this possible, there should be a property to enable particle-to-particle collision (which is another feature that can't be efficiently implemented on GPUParticles).
To further reduce CPU usage, CPUParticles simulation could be made to happen at a lower rate with interpolation. Support for this will require something similar to #439.
If this enhancement will not be used often, can it be worked around with a few lines of script?
No, as CPUParticles behavior is not extendable from the scripting API.
Is there a reason why this should be core and not an add-on in the asset library?
This is core rendering functionality.
The text was updated successfully, but these errors were encountered: