GPUParticles3D collision point is unpredictable depending on particle collision speed

[derkork]

Tested versions

v4.2.2.stable.mono.official [15073af]

System information

Godot v4.2.2.stable.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4080 (NVIDIA; 32.0.15.5599) - AMD Ryzen 9 7950X3D 16-Core Processor (32 Threads)

Issue description

If have set up a GPUParticles3D with a GPUParticlesCollisionHeightField3D collider. The particles are set up to hide on collide and spawn a subemitter on collision. The idea behind it is to simulate rain drops creating splashes when hitting the ground. To keep things simple we use a flat piece of geometry as ground. The particles spawn in a ring shape with 0 height from 20 m above the ground and are only affected by gravity. So each particle should travel at the exact same speed when it hits the ground. Now please regard the following video:

2024-08-14_07-52-11.mp4

We can immediately see that by default the particle collision point is below the ground. I switched the view to orthogonal so it is easier to see. At least all particle collision points seem to end up at the same y position, so I thought this is some kind of tunneling issue where the 30fps framerate isn't enough to keep up with the particle speed and hence the colllison is detected inside the ground. So I increased the collision base size to compensate for that and 1.1 meter makes it so that the particles look like they properly collide with the ground.

Now this is already the first problem. How much I need to compensate depends on the speed that the particles have when they hit the ground (and a few other variables as we will see). So if I want some variety to my rain and some particles should move a little faster than others, there is no way I can have all particles collide at the same plane because the collision point is unpredictable with randomized speeds.

Now I increase the amount of particles in my particle system to 500 and then to 5000. I would expect that this has no impact on where the collision point of the particles is. They all still travel at the same acceleration from the same height so they shoudl have exactly the same speed when hitting the ground and my 1.1m compensation should still work. But it doesn't. Instead the collision points randomly vary by about 1 meter in height, which should absolutely not be the case.

Now I try to increase the FPS of the particle system. When I increase it to 60 now my particles all collide way above the ground, so my compensation is too much. But they still don't collide at the same height but in a band of roughly 0.5 meters. If I use 0 FPS which basically is "as fast as possible", the band narrows but still isn't at the same height and is still above the ground. Finally I reduce the amount of particles back to 50 and suddenly no more subemitters are spawned at all.

This unpredictable behaviour makes it next to impossible to use subemitters on impact in a meaningful way.

Steps to reproduce

Using the supplied reproduction project, open collision_offsets.tscn and repeat the steps shown in the video.

Minimal reproduction project (MRP)

reproducer.zip

[derkork]

Another interesting observation: in the test project disabling "Fract Delta" seems to improve the collision situation quite a bit:

2024-08-14_20-25-09.mp4

The particles look strange though with this setting disabled. I tried this workaround in my more complex main project, there disabling fract delta seems to be no improvement at all:

2024-08-14_20-28-16.mp4

The behaviour is seemingly random.

[Calinou]

The behaviour is seemingly random.

How many FPS do you get in the editor in your main project and minimal project respectively? Use the View Frame Time option in the Perspective menu of the 3D editor viewport to check.

[derkork]

Minimal project:

Main project:

That was surprising, but i found that using spheres in the emitter of the minimal project cost of a lot of framerate. When I change the particles to boxes, then I get a lot better framerate in the minimal project and the fract delta trick continues to work.

2024-08-15_07-13-51.mp4

[Calinou]

That was surprising, but i found that using spheres in the emitter of the minimal project cost of a lot of framerate. When I change the particles to boxes

SphereMesh has a lot more vertices than BoxMesh. Reducing SphereMesh's vertex count by reducing its subdivision count in the mesh properties should bring performance closer to BoxMesh. For particles, you can often get by with a much lower subdivision count since they're small.

[derkork]

Is there any particular reason you wanted to know the frame timings? Some idea what may cause the problem?

[Calinou]

Is there any particular reason you wanted to know the frame timings? Some idea what may cause the problem?

I was expecting the issue to be dependent on the actual rendered FPS (which is common for this kind of thing), and the results seem to confirm my suspicion here.