Particles refuse do deform properly... On one side only [SOLVED!]

Support Particles and Physics Simulations
1

Hey guys,
I’ve asked this in blender stack exchange as well but it seems like no one there can figure this out…
If any of you can help:

I have a female mesh that is placed centered on the world origin with all transformations applied.
That mesh is symmetrical, with no active mirror modifier.

The metarig (Pitchypoi rigify) is setup symmetrically (used x mirror at first, then symmetrized it, reset the bone roll and applied all transformations).

The eyelashes are “growing” out of small skin-patch particle emitters.

The particle emitters are snugly placed on the eyelids of the mesh and are set to invisible.

The eyelash emitters are all separate meshes, there are 4 of them, two identical pairs. A pair of upper and a pair of lower lashes (Shift+D, Ctrl+M then X for X axis mirror, then applied all transformations).

The emitters are parented to the rig (auto-generated by addon-script) with automatic weights.
The armature modifier is set Above the Particle in all meshes.

The issue is that when I move the eye control bone the Right-Hand (Left side of pic) moves perfectly fine. The eyelashes move with the lids and the emitter, all in perfect sync, they stick together and work wonderfully… while the Left-hand (Right side of pic) emitter and particles seem to have a greater amplitude of movement, they detach, and float around even though the body mesh (the lids) deforms symmetrically on both sides.
I can only assume that it’s a weight issue but I can’t locate it. It’s all auto generated on identical and symmetrical meshes with one side working and the other not…

I’ve tried moving the eye control bone up via G then Z, straight up the Z axis, in order to avoid any asymmetry and view the problem in Front Orthographic. What I got is attached below:

1915×989

The floating emitter is highlighted in yellow. If anyone has any idea where I could look for the reason why one emitter stays in place while its copy floats around with a greater motion amplitude I’d be very grateful

Edit: Blender version 2.82a. But the same file causes the same issue in 2.83 LTS. The LTS version takes a longer time to save so I use 2.82a.

Edit 2: I’ve tried “breaking” the other side by deleting the working emitters and duplicating the “broken” ones. I’ve symmetrized the mesh and metarig from the broken side to the working one too. I’ve tried new emitters altogether. But the problem remains only on one side (-x side or the Right side if you look at it from the POV in the screen shot). So duplicating the issue to the working side… Seems impossible.

I can’t fix the problem nor recreate it on the other side.

Edit 3: I managed to get it to work on the broken side by converting the hair particles into a mesh but this is very undesirable because:

  1. The mesh hair causes a drop in performance (increases RAM consumption and even though I have 32 gb, I still don’t want to cause unnecessary loads).
  2. It does not accept the material (instead always displaying the new mesh-strands as pitch black).
  3. It is still inferior to the particle system that does deform properly.

Does that mean it’s a bug in the software itself? I have not changed anything except converting the particles into a mesh. Same rig, same meshes, same weights… If I parent the particle system AND the new mesh system together: the particle one still floats around when I move the bones that govern it…

Note: On a side note I’d also like to ask why in viewport shading light does not penetrate into the mesh while in Eevee render preview it does (cavities and orifices have light in them)? I know I’ve ticked something but idk what…

THANKS!

2

Rule 1, symmetrize is funky, never trust it. You can only trust a mirror modifier.

If the lower eyelash is a separate object you are better off choosing a single bone to parent it to, rather than weighting it. You select the bone you want in pose mode, switch back to object mode, select the eyelash emitter and shift select the armature and then Ctrl P choose ‘bone’

As for the cause, maybe a rogue very floating in space causing Weights to fail. Select a single very in emitter, Ctrl L to selected connected, Ctrl I for inverse, are any verts selected (look at very count lower right) if do delete and re weight.

But you pretty much never want to use symmetrize.

1 Like
3

The other issue you can have is when you use a mirror modifier on an object, you apply it and then separate by loose parts or by selection, the newly mirrored object inherits the original objects origin which is rarely what you want.

4

I want to be able to deform it in various ways rather than just open and close.
I guess I can try “Bendy bones” (giving a single large bone several segments).

This method did not reveal anything.
The object is a mere 2D stripe of 26 verts in total.
Ctrl+L selects 26/26 and Ctrl+I deselects everything.

I can cut the mesh in half again and just use mirror mod. I will try that now.

I didn’t do that. Just applied it with Clipping ticked on and then merged by distance 0.0001 and it merged the verts that lay on top of each-other on the midline.

Thanks!
I will get back to you with the cutting in half and mirroring.

5

Yeah, post back if that works.

6

Same issue when using a mirror modifier. Nothing’s changed at all.
If I mirror the working side, the emitter on the mirrored side is broken.
If I mirror the broken side, the emitter on the mirrored side is working just fine.

Is it a bug in blender perhaps?
The problem is always unilateral regardless of what I do. Always on the same side. Nothing seems to fix it. New emitters only work on 1 side. Mirror or no mirror, only 1 side works. Applied transformations / not applied, only 1 side works. Copy the broken emitter = the copy works perfectly if it’s on the working side. Copy the working emitter and it’ll break on the opposite side.

I’ll try mirroring the rig now I guess. Maybe it’s half of the rig that is broken for some reason. Even though it all looks perfectly fine.

Edit: Mirroring the rig does not change anything either.
Same side is broken no matter what I mirror.

Edit: I just want the eyelashes to be deform with the lids. On BOTH sides… Anyone?

7

Check the direction of the normals on the emitter it appears as if they are flipped, if so recalculate them (and possible flip) and re weight. If not, tough to say, could you strip down the file delete most of the body/face and post a blend file.

1 Like
8

It says that new users can’t upload attachments.
I worked around this by uploading to google drive.
Here’s the link do the file:
----I took down the link after issue was solved----

The issue is already there. Just open it and move the eye bone.
You’ll see the right (your right) eyelash detach and float while the left is perfectly fine.

Edit: I’ve tried recalculating normals. It destroys the hair particle arrangement but does noting to solve the issue.

Edit 2:
I DID IT!
HERE’S THE SOLUTION TO ANYONE FACING A SIMILAR ISSUE:

Thanks to @Photox 's suggestion I’ve started playing with the normals.

  1. Recalculating them will not work while you’re already attached to the rig with any weights applied. The issue will remain but the particles will get messed up.
  2. If you delete the parenting and the vertex groups, recalculate normals, it will destroy the hair particle arrangement (flipping them inside out and you can’t comb it back to normal).
  3. BUT if you then parent it back to the mesh with new groups and higher weight values it will work just fine… Except the particles will be all messed up.
  4. Well, what did we learn in step 1? Recalculating normals when already parented with weights and groups flips the particles but does not affect the attachment!
    Well if we’ve attached it properly we can now recalculate, flip the particles back to proper position, automatically get the combing back, and the emitter stays firmly attached to the mesh and deforms 100% accurately with the rig!

It seems like I had to trick the system for this solution. Flip something, fix it in place, flip it back.
I hope it helps the people reading this!

Cheers to @Photox for being there for me. You’re king!
Marked your answer as solution. Just needs the extra step.

Untitled
Untitled815×754 584 KB

1 Like