Merged 39990:42605 from trunk (arf!)
Merged 39990:42605 from trunk (arf!)

second round (don’t know what happened???).
Adding optionnal weight preview in Weight Paint mode (code inspired by Dynapaint one).
Also re-enabled the eModifierTypeFlag_SupportsMapping flag, as it seems to not crash anymore (???).

And finally, done some minor style editing...
Minor fixes for weight preview.
Merged with trunk (42606:42684).
Merged from trunk -r42685:42821.
On second thought, also enable weight preview in object mode, like for DynamicPaint. This commit also generalizes/factorizes the way that feature (CD_WEIGHT_MCOL preview in object mode) is handled:
* Adding in BKE_modifier.h "int modifiers_isWMColPreview(struct Object *ob);", which checks whether there is a modifier in the object's stack that needs WEIGHT_MCOL preview. This higly simplifies the code in draw_mesh_fancy() (drawobject.c).
* Adding in BKE_modifier.h "int modifier_usesWMColPreview(struct ModifierData *md);", which checks whether that modifier needs WEIGHT_MCOL preview. Used among other places in mesh_calc_modifiers() (DerivedMesh.c) to make sure preview mask remains for following modifiers.
* Adding the new flag "eModifierTypeFlag_UsesWMColPreview" for those modifiers, used by above functions to make a first, quick check.
Merged from trunk -r42822:42826.
Why in hell rename of blenderbuttons in blender_icons.png wasn’t catch by merge???
Now using weightpaint instead of weight_to_rgb for modifier weight preview. This allows custom weight colorband to be used. Not sure we can go higher in weightcol compute here (i.e. imho, handling multipaint and co is not good idea here, and would add many complexity...). Maybe we should also move other uses of weight_to_rgb to weight_paint (particles, some drawing code), and thus remove weight_to_rgb from header?

Thinking about Campbell's remark about DynamicPaint and WeightVG modifiers' weight preview not using advanced weights preview generation from DerivedMesh.c, I mumbled and tried to design a proper way to manage those weight-editing modifiers in WP mode. Previously (in this branch), DynaPaint had no effect (as it did not have eModifierTypeFlag_SupportsMapping flag, I wonder why???), and WeightVG were always drawn. Not nice. So I coded a three-states "weight preview mode": original weights and final modified weights (both using full weight preview, included multipaint), and modifier weights, same result as in 3D view (or same as original if no weight preview generated by modifiers).

All this obviously will need discussion & approval!

Also restored eol-style prop of weightvg modifier files (grrrr, merge...).
Merged from trunk (-r 42826:42849).
Previous commit was not working as expected, except in some specific cases. So I had to change things a bit, and add a new "flags" memeber to DerivedMesh struct. For now, it only holds a DM_MOD_DO_WMCOL flag indicating to DynaPaint and WeightVG modifiers whether they should do weight preview or not (specifically, only in Object mode, or WP mode when modifier preview is enabled)!

As far as I can tell, it now works fine (and I’m quite happy with the viewing possibilities in WP mode), but not sure it is OK to edit such core struct for this? Will have to poke main devs… :)
Merged from trunk (-r42849:42864)
Ooops! Forgot to add "md control" on weight preview in WeightVG Edit and Mix modifiers...
Merged from trunk (-r42864:43015)
Merged from trunk (-r43015:43033)
merged from trunk (-r43033:43210)
Merged with trunk (-r43210:43491).
Heavily refactored the "weight preview" code:
* Removed "preview modes" from 3DView in WPaint mode.
* Made preview even more "generic code". Note however current solution to control whether a given modifier is authorized to compute preview or not is most probably wrong currently, will need another solution (prob. affecting all modifiers' code).

-----

Here is a new version of the patch.

I addressed most of your advices, with one exception: imho, setting CD_WEIGHT_MCOL from the main modifier evaluation code (in DerivedMesh.c) is not a good idea, and is not even doable, at least for DPaint VCol preview. There would also be the problem of determining which vgroup’s weights to preview (modifier one might be different from current active one). Not to mention that a modifier might want to output something else than just a single group’s weights (I already have on my hdd a new weight modifier that uses a more complex preview option…).

So, I think the modifier should keep the responsibility of preview compute, and hence be aware whether it is authorized to compute a given type of preview (in WPaint mode, we want weight preview, but not VCol preview!). In current code, I added two more temporary flags to md->mode, but I’m quite aware this is not a good solution.

Which leads me to that proposition: I’d like to replace the useRenderParam, useCache, useDeform, etc. params passed to the exec modifier functions by a single flag one, which would allow much more flexibility to main code to control each modifier’s behavior.

Obviously, this would be a huge change in modifiers code, to be done on its own (and before applying that patch!). Not sure whether we want to do that kind of things with bmesh narrowing to merge point?

As a side note, as suggested by miikha, we should also rename CD_WEIGHT_MCOL to something like CD_PREVIEW_MCOL... another big patch, but that can wait later.
Merged with trunk (-r43491:43541).