2.77a hair mesh collisions don't work for emitter object #48535

New Issue

David Jeske · 2016-05-28T08:08:14+02:00

David Jeske commented

2016-05-28 08:08:14 +02:00

System Information
windows10, NVidia GTX 970

Blender Version
Broken: 2.77a abf6f08
Worked: ??

Short description of error

When using hair/mesh collision detection, particles ignore the emitter mesh.

Exact steps for others to reproduce the error

Load this blend

https://dl.dropboxusercontent.com/u/428467/hair_mesh_collision_1.blend

select "emitter object", goto particle properties, cache subpanel
click "bake"
WITNESS: scrub the baked frames, and witness the hair collides with the "test collider", but not "emitter object" (both of them have collisions turned on)
EXPECTED: the particles to correctly collide with the "emitter object"

Note: if you duplicate "emitter object", delete the particle system from the copy, and re-bake the simulation, the hair will correctly collide with the duplicate of emitter object.

**System Information** windows10, NVidia GTX 970 **Blender Version** Broken: 2.77a abf6f08 Worked: ?? **Short description of error** When using hair/mesh collision detection, particles ignore the emitter mesh. **Exact steps for others to reproduce the error** 1) Load this blend https://dl.dropboxusercontent.com/u/428467/hair_mesh_collision_1.blend 2) select "emitter object", goto particle properties, cache subpanel 3) click "bake" 4) WITNESS: scrub the baked frames, and witness the hair collides with the "test collider", but not "emitter object" (both of them have collisions turned on) 5) EXPECTED: the particles to correctly collide with the "emitter object" Note: if you duplicate "emitter object", delete the particle system from the copy, and re-bake the simulation, the hair will correctly collide with the duplicate of emitter object.

David Jeske commented

2016-05-28 08:08:14 +02:00

Changed status to: 'Open'

David Jeske commented

2016-05-28 08:08:14 +02:00

Added subscriber: @DavidJeske

Bastien Montagne commented

2016-05-29 18:40:43 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2016-05-29 18:40:43 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2016-05-29 18:40:43 +02:00

Bastien Montagne self-assigned this 2016-05-29 18:40:43 +02:00

Bastien Montagne commented

2016-05-29 18:40:43 +02:00

Not sure this has ever been supported? Would need some kind of 'self intersection' option (like e.g. cloth)…

In any case, this is not a bug, rather a feature request - and on a feature that we intend to rewrite from scratch for 2.8…

Not sure this has ever been supported? Would need some kind of 'self intersection' option (like e.g. cloth)… In any case, this is not a bug, rather a feature request - and on a feature that we intend to rewrite from scratch for 2.8…

David Jeske commented

2016-05-30 06:09:21 +02:00

I want to add a few pieces of information.. and ask some questions.

In this case, I wasn't talking about the hair intersecting with itself, which would be analagous to cloth self collision. I was talking about hair colliding with the emission mesh that it spawns from. I would expect if there was a collision modifier in the stack before the particle spawn, that the version of the mesh sent to the collision modifier would be available for the particle system to collide against.

The particle tools (comb etc) seem to have no problem doing collisions between the particles and the emission mesh to prevent particles from interpenetrating the emission mesh.

Hair is often spawned from a character model. Using hair dynamics for long hair requires the ability to prevent the hair from interpenetrating the character model it spawned from, which is the emission mesh.

If you still think this is a "feature request", that's fine.

Here are my questions.... 2.8 sounds a long way off. In the meantime, can you share any thoughts about why this is non-trivial to support today (especially considering the comb tools do it)?

As I mentioned above, I expected that putting the collision modifier in before the particle system would cause that modifier to be processed first, and thus that version of the mesh to be available for collisions in hair dynamics. Why doesn't it work this way? Is there something preventing it from working this way?

