Particle drag values greater than zero can cause particle velocity instability and do not behave as expected. #102093

New Issue

Paul Forgy · 2022-10-27T07:08:20+02:00

Paul Forgy commented

2022-10-27 07:08:20 +02:00

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.15

Blender Version
Broken: version: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: b292cfe5a9
Worked: unknown

Short description of error
Setting the particle properties -> physics -> drag value to greater than zero can cause unstable and unexpected particle velocity. In the test case file, a drag value of .2 causes some particles to have extremely high velocity, while a drag value of 0 produces more consistent and stable velocities.

Exact steps for others to reproduce the error
The test file contains two particle emitters which differ only in their drag parameter settings. Scrubbing the time to frame 3, you can observe the emitter on the left produces several particles which fly outwards at very high velocities, much greater than the emitter on the right with zero drag. I would expect that higher drag values always produce slower velocities, never faster, but this appears not to be the case. This was an issue because the very distant particles produced by larger than zero drag values were causing the sun light shadows not to render, which is another bug/issue demonstrated in this file.

Particle Drag and Sun Shadow Bug.blend

More information in available in the text editor of the sample file. Thanks!

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.15 **Blender Version** Broken: version: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: `b292cfe5a9` Worked: unknown **Short description of error** Setting the **particle properties -> physics -> drag** value to greater than zero can cause unstable and unexpected particle velocity. In the test case file, a drag value of .2 causes some particles to have extremely high velocity, while a drag value of 0 produces more consistent and stable velocities. **Exact steps for others to reproduce the error** The test file contains two particle emitters which differ only in their drag parameter settings. Scrubbing the time to frame 3, you can observe the emitter on the left produces several particles which fly outwards at very high velocities, much greater than the emitter on the right with zero drag. I would expect that higher drag values always produce slower velocities, never faster, but this appears not to be the case. This was an issue because the very distant particles produced by larger than zero drag values were causing the sun light shadows not to render, which is another bug/issue demonstrated in this file. [Particle Drag and Sun Shadow Bug.blend](https://archive.blender.org/developer/F13778472/Particle_Drag_and_Sun_Shadow_Bug.blend) More information in available in the text editor of the sample file. Thanks!

Paul Forgy commented

2022-10-27 07:08:20 +02:00

Added subscriber: @PaulForgy

Edward commented

2022-10-27 10:48:30 +02:00

Added subscriber: @edward88

Edward commented

2022-10-27 10:48:30 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Edward commented

2022-10-27 10:48:30 +02:00

I realized the particle instances and i can confirm that some of the positions have extremely high values, there are also some nan values among them.

Edward commented

2022-10-27 17:18:24 +02:00

This comment was removed by @edward88

*This comment was removed by @edward88*

Paul Forgy commented

2022-10-28 03:18:17 +02:00

I see two issues with the drag force calculation.

I believe the first vector should be normalized:

from: madd_v3_v3fl(force,state->vel, -part->dragfac * pa->size * pa->size * len_v3(state->vel));
to: madd_v3_v3fl(force, normalize_v3(state->vel), -part->dragfac * pa->size * pa->size * len_v3(state->vel));

This error becomes very apparent when the scale/size of the particles becomes greater than 1 and the velocities are high. May not have been readily noticed to this point because the default particle scale is 0.05. For example, a particle system with a velocity of 100, scale of 4 and drag of 0.05, the second frame of the simulation, the particle inherits a very large negative velocity due to the incorrect drag calculation. Drag force should never overcome the velocity but only retard it.

Test file attached. The particle system on the right has drag of 0.05, on the left is 0. Both particles should still have upwards velocity, though the right particle should be slightly slowed over time. Observe that at frame 2, the right side particle already has a negative velocity and is going downwards due to incorrectly high drag force being applied.
Drag force exceeds velocity.blend

Drag increases exponentially with velocity, and that's not represented.
The academic formula is: D = .5 * Cd * r * V^2 * A, where Cd = coefficient of drag, r = air density (can be ignored), V = velocity, A = area.

In this case, the formula should be something like: dragforce = 0.5 * dragfac * velocity * velocity * size * size

or: madd_v3_v3fl(force, normalize_v3(state->vel),**0.5f *** -part->dragfac * pa->size * pa->size *len_v3(state->vel) * len_v3(state->vel));

I see two issues with the drag force calculation. 1. I believe the first vector should be normalized: from: madd_v3_v3fl(force,**state->vel**, -part->dragfac * pa->size * pa->size * len_v3(state->vel)); to: madd_v3_v3fl(force, **normalize_v3(state->vel)**, -part->dragfac * pa->size * pa->size * len_v3(state->vel)); This error becomes very apparent when the scale/size of the particles becomes greater than 1 and the velocities are high. May not have been readily noticed to this point because the default particle scale is 0.05. For example, a particle system with a velocity of 100, scale of 4 and drag of 0.05, the second frame of the simulation, the particle inherits a very large negative velocity due to the incorrect drag calculation. Drag force should never overcome the velocity but only retard it. Test file attached. The particle system on the right has drag of 0.05, on the left is 0. Both particles should still have upwards velocity, though the right particle should be slightly slowed over time. Observe that at frame 2, the right side particle already has a negative velocity and is going downwards due to incorrectly high drag force being applied. [Drag force exceeds velocity.blend](https://archive.blender.org/developer/F13786476/Drag_force_exceeds_velocity.blend) 2. Drag increases exponentially with velocity, and that's not represented. The academic formula is: D = .5 * Cd * r * V^2 * A, where Cd = coefficient of drag, r = air density (can be ignored), V = velocity, A = area. In this case, the formula should be something like: dragforce = 0.5 * dragfac * velocity * velocity * size * size or: madd_v3_v3fl(force, normalize_v3(state->vel),**0.5f *** -part->dragfac * pa->size * pa->size ***len_v3(state->vel) * len_v3(state->vel)**);

Edward commented

2022-10-28 06:54:58 +02:00

Tyvm for your help!
I had a similar thought crossing my mind, unfortunally,
state->vel * len_v3(state->vel) and normalize_v3(state->vel) * len_v3(state->vel) * len_v3(state->vel) is exactly the same thing. :D
I think you are right with the missing 0.5 factor, it just does not seem to be the critical problem here.
But I don't see anything that limits this force. Maybe we should make sure that the maximum force that comes from this is a value necessary to counter out the velocity in one time step. Otherwise it may push back and go loko? Just an idea, not sure.

Tyvm for your help! I had a similar thought crossing my mind, unfortunally, `state->vel * len_v3(state->vel)` and `normalize_v3(state->vel) * len_v3(state->vel) * len_v3(state->vel)` is exactly the same thing. :D I think you are right with the missing 0.5 factor, it just does not seem to be the critical problem here. But I don't see anything that limits this force. Maybe we should make sure that the maximum force that comes from this is a value necessary to counter out the velocity in one time step. Otherwise it may push back and go loko? Just an idea, not sure.

Paul Forgy commented

2022-10-28 10:13:56 +02:00

Thanks for pointing that out. I understand now that normalizing the vector makes no difference and that the formula is simplified.

I think you're correct about needing to limit the drag force. I was trying various things with the physics, and noticed that if I changed the integration type to Euler, the velocity would ping-pong on alternate frames due to the drag. On frame 2 the particle was above the XY plane, frame 3 it was below, alternating each frame and becoming farther and farther away in a runaway condition.

Thanks for pointing that out. I understand now that normalizing the vector makes no difference and that the formula is simplified. I think you're correct about needing to limit the drag force. I was trying various things with the physics, and noticed that if I changed the integration type to Euler, the velocity would ping-pong on alternate frames due to the drag. On frame 2 the particle was above the XY plane, frame 3 it was below, alternating each frame and becoming farther and farther away in a runaway condition.

Philipp Oeser added the

Module

Nodes & Physics

label 2023-02-20 09:38:38 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Particle drag values greater than zero can cause particle velocity instability and do not behave as expected. #102093