Page MenuHome

Fix T68499: weight paint gradient is broken with generative modifiers

Authored by Philipp Oeser (lichtwerk) on Wed, Nov 20, 9:11 PM.



Caused by rBac442da4a14d.

Above commit tweaked the logic to not only early out, but also set the
WPGradient_vertStore screen coord to FLT_MAX in case this original index
was visited before [gradientVertInitmapFunc].
For generative modifiers though, we might get here multiple times for the
same orig index, resulting in a valid orig index being made invalid for
mapFunc [which would early out in case of FLT_MAX].

Restored original logic, so that setting FLT_MAX only really happens
when it should: when ED_view3d_project_float_object fails...

Diff Detail

rB Blender

Event Timeline

Jacques Lucke (JacquesLucke) added inline comments.

Does it make sense to also call BLI_BITMAP_ENABLE(grad_data->vert_visit, index); here?

This revision is now accepted and ready to land.Thu, Nov 21, 10:13 AM

I would vote for: No.

Again: we could come here multiple times and with coords from verts generated by generative modifiers.
If we would 'Mark this check as Done' just because any of these verts associated with the orig index fail, we would miss to catch the ones that are valid later...

For example, this would fail for situations like these (part of any array-modifier plane clipped by viewport clipping):


P.S.: not saying that doing weight paint gradients on modifier generated verts is nice atm (I think we could be better here), but that is another story... :)