Page MenuHome

Mesh Edit: preserve Custom Normal vectors in topology operators.
ClosedPublic

Authored by Alexander Gavrilov (angavrilov) on Jun 2 2019, 12:28 PM.

Details

Summary

Mesh Edit: preserve Custom Normal vectors in topology operators.

Custom Loop Normals are normally encoded relative to the default
normals, similar to normal maps, allowing them to naturally follow
mesh deformations. Changes to mesh topology however often result
in nonsensical effects that are not desired.

The Remove Doubles operation especially (now known as Merge By
Distance) is intended as a purely topological operation, and
definitely should not change the vector of the custom normals.

This patch implements that behavior by converting the relative
encoding into an absolute vector layer for the duration of the
operation. It also modifies other Merge types in this way for
consistency, the Rip operator as their inverse counterpart;
and also Dissolve, Connect Path and Knife operators as other
examples more related to topology than shape.

On the technical side, this ports mesh_normals_loop_custom_set
to BMesh, and then uses a temporary Custom Data layer to store
the normals as vectors for the duration of the above mentioned
operations. When the normals are converted back to custom data,
the caller can choose whether to mark edges as sharp to preserve
distinct normals, or just average them instead. All but Remove
Doubles choose to average for now.

Diff Detail

Repository
rB Blender

Event Timeline

Bastien Montagne (mont29) requested changes to this revision.Jun 3 2019, 5:23 PM

Custom Normals: when forcing smooth fan clnors together, average in 3D.

It seems the code is designed to force all custom normals associated
with a smooth fan to be the same. Not touching on that design decision,
this fixes the code to average in 3D space, because averaging normals
in polar coordinates produces weird results.

I wonder whether your solution is really better, since you evaluate the clnors using another clnor_space than the one used to create them. Did you actually found a real difference (as in, worse/better) in results here?
Further more, that averaging of 'polar' clnors values is expected to be used only to solve very small divergences due to numerical errors or so, not to fix widely different clnors - this would be a bug and not an expected behavior, as you said, all clnors in a same clnor_fan should have same value, since it defines a single normal… Did you actually encounter such case with existing code?

In fact, I have the feeling that you are using that code in a weird unexpected way, BM_custom_loop_normals_from_vector_layer() seems way to simple to me, think you should check what mesh_normals_loop_custom_set() is doing. It first computes existing clnors fans, then detects the ones that are no more valid and need splitting (because the custom normals in it are not matching anymore), sets relevant edges as sharp to create new fans as needed, then recomputes again all clnor_space fans, and finally sets the new custom normals… That’s how the few modifiers supporting custom normals handle topology changes currently, e.g.

Note that that patch would need to wait for after 2.80 release anyway…

This revision now requires changes to proceed.Jun 3 2019, 5:23 PM

I'm not sure mesh editing operations that are not in any way related to shading should suddenly start setting edges to sharp (there are arguments both way, especially for remove doubles; could be an option, or maybe differ per operator?), so I let it assign 'incorrect' normals and rely on that code to average them out, but in a sensible way.

Remplemented by porting a version of mesh_normals_loop_custom_set to BMesh.

Patch LGTM now, unless @ideasman42 wants to have a look think you can commit it.

This revision is now accepted and ready to land.Mar 24 2020, 2:54 PM

hi, is there any news with this patch? it would be really handy to have a solution for the custom normal's issue during merging.