I want to add a few pieces of information.. and ask some questions. In this case, I wasn't talking about the hair intersecting with itself, which would be analagous to cloth self collision. I was talking about hair colliding with the emission mesh that it spawns from. I would expect if there was a collision modifier in the stack before the particle spawn, that the version of the mesh sent to the collision modifier would be available for the particle system to collide against. The particle tools (comb etc) seem to have no problem doing collisions between the particles and the emission mesh to prevent particles from interpenetrating the emission mesh. Hair is often spawned from a character model. Using hair dynamics for long hair requires the ability to prevent the hair from interpenetrating the character model it spawned from, which is the emission mesh. If you still think this is a "feature request", that's fine. Here are my questions.... 2.8 sounds a long way off. In the meantime, can you share any thoughts about why this is non-trivial to support today (especially considering the comb tools do it)? As I mentioned above, I expected that putting the collision modifier in before the particle system would cause that modifier to be processed first, and thus that version of the mesh to be available for collisions in hair dynamics. Why doesn't it work this way? Is there something preventing it from working this way?

David Jeske commented

2016-05-30 06:27:50 +02:00

On ... 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? Is the collision modifier information being invalidated when the particle system adds verticies to the derived mesh? Why is it necessary to invalidate the collision modifer 'safe' when verticies are added? It seems like the entire point of the collision modifier is to save the state of the object at that point, regardless of what happens later in the modifier stack.

On ... 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? Is the collision modifier information being invalidated when the particle system adds verticies to the derived mesh? Why is it necessary to invalidate the collision modifer 'safe' when verticies are added? It seems like the entire point of the collision modifier is to save the state of the object at that point, regardless of what happens later in the modifier stack.

David Jeske commented

2016-05-30 19:49:12 +02:00

Considering normal (non-hair) particle dynamics for a moment. Normal particles skip collision checks with their emitter, because of this code in particle_system.c:dynamics_step(). The second parameter (sim->ob) causes it to skip itself when constructing the collider list.

  if (part->type != PART_HAIR)
     sim->colliders = get_collider_cache(sim->scene, sim->ob, NULL);

If I change this to:

  if (part->type != PART_HAIR)
     sim->colliders = get_collider_cache(sim->scene, NULL, NULL);

Then placing a collision modifier on a particle emitter seems to correctly cause the particles to collide with their own emitter in some simple tests.

So this begs the question..

Why do normal particle dynamics specifically ignore the emitter object? Does this cause problems in certain situations? What situations?

Hair particles don't use particle-dynamics, but cloth-modifier dynamics. The cloth code calls also calls get_collider_cache() ignoring itself, and it handles self-collision explicitly. This makes sense for cloth, but I don't see why it needs to be this way for hair. Experimenting with changing this is a bit more tricky, because the cloth sim code doesn't currently know when it's being used for hair sim vs cloth sim.

Considering normal (non-hair) particle dynamics for a moment. Normal particles skip collision checks with their emitter, because of this code in particle_system.c:dynamics_step(). The second parameter (sim->ob) causes it to skip itself when constructing the collider list. ``` if (part->type != PART_HAIR) sim->colliders = get_collider_cache(sim->scene, sim->ob, NULL); ``` If I change this to: ``` if (part->type != PART_HAIR) sim->colliders = get_collider_cache(sim->scene, NULL, NULL); ``` Then placing a collision modifier on a particle emitter seems to correctly cause the particles to collide with their own emitter in some simple tests. So this begs the question.. Why do normal particle dynamics specifically ignore the emitter object? Does this cause problems in certain situations? What situations? Hair particles don't use particle-dynamics, but cloth-modifier dynamics. The cloth code calls also calls get_collider_cache() ignoring itself, and it handles self-collision explicitly. This makes sense for cloth, but I don't see why it needs to be this way for hair. Experimenting with changing this is a bit more tricky, because the cloth sim code doesn't currently know when it's being used for hair sim vs cloth sim.

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

2.77a hair mesh collisions don't work for emitter object #48535