Finished heavy refactor of the 'keep sharp' case for weighted modifier now, it will now take all 'sharp edge' factors into account like every where else in code (i.e. sharp edges themselves, but also flat faces and split angle setting of mesh is needed).

I am still a bit on the fence regarding the 'weight' stuff. As far as I understand that code, it is doing some kind of exponential (or inverted exponential) correction, using the sorted list of 'values' to increase or decrease correction factor in relation with the values importance.

I may be wrong, but I have a strong feeling that this is a rather doggy process, not very predictable what importance which face will get in the end (when weight setting is not at its neutral 50 value). I even think that a same (square, so same value for all its loops) face can get different importances for each of its loops depending on surrounding geometry, correct?

Why not simply normalize the face/loop values (for angle it’s dead simple, for face area we'd need to store max area and do another loop to divide by it), and apply basic exponential correction? Or maybe even not normalize them at all, just apply powf(val, corrective_factor) ?

I understand that the current exponential weighting system is incessantly computation intensive. Efficient calculating the corrective factor also needs to be taken into account.

In D2897#73475, @Bastien Montagne (mont29) wrote:

I may be wrong, but I have a strong feeling that this is a rather doggy process, not very predictable what importance which face will get in the end (when weight setting is not at its neutral 50 value). I even think that a same (square, so same value for all its loops) face can get different importances for each of its loops depending on surrounding geometry, correct?

Yes, the face can have different importance for loops dependent on adjacent faces. The current method works very similar to YAVNE.

In D2897#73475, @Bastien Montagne (mont29) wrote:

Why not simply normalize the face/loop values (for angle it’s dead simple, for face area we'd need to store max area and do another loop to divide by it), and apply basic exponential correction? Or maybe even not normalize them at all, just apply powf(val, corrective_factor) ?

One thing I have in mind is to find out avg area of faces around each vert and use the current (poly area / avg area) as corrective factor. With final normal being: Summation (normal[3] * powf(corrective factor, weight))

Hi

I want to comment a few bugs added since @Bastien Montagne (mont29) refactor, these problems don't appear in 9d3ad0eb5af7ab4f3fe28820f1e419e2f69c7cb9

• When you add a weighted normal modifier and activate the sharp edges, in some conditions, Blender automatically add sharp edges in edges that have an angle superior to the autosmooth value. This is unpredictable behavior and the correct behaviour was the original, ignore the angle value from autosmooth and don't add sharp edges to the mesh.
  
  To reproduce the problem: Create a suzanne object > shade smooth > activate autosmooth > enter edit mode > show sharp edges > add weighted normal modifier > activate sharp edges in modifier > go to object mode > enter edit mode

• Face influence have bad behaviours, at least in some triangles. And activate sharp edges give unexpected results in border normals, even when the mesh does not have sharp edges.

In this case the border ngons have weak value and center triangles are medium value (left object). The actual modifier give a strange solution when in triangles, when if you compare with right object with correct behaviour. Also you can compare the difference in the normal of the top vertex of the model when you activate sharp edges, if you compare with righ object (correct behaviour)

And here the behaviour of the modifier before the refactor, with all cases working well.

Thanks for the feedback, fixed the first issue already (easy stupid one, rB3b01edd52e8e).

Still checking on the second one, was introduced by rB93ef006e3c.

OK, second issue is caused by addition of check for too small normal vectors (which typically indicate degenerated cases, and are hence 'reset' to default vertex normal). Think 1e-4f is a bit of an aggressive threshold actually, reducing it to more common 1e-6 value seems to fix reported issue and should probably still be OK. Will commit the change (rB2da3949e26f), thanks again for the feedback.

Thanks to you!

In D2897#128772, @Bastien Montagne (mont29) wrote:

Time to close this, afaik everything has been merged in master last year?

Yes, but i want to remember that the interface to access to all options properly are not created because was removed in 2.8 and it wasnt replace