Page MenuHome

GPencil: Fading for build modifier
ClosedPublic

Authored by YimingWu (NicksBest) on Mar 11 2022, 9:57 AM.

Details

Summary

This patch adds fading support in GPencil build modifier. The weight will be put into selected vertex group for further manipulation using other modifiers like thickness. Support sequential and concurrent building of strokes. Also, a new option is available to specify building starting position using object reference.

See GIF for demonstration:

UI looks like this:

Diff Detail

Event Timeline

YimingWu (NicksBest) requested review of this revision.Mar 11 2022, 9:57 AM
YimingWu (NicksBest) updated this revision to Diff 49162.
YimingWu (NicksBest) created this revision.

Remove compiler optimization hint (debug)

I like a lot this feature, but we need a review of the UI by @Matias Mendiola (mendio) and a full set of test by @Aleš Jelovčan (frogstomp).

source/blender/gpencil_modifiers/intern/MOD_gpencilbuild.c
195

Add point at the end of comments

213

Add point at the end of comments

231

Remove

346

0.0f 1.0f

606

Don't sure about the logic here, but my concern is if you create a weight of 1.0 could this affect other modifiers after build modifier. My guess is that a value of 1.0 has no effect, but it would be good to double check.

Antonio Vazquez (antoniov) requested changes to this revision.Mar 11 2022, 10:10 AM
This revision now requires changes to proceed.Mar 11 2022, 10:10 AM

I had understood wrongly the output weights... I see now that the idea is to generate a new set of weights base on fading... so, generate a value of 1.0f is perfect. I would like to listen the opinions about the workflow and if the parameters and UI are clear enough to communicate the idea of generate weights.

Very nice! Plays incredibly well with other modifiers. I'll notify when I am done testing with all of them

Looking at the UI I think we need at least two changes:

  1. The factor of fade must be above vertex group
  2. Vertex group is only valid if fade is enabled, no? so better disable if fade is 0

Maybe it would be better to add a secondary panel Fade and maybe put a main fade switch. @Matias Mendiola (mendio) what do you think?

YimingWu (NicksBest) marked 5 inline comments as done.Mar 12 2022, 6:43 AM

I made it this way so it deactivates when there's no fading selection. Also from the logic of it, it should be "first select the output then adjust the fading parameter", so the factor kinda stays down?

Maybe a separate checkbox and a panel can be good. But this is also a very simple option. Yeah let's hear from the UI guys

source/blender/gpencil_modifiers/intern/MOD_gpencilbuild.c
606

Yeah I need to assign a default of 1 or otherwise the weight jumps to zero when out of fading range.

@YimingWu (NicksBest) I have not tested the patch but my point is that maybe you just want the fade effect, but not the weight output... I mean, weight output is an advanced feature not used all the times and this is why IMHO factor must be before, but I can be wrong.

YimingWu (NicksBest) marked an inline comment as done.Mar 12 2022, 12:43 PM

Oh now I understood, that's actually a pretty valid point, I see... Then I shall add a few toggle checkboxes to enable "fade opacity" and "fade thickness" and an overall enable thing.

  • Use a separate panel for fading options.
  • Provide options to influence opacity and strength directly without using additional weight output.

Tested latest patch, those new parametric sliders really simplify things. I like the new layout.
The vertex group field could use invert selection option.

Unrelated suggestion:
Concurrent option could also use factor slider to control how many concurrent strokes are being drawn

Concurrent option could also use factor slider to control how many concurrent strokes are being drawn

This might be a bit complex to achieve... hummmm maybe separating them into different layers and stuff?

The Modifier LGTM now, UI is far better now.

I just want to listen @Matias Mendiola (mendio) opinions about UI before approve it.

Matias Mendiola (mendio) requested changes to this revision.Mar 21 2022, 1:54 PM

After some testing here are my notes:

  • To avoid confusions now that we will have a real fede effect the Fade transition should be removed (The only difference with Shrink transition is the order of the building proccess, the Fade name was arbitrary)

  • Connected to the above point, for better control on the building proccess would be great to have a target object that control the stroke builidng order. Nearest strokes to this object should start first.

  • Remove the Weight output. It's better to follow the Blender aproach and add a new Vertex Weight Opacity and a Vertex Weight Thickness modifiers.

Of course this is out of the scope of this patch. Another tasks should be opened for this

This revision now requires changes to proceed.Mar 21 2022, 1:54 PM
  • Remove the Weight output. It's better to follow the Blender aproach and add a new Vertex Weight Opacity and a Vertex Weight Thickness modifiers.

Not sure is good idea... the weight is calculated on the fly and you cannot calculate in the "next" modifier. @YimingWu (NicksBest) is this that way?

  • Remove the Weight output. It's better to follow the Blender aproach and add a new Vertex Weight Opacity and a Vertex Weight Thickness modifiers.

Not sure is good idea... the weight is calculated on the fly and you cannot calculate in the "next" modifier. @YimingWu (NicksBest) is this that way?

Do you mean that if we use a Vertex Weight Opacity modifier after the Build modifier we are not be able to read the actual opacity of the stroke generated by the Build modifier on realtime?

  • Remove the Weight output. It's better to follow the Blender aproach and add a new Vertex Weight Opacity and a Vertex Weight Thickness modifiers.

Not sure is good idea... the weight is calculated on the fly and you cannot calculate in the "next" modifier. @YimingWu (NicksBest) is this that way?

Do you mean that if we use a Vertex Weight Opacity modifier after the Build modifier we are not be able to read the actual opacity of the stroke generated by the Build modifier on realtime?

Maybe the fade value No.. @YimingWu (NicksBest) What do you think?

What is the satus of this patch? something pending of testing @Matias Mendiola (mendio) @Aleš Jelovčan (frogstomp) ?

What is the satus of this patch? something pending of testing @Matias Mendiola (mendio) @Aleš Jelovčan (frogstomp) ?

Still not have news from @YimingWu (NicksBest) about my last comments

@Matias Mendiola (mendio) Hi sorry for the delay... I don't think a separate "build weight" modifier is gonna work because you have the build sequence information that is not present in another modifier. So I'd say keeping the weight output in place.

To avoid confusions now that we will have a real fede effect the Fade transition should be removed (The only difference with Shrink transition is the order of the building proccess, the Fade name was arbitrary)

I think we could change the name of that to "fade in", "fade out", "shrink", which is more or less consistent with what it's doing.

would be great to have a target object that control the stroke builidng order. Nearest strokes to this object should start first.

I think this can be added... In the code it simply uses drawing order so I think I can rearrange this based on stroke end-points.

For the "vertex weight opacity" thing you suggested, I'm not sure I understand, Isn't that just doable from regular opacity modifier and select that particular vertex group and adjust the influence?

I find this modifier mature, keep finding new use cases for it (works very well with Envelope modifier):

With factor and offset modifier we can now offset strokes perfectly with draw order:

Changed the naming of "Fade" order to "Tail", which is more aligned with what it does.

Also Updated with object controlled fading origin (see gif):

Updated to latest master. Should compile fine now.

Updated to latest master

Updated to compensate for object transformation.

Use stdlib qsort instead of BLI_qsort_r, see if is correct on windows.

Get rid of compiling errors in windows.

Also the object selector is hidden when in concurrent mode.

Some notes after testing:

  • Change mode name Tail to Vanishing to make it less vague
  • Really fixed the sorting.
  • Changed name "tail" into "vanish".

Very very close to perfection!
Found occasional line disappearing (sun circle) and stroke direction reset to initial after build is complete. Attaching testing file

would be great to have a target object that control the stroke builidng order. Nearest strokes to this object should start first.

I think this can be added... In the code it simply uses drawing order so I think I can rearrange this based on stroke end-points.

i have a question is this feature will be added ? and if so , can this feature affect how a single stroke will be building (from middle if the object target is also in the middle of the stroke) ?
""curious""
respect

@hamza.SMA (hamza.elbarmaki) the feature is already in the patch, here is an example:

@hamza.SMA (hamza.elbarmaki) From middle of the stroke... it's not very likely because that way the stroke will be broke down, and that would affect style and UV. But could have some potential

This revision is now accepted and ready to land.Mar 29 2022, 12:52 PM
This revision was automatically updated to reflect the committed changes.
YimingWu (NicksBest) edited the summary of this revision. (Show Details)Mar 30 2022, 5:17 PM
YimingWu (NicksBest) edited the summary of this revision. (Show Details)