[Bf-committers] particle + mirror modifier bug

[Oliver Mangold]

Hi,

thanks you very much for taking the time to explain.

After more checking of the behavior with or without using dm_deformed, I understand things somewhat better.

- I believe what you mean with 'use modifier stack' in combination with subsurf not working well is, that generative modifiers garble the face indices, so changes like switching the modifiers on/off or changing subdivision level will result in the hair being a complete mess. Correct?

- What surprised me a little, though, was that disconnect/reconnect will result in garbage also in the presence of generative modifiers, *without* 'use modifier stack' enabled. E.g. for subsurf the hair will be attached at the location of the original mesh, leaving a gap.

- I found, when using dm_final instead of dm_deformed, both with and without 'use modifier stack', the hairs are placed nicely after a reconnect, but in both cases, they seem not to be attached correctly. This will only become visible after deforming or moving geometry around.

- Only got a rough understanding about the latter problem. The culprit seems to be this:

    tpa->num_dmcache = psys_particle_dm_face_lookup(target_dm, dm, tpa->num, tpa->fuv, NULL);

  As far as I get it, psys_particle_dm_face_lookup() doesn't do the right thing then. The other place, where this is used, psys_calc_dmcache() in source/blender/blenkernel/intern/particle_system.c, seem to have a special treatment for the case of 'use modifier stack' enabled.

Best regards,

O.

> Hi,
> 
> By default for hair, it is attached to the original mesh before modifier
> stack evaluation, referencing one of the faces in the original mesh. The
> advice is generally to apply the mirror modifier before starting hair
> editing.
> 
> In your file the "Use Modifier Stack" option is enabled, which attaches the
> hair to the mesh after modifier evaluation. This makes it work for the
> mirror modifier (but will not work so well in other cases like subsurf
> which is why the option is off by default).
> 
> The bug seems to be that the disconnect/reconnect hair operator does not
> take into account this "Use Modifier Stack" setting, in that case it should
> use the final mesh instead of the deformed (original) mesh.
> 
> Regards,
> Brecht.
> 
> 
> 
> 
> On Sun, May 27, 2018 at 7:35 PM, Oliver Mangold <o.mangold at gmail.com> wrote:
> 
> > Hi,
> >
> > I would like to fix a bug, concerning disconnect/reconnect of hairs on an
> > object with a mirror modifier. I already reported it (
> > https://developer.blender.org/T54488), but now I also dug a little into
> > the relevant code. My findings are, that in the function
> > remap_hair_emitter(), which does the main work of reconnecting hair to the
> > mesh, there is a weird case decision
> >
> >         if (target_psmd->dm_final->deformedOnly) {
> >                 /* we don't want to mess up target_psmd->dm when
> > converting to global coordinates below */
> >                 dm = target_psmd->dm_final;
> >         }
> >         else {
> >                 dm = target_psmd->dm_deformed;
> >         }
> >
> > where in my tests the second branch is taken, thus dm_deformed is used for
> > the further steps, in particular to build the BVH which is used to search
> > for the nearest face to connect the a hair to.
> >
> >                 bvhtree_from_mesh_get(&bvhtree, dm, BVHTREE_FROM_FACES,
> > 2);
> >
> > It seems that in dm_final the mirrored faces are present, while in
> > dm_deformed they are not. Thus was happens is, that the hair on the
> > mirrored side get connected to the nearest point of the nearest unmirrored
> > face. The problem goes away when removing the case decision and always
> > using dm_final. Checking the history, once it worked that way, and was
> > changed to the current situation in this commit:
> >
> > commit 0666de06f3119ff1640f1eb66833cd4feb669209
> > Date:   Thu Jan 15 18:15:52 2015 +0100
> >
> >     Fix for particle system copy: This has to make sure the ORIGSPACE data
> >     layer is available.
> >
> >     Otherwise particle mapping to the new mesh cannot work with subdivided
> >     and constructively-modified meshes.
> >
> > I have to admit, that I got lost at that point. I'm not familiar enough
> > with the code yet, to understand what really is the idea behind selecting
> > dm_final or dm_deformed, and what problem exactly was fixed by that. Would
> > be great if someone could explain. How can this bug be fixed without
> > breaking the fix of the commit above?
> >
> > Best regards,
> >
> > O.
> > _______________________________________________
> >