[Bf-committers] questions about particles and collisions

Lukas Tönne lukas.toenne at gmail.com
Wed Jun 1 11:18:26 CEST 2016


Hi David,

Generally one problem with particle systems is that their updates are
inseparable from the emitter object update, due to the old depsgraph
only doing one update function call per object. This means that
particles cannot rely on the emitter mesh to be valid, especially when
the emitter is animated or part of a more complex setup with rigs and
constraints. The usual approach i believe is to make a copy of the
emitter mesh and use that independent object as a collider. Your test
case seems to cover only a static emitter, in which case it might just
work.

The penetration issues at emission time are tricky. Collision
algorithms (at least "real" collision systems beyond the simplistic
mesh-sphere collision in particles) usually assume that you start with
a collision-free state, and only then can guarantee
collision-free-ness in the next iteration. So if you particles start
too close to some collision object (not necessarily "the emitter") one
has to cheat and disable collision until they are free (for example:
water particles in a fountain, emitted in a tight tube and spraying
out).

*How* to avoid this initial collision exactly should be up to the
(technical) artist IMO. The easiest and most controllable way, i would
guess, is to just use an "inactive" time interval after emission. OTOH
making it an automatic feature would probably not work in more complex
cases, and may even break existing setups. For example: what if
artists placed a bunch of marbles carefully on a table, so that they
are in collision right away and correcly so? Then starting with
disabled collision at the beginning would break it and the marbles
would fall through the table before their collision gets activated
again. I think it's more transparent to add collision on/off animation
as a little optional feature, and less likely to create more trouble
in the fragile particle system code.

Regarding the collision modifier: the ordering of psys vs collision
modifier probably only makes a difference in the animated case. Then
the movement information in the collision modifier should be updated
before the particle system accesses it, so the collision should go
*before* the psys. In the static case this would be irrelevant.

Hope this helps. Best regards,
Lukas

On Tue, May 31, 2016 at 12:14 AM, David Jeske <davidj at gmail.com> wrote:
> Quick update.
>
> I have particle / emitter self-collision working, at least in my quick
> test. Here is a test showing an emitter surface with both a collision
> modifier and a particle system.
>
>   https://www.youtube.com/watch?v=2WUeFGY4Rlg&feature=youtu.be
>
> What I did was introduce a new particle state during the beginning of a
> particle lifetime, PARS_BIRTHING, during which it does not collide. They
> switch to PARS_ALIVE as soon as they are not colliding with anything. This
> prevents particles from colliding with their own emitter while they are
> spawning. Kill particles now also works correctly.
>
>
> https://github.com/jeske/blender_hacking/commit/d9a96cbcf3915eda1e9b4b49437539fd52adf689
>
> At this point, I'm doing more testing, and trying to figure out if this
> unintentionally breaks anything. It seemed a rather easy change to make, so
> I'm suspicious that there is a deeper reason particle/emitter
> self-collision is disabled.
>
> Can anyone think of a reason this is not a good thing to do?
>
> Here is a little more background...
>
> My new BIRTHING state ignores collisions with any object, not just the
> emitter. I struggled to think of a scenario where this is bad, since
> birthing a particle into a collision state seems both highly unlikely, and
> might cause unwanted instability. Can anyone can think of a reason this is
> generally bad, and why BIRTHING should be restricted to only ignoring
> collisions with the emitter? If so it could be changed to do that instead
> (the code for this will just be a more complicated).
>
> My patch appears to work whether the collision modifier is before or after
> the particle system, though I didn't yet test for subtlety. As a user, I
> think I would expect the collision modifier before the particle system to
> mean particles only collide with the emitter, and after the particle system
> to mean the particles collide with the emitter and other particle system
> particles. I don't know how feasible this is.
>
> Interested in any feedback.
>
>
>
>
> On Mon, May 30, 2016 at 11:31 AM, David Jeske <davidj at gmail.com> wrote:
>
>> I am trying to understand why particles (emitter and hair) ignore
>> collisions with their emitter objects, even if the emitter has a collision
>> modifier. (because this is very inconvenient)
>>
>> I'm starting with emitter particles, because the situation there is
>> simpler and uncovers some of the challenges.
>>
>> It seems like at least at some point someone thought particle-to-emitter
>> collisions should work, as evidenced by this code in particle_system.c,
>> collision_detect(). It is trying to prevent particles from colliding with
>> their emitter too early in their lifetime. (afaik this code currently does
>> nothing, because the emitter will never appear in the collision list, see
>> next)
>>
>>    for (coll = colliders->first; coll; coll=coll->next) {
>>        ...
>>        /* particles should not collide with emitter at birth */
>>        if (coll->ob == col->emitter && pa->time < col->cfra && pa->time >=
>> col->old_cfra)
>>             continue;
>>
>> I can see that normal emitter particles ignore collisions with their own
>> emitter object because of this code-line in
>> particle_system.c:dynamics_step(). The second parameter (sim->ob) causes it
>> to skip itself when constructing the collider list.
>>
>>    sim->colliders = get_collider_cache(sim->scene, sim->ob, NULL);
>>
>> If I change the second parameter to NULL, it (may) include itself in the
>> collision list (if it has a collision modifier)
>>
>>    sim->colliders = get_collider_cache(sim->scene, NULL, NULL);
>>
>> Then placing a collision modifier on a particle emitter seems to cause the
>> particles to collide with their own emitter -- although there are some
>> issues.
>>
>> One issue is that some particles appear to collide with the emitter at
>> birth (they emit opposite the normal), suggesting the first code-snippet is
>> insufficient to prevent this problem.
>>
>> Another problem, is that if the emitter-collision-modifier is set to kill
>> particles, the first particle it kills seems to kill the entire particle
>> system. (see [1] below)
>>
>>
>> Are these the only two issues, or are there other problems?
>>
>>
>> I'm trying to figure out if this is reasonably fixable, or if it is just a
>> "bad idea" to pull on this thread. For example, is there something about
>> particles colliding with their own emitter that violates some expectation
>> of the modifier stack? Or is this simply a matter of coming up with
>> appropriate solutions to the odd cases and data interactions so it works
>> properly?
>>
>> ---
>>
>> [1] On a related note, at ...
>> https://wiki.blender.org/index.php/Dev:Source/Physics/Collision_Modifier
>>
>> It says:
>>
>>      The collision modifier safes the position of the vertices
>>     of the object at the corresponding position on the modifier
>>     stack. It does this for the current and the last position
>>     using GLOBAL coordinates. The data is only valid as long as
>>
>>       * you don't skip ahead/back several frames
>>             [TODO: should be enhanced later]
>>       * the number of vertices don't change on the
>>         modifier stack.
>>
>>
>> Is this related? Does the particle death kill the collision 'safe' (seems
>> like it would, though i don't understand why this would kill the particle
>> system)? Does a vertex-count-change invalidate the collision modifer 'safe'
>> even when verticies are added "after" the collision modifier in the
>> modifier stack?
>>
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list