GPencil: Build Modifier in GP sequential growth stroke ordering #110147

New Issue

funty · 2023-07-15T21:41:11+02:00

funty commented

2023-07-15 21:41:11 +02:00

System Information
Operating system: Windows 10, 22H2
Graphics card: AMD R7 200

Blender Version
Broken: 3.60
Worked: Not sure if it ever worked perfectly, as I never cared for its sequential mode before , but I would guess 3.3.

Short description of error
If you view the attached video file , you will notice that it is in fact the "Draw Strokes on Back" that is causing the Build Modifier to work counter-intuitively.

Instead of building strokes sequentially, meaning first stroke drawn is the first stroke built or FIFO building, it LIFO builds the strokes drawn using the "Draw strokes on back" option first, and then it FIFO builds the normal strokes.

In other words, its not even building the strokes drawn on back sequentially forwards, but instead backwards, as is evident in the attached video.

Exact steps for others to reproduce the error

Open default grease pencil template
draw few strokes
toggle draw strokes on back property
repeat last two steps for 1-2 times (refer video)
Add build modifier
Play animation

Video: https://projects.blender.org/attachments/2f3c6ad8-763d-4aba-a81e-400823a7ae70

**System Information** Operating system: Windows 10, 22H2 Graphics card: AMD R7 200 **Blender Version** Broken: 3.60 Worked: Not sure if it ever worked perfectly, as I never cared for its sequential mode before , but I would guess 3.3. **Short description of error** If you view the attached video file , you will notice that it is in fact the "Draw Strokes on Back" that is causing the Build Modifier to work counter-intuitively. Instead of building strokes sequentially, meaning first stroke drawn is the first stroke built or FIFO building, it LIFO builds the strokes drawn using the "Draw strokes on back" option first, and then it FIFO builds the normal strokes. In other words, its not even building the strokes drawn on back sequentially forwards, but instead backwards, as is evident in the attached video. **Exact steps for others to reproduce the error** - Open default grease pencil template - draw few strokes - toggle `draw strokes on back` property - repeat last two steps for 1-2 times (refer video) - Add build modifier - Play animation Video: https://projects.blender.org/attachments/2f3c6ad8-763d-4aba-a81e-400823a7ae70

funty added the

labels 2023-07-15 21:41:11 +02:00

funty commented

2023-07-16 18:57:21 +02:00

Update, using 3.6.0:

Before starting the GP strokes, removed all modifiers, and effects.
Started the GP strokes the way I want them to build sequentially.
After around 30K points, added the Build modifier only with default settings of Sequential, Grow, Number of Frames
Played the animation, and it grows in reverse, LIFO, last in first out, the last stroke drawn is the first stroke built, and it goes backward from there, opposite of what one would expect, imo.
Change Transition to Shrink, and it uses FIFO, first frame draw is the first frame shrunk.
Change Transition to Vanish, and it uses LIFO, last frame drawn is the first frame vanished.

Tried above with Concurrent and additive with similar results. Instead of FIFO, its following LIFO.

I will add more updates as I do variations of this in 3.6 and other versions.

Just to reiterate, I expect the build function to build sequentially using FIFO, first frame drawn is the first frame built, and growing sequentially till the last frame drawn, as that is what I understood from the reference manual.

So from the above experience, this is a bug, as its not behaving the way the reference manual states, or even the way that option labels describe it should behave.

The way its works by default right now, if there was a way to reverse the build sequence, so it builds FIFO, instead of LIFO, that would satisfy my current needs.

Update, using 3.6.0: 1. Before starting the GP strokes, removed all modifiers, and effects. 2. Started the GP strokes the way I want them to build sequentially. 3. After around 30K points, added the Build modifier only with default settings of Sequential, Grow, Number of Frames 4. Played the animation, and it grows in reverse, LIFO, last in first out, the last stroke drawn is the first stroke built, and it goes backward from there, _opposite of what one would expect_, imo. 5. Change Transition to Shrink, and it uses FIFO, first frame draw is the first frame shrunk. 6. Change Transition to Vanish, and it uses LIFO, last frame drawn is the first frame vanished. Tried above with Concurrent and additive with similar results. Instead of FIFO, its following LIFO. I will add more updates as I do variations of this in 3.6 and other versions. Just to reiterate, I expect the build function to build sequentially using FIFO, first frame drawn is the first frame built, and growing sequentially till the last frame drawn, as that is what I understood from the reference manual. So from the above experience, this is a bug, as its not behaving the way the reference manual states, or even the way that option labels describe it should behave. The way its works by default right now, if there was a way to reverse the build sequence, so it builds FIFO, instead of LIFO, that would satisfy my current needs.

Pratik Borhade commented

2023-07-17 07:43:34 +02:00

Hi, thanks for the report. Tried with around 10k points but sequence of drawing was correct.
I'm not able to redo this locally in 3.6, 4.0
Are you appending build modifier on existing drawing from previous blender versions?
Unfortunately the scenario described is too time consuming for us to track down, we require the bug reporter to narrow down the problem.

Hi, thanks for the report. Tried with around 10k points but sequence of drawing was correct. I'm not able to redo this locally in 3.6, 4.0 Are you appending build modifier on existing drawing from previous blender versions? Unfortunately the scenario described is too time consuming for us to track down, we require the bug reporter to narrow down the problem.

Pratik Borhade added

Status

Needs Information from User

and removed

Status

Needs Triage

labels 2023-07-17 07:43:45 +02:00

funty commented

2023-07-17 14:44:42 +02:00

Are you appending build modifier on existing drawing from previous blender versions?

No, its the same version, only thing that can be related is that I am going between versions 3.6.0 and 3.3.8 sometimes, using the same file. So, for example, I will create the file in 3.6.0 and append build modifier in the same version and then use the file in 3.3.8 sometimes, and vice versa.

Furthermore, I am not able to reproduce the issue when focusing on just the number of points. Reaching over 30K points while using very few strokes, for example, scribbling with continuous round circles (without lifting the stylus too many times), does not reproduce this issue with default settings Blender 3.6.0/3.3.8. Build modifier works normally as expected using FIFO growth algorithm.

This may have something to do with the number of strokes instead, meaning many small strokes with fewer points, as opposed to fewer strokes with many points. Since drawing many strokes (lifting the stylus often) takes more effort than just points (not lifting the stylus often), this is going to take me a bit of time to narrow down.

Further testing is required, so please leave this open for now.

> Are you appending build modifier on existing drawing from previous blender versions? No, its the same version, only thing that can be related is that I am going between versions 3.6.0 and 3.3.8 sometimes, using the same file. So, for example, I will create the file in 3.6.0 and append build modifier in the same version and then use the file in 3.3.8 sometimes, and vice versa. Furthermore, I am not able to reproduce the issue when focusing on just the number of points. Reaching over 30K points while using very few strokes, for example, scribbling with continuous round circles (without lifting the stylus too many times), does not reproduce this issue with default settings Blender 3.6.0/3.3.8. Build modifier works normally as expected using FIFO growth algorithm. This may have something to do with the number of strokes instead, meaning many small strokes with fewer points, as opposed to fewer strokes with many points. Since drawing many strokes (lifting the stylus often) takes more effort than just points (not lifting the stylus often), this is going to take me a bit of time to narrow down. Further testing is required, so please leave this open for now.

👍 1

funty commented

2023-07-17 15:23:11 +02:00

Based on potential issue with using two versions (3.6.0 and 3.3.8) for the same file, I am going to create a fresh file in one version and use only that version from now on and see if I can reproduce it.
I will start with version 3.3.8. If I am not able to reproduce it, then I will start a fresh file in 3.6.0 (or 3.6.1 if that is is out by then), and use it in only that version.

Based on potential issue with using two versions (3.6.0 and 3.3.8) for the same file, I am going to create a fresh file in one version and use only that version from now on and see if I can reproduce it. I will start with version 3.3.8. If I am not able to reproduce it, then I will start a fresh file in 3.6.0 (or 3.6.1 if that is is out by then), and use it in only that version.

funty commented

2023-07-18 22:17:55 +02:00

btw, I am using Workbench, and not EEVEE. I am not sure if it changes anything. I am going to try using EEVEE exclusively as well, to see if it reproduces the issue.

funty commented

2023-07-18 23:23:50 +02:00

Update
Using Build Modifier with 3.3.9 with fresh file from default settings, and using the file only in 3.3.9
Default file settings, using Workbench and EEVEE results in the same behavior. This behavior does not reveal itself until over a certain number of strokes/points. Not sure exactly how many, but usually over 1K strokes and 20k points, and its not consistent.

While using vertex colors, build modifier seems to work as expected consistently (FIFO strokes/points) only if one vertex color is used, even if the values are changed for that vertex color, for example using HSV, and only V is changed.

However, if another vertex color is picked from the palette at any point after a certain number of strokes/points (inconsistent), then the indexing begins with the new color strokes, and ends with the previous color strokes, in other words, it becomes LIFO with reference to different vertex colors, but maintains FIFO within the same vertex color. Once this change occurs, all subsequent new strokes with new vertex colors become the first strokes to be drawn, as the build mode has change from FIFO to LIFO.
I will do more testing with a different GPU, and even in Linux to see if this issue persists. I will also use materials without vertex colors to see if it has the same behavior.

Also, I will test the same in 3.6.0, and report back.

Update Using Build Modifier with 3.3.9 with fresh file from default settings, and using the file only in 3.3.9 Default file settings, using Workbench and EEVEE results in the same behavior. This behavior does not reveal itself until over a certain number of strokes/points. Not sure exactly how many, but usually over 1K strokes and 20k points, and its not consistent. While using vertex colors, build modifier seems to work as expected consistently (FIFO strokes/points) only if one vertex color is used, even if the values are changed for that vertex color, for example using HSV, and only V is changed. However, if another vertex color is picked from the palette at any point after a certain number of strokes/points (inconsistent), then the indexing begins with the new color strokes, and ends with the previous color strokes, in other words, it becomes LIFO with reference to different vertex colors, but maintains FIFO within the same vertex color. Once this change occurs, all subsequent new strokes with new vertex colors become the first strokes to be drawn, as the build mode has change from FIFO to LIFO. I will do more testing with a different GPU, and even in Linux to see if this issue persists. I will also use materials without vertex colors to see if it has the same behavior. Also, I will test the same in 3.6.0, and report back.

funty commented

2023-07-19 04:25:46 +02:00

Final Update.

I believe I have narrowed it down. First of all, its not what I thought initially, or as complicated as I thought. Its not number of strokes or number of points that are causing the problem. If you view the attached video file , you will notice that it is in fact the "Draw Strokes on Back" that is causing the Build Modifier to work counter-intuitively.

Instead of building strokes sequentially, meaning first stroke drawn is the first stroke built or FIFO building, it LIFO builds the strokes drawn using the "Draw strokes on back" option first, and then it FIFO builds the normal strokes.

In other words, its not even building the strokes drawn on back sequentially forwards, but instead backwards, as is evident in the attached video.

What it should do, from my understanding, and what is useful to me, is literally draw strokes sequentially forwards regardless of if they are drawn in the back or in the front.

Please fix this, so strokes are actually drawn sequentially forwards, one after the other as the build modifier description, and tooltips inform the user.

P.S. I have checked all LTS versions all the way back to 2.83.20 and the build modifier behaves in the same errant way.

Final Update. I believe I have narrowed it down. First of all, its not what I thought initially, or as complicated as I thought. Its not number of strokes or number of points that are causing the problem. If you view the attached video file , you will notice that it is in fact the "Draw Strokes on Back" that is causing the Build Modifier to work counter-intuitively. Instead of building strokes sequentially, meaning first stroke drawn is the first stroke built or FIFO building, it LIFO builds the strokes drawn using the "Draw strokes on back" option first, and then it FIFO builds the normal strokes. In other words, its not even building the strokes drawn on back sequentially forwards, but instead backwards, as is evident in the attached video. What it should do, from my understanding, and what is useful to me, is literally draw strokes sequentially forwards regardless of if they are drawn in the back or in the front. Please fix this, so strokes are actually drawn sequentially forwards, one after the other as the build modifier description, and tooltips inform the user. P.S. I have checked all LTS versions all the way back to 2.83.20 and the build modifier behaves in the same errant way.

BuildModBehavior361.mkv

4.5 MiB

Pratik Borhade commented

2023-07-21 11:10:58 +02:00

Yes, can confirm, will update the report. Thanks for investigating :)

Pratik Borhade changed title from ~~Build Modifier in GP randomizes/reverses growth sometimes.~~ to GPencil: Build Modifier in GP sequential growth stroke ordering

2023-07-21 11:12:21 +02:00

Pratik Borhade added

and removed

Needs Information from User

labels 2023-07-21 11:14:59 +02:00

Pratik Borhade commented

2023-07-21 11:46:39 +02:00

Nothing wrong in build modifier. Stroke itself are stored in the different order in gpencil frame.
But this is expected from code's perspective. Background strokes are added to the head of list so these strokes will be drawn first on region and then normal strokes (for correct overlapping effect I assume)

see: https://projects.blender.org/blender/blender/src/branch/main/source/blender/editors/gpencil_legacy/gpencil_paint.c#L1323

  /* add stroke to frame, usually on tail of the listbase, but if on back is enabled the stroke
   * is added on listbase head because the drawing order is inverse and the head stroke is the
   * first to draw. This is very useful for artist when drawing the background.
   */
  if (ts->gpencil_flags & GP_TOOL_FLAG_PAINT_ONBACK) {
    BLI_addhead(&p->gpf->strokes, gps);
  }
  else {
    BLI_addtail(&p->gpf->strokes, gps);
  }

@antoniov hi, would you consider this a bug? looks expected behavior to me

Nothing wrong in build modifier. Stroke itself are stored in the different order in gpencil frame. But this is expected from code's perspective. Background strokes are added to the head of list so these strokes will be drawn first on region and then normal strokes (for correct overlapping effect I assume) see: https://projects.blender.org/blender/blender/src/branch/main/source/blender/editors/gpencil_legacy/gpencil_paint.c#L1323 ``` /* add stroke to frame, usually on tail of the listbase, but if on back is enabled the stroke * is added on listbase head because the drawing order is inverse and the head stroke is the * first to draw. This is very useful for artist when drawing the background. */ if (ts->gpencil_flags & GP_TOOL_FLAG_PAINT_ONBACK) { BLI_addhead(&p->gpf->strokes, gps); } else { BLI_addtail(&p->gpf->strokes, gps); } ``` @antoniov hi, would you consider this a bug? looks expected behavior to me

funty commented

2023-07-22 06:40:32 +02:00

Thanks for considering this.

From the programming perspective, if the build modifier is working with the sequence from GP core, then, as much as I have experienced so far, the build modifier is getting a FIFO sequence only when the strokes/fills are in the same layer and drawn in the front.

If the strokes are in the same layer and drawn in the back, the build modifier gets a LIFO sequence, and draws them before the strokes in the front.
Furthermore, if the strokes are in different layers, then a whole new sequence is provided to the build modifier, without consideration to the sequence of strokes drawn in other layers. This results in strokes from different layers being drawn in tandem, some FIFO, some LIFO, depending on if they are drawn in the front or the back.

This is not consistent with my user expectation of "sequential" drawing of strokes. Frankly its chaotic, depriving the user of control over which strokes are drawn first.

My expectation would be satisfied with the following:

All strokes drawn FIFO, regardless of if they are drawn in front or back.
All strokes drawn respect the layer heirarchy in the layers drop down, with strokes in the layer at the top drawn first, and the strokes in the layer at the bottom drawn last.

This would give, in my opinion, a satisfactory amount of control over the build modifier in GP.

Thanks for considering this. From the programming perspective, if the build modifier is working with the sequence from GP core, then, as much as I have experienced so far, the build modifier is getting a FIFO sequence only when the strokes/fills are in the same layer and drawn in the front. - If the strokes are in the same layer and drawn in the back, the build modifier gets a LIFO sequence, and draws them before the strokes in the front. - Furthermore, if the strokes are in different layers, then a whole new sequence is provided to the build modifier, without consideration to the sequence of strokes drawn in other layers. This results in strokes from different layers being drawn in tandem, some FIFO, some LIFO, depending on if they are drawn in the front or the back. This is not consistent with my user expectation of "sequential" drawing of strokes. Frankly its chaotic, depriving the user of control over which strokes are drawn first. My expectation would be satisfied with the following: - All strokes drawn FIFO, regardless of if they are drawn in front or back. - All strokes drawn respect the layer heirarchy in the layers drop down, with strokes in the layer at the top drawn first, and the strokes in the layer at the bottom drawn last. This would give, in my opinion, a satisfactory amount of control over the build modifier in GP.

Antonio Vazquez commented

2023-07-22 11:54:36 +02:00

The Build modifier works with the order of the strokes in the list (that is the same used when the draw engine uses)...so, if you use the draw "on back"...you are putting before in the list. To get the order that you want would need zdepth order or something like that, but this is not supported.

@PratikPB2123 IMHO you could close as Known Issue.

Also, I'm not sure how this going to be done in GP3.0. Maybe this could change in the future.

The Build modifier works with the order of the strokes in the list (that is the same used when the draw engine uses)...so, if you use the draw "on back"...you are putting before in the list. To get the order that you want would need zdepth order or something like that, but this is not supported. @PratikPB2123 IMHO you could close as Known Issue. Also, I'm not sure how this going to be done in GP3.0. Maybe this could change in the future.

funty commented

2023-07-22 19:45:22 +02:00

@antoniov

...so, if you use the draw "on back"...you are putting before in the list

even as you explained, the build modifier is not drawing the "on back" strokes FIFO (as one would expect "sequential" to mean), but LIFO, meaning the last "on back" stroke is built first (reverse of sequential). So there is some conceptual chaos from the programming side.

@antoniov > ...so, if you use the draw "on back"...you are putting before in the list even as you explained, the build modifier is not drawing the "on back" strokes FIFO (as one would expect "sequential" to mean), but LIFO, meaning the last "on back" stroke is built first (reverse of sequential). So there is some conceptual chaos from the programming side.

funty commented

2023-07-22 20:12:33 +02:00

So, for users who might be interested in this workflow, if I understood this correctly, as of version 3.6.1, if you want to use the build modifier with "on back" strokes to get sequential building of strokes, to accommodate the current build ordering, you will have to draw the "on back" strokes in reverse order first, so that the build modifiers builds them in the correct order. And then draw the regular "on front" strokes. If in the middle of this, you decide to go back and forth between "on back" and "on front" you will end up creating a chaos of the stroke order that may mess up your initial build order as well, and the stroke building may become unpredictable, as I have experienced so far.

This will require pre-planning, and will weaken the creative process (at least for me), for this specific workflow, as Blender has a lot of other amazing stuff to offer.

Personally, going forward, when using the build modifier, I will stop using the "on back" stroke altogether, and stick to normal strokes, as they are more predictable with the build modifier.

Thank you for considering this though.

So, for users who might be interested in this workflow, if I understood this correctly, as of version 3.6.1, if you want to use the build modifier with "on back" strokes to get sequential building of strokes, to accommodate the current build ordering, you will have to draw the "on back" strokes in reverse order first, so that the build modifiers builds them in the correct order. And then draw the regular "on front" strokes. If in the middle of this, you decide to go back and forth between "on back" and "on front" you will end up creating a chaos of the stroke order that may mess up your initial build order as well, and the stroke building may become unpredictable, as I have experienced so far. This will require pre-planning, and will weaken the creative process (at least for me), for this specific workflow, as Blender has a lot of other amazing stuff to offer. Personally, going forward, when using the build modifier, I will stop using the "on back" stroke altogether, and stick to normal strokes, as they are more predictable with the build modifier. Thank you for considering this though.

Pratik Borhade commented

2023-07-26 13:26:56 +02:00

@funty hi, actually there is no FIFO and LIFO order in this case.
We have one list per frame where strokes are stored.
If stroke is drawn:

When draw strokes on back is disabled: strokes are added at the end of list
When draw strokes on back is enabled: strokes are added at the start of the list

And build modifier this list, loops over the list in sequential order from start to end.

Will close since this is not technically a bug. For build modifier, this does look like incorrect behavior.
This might be improved in Grease pencil 3.0

IMHO you could close as Known Issue.

Sure.

@funty hi, actually there is no FIFO and LIFO order in this case. We have one list per frame where strokes are stored. If stroke is drawn: - When `draw strokes on back` is disabled: strokes are added at the end of list - When `draw strokes on back` is enabled: strokes are added at the start of the list And build modifier this list, loops over the list in sequential order from start to end. Will close since this is not technically a bug. For build modifier, this does look like incorrect behavior. This might be improved in [Grease pencil 3.0](https://code.blender.org/2023/05/the-next-big-step-grease-pencil-3-0/) > IMHO you could close as Known Issue. Sure.

Pratik Borhade closed this issue

2023-07-26 13:26:59 +02:00

Blender Bot added

and removed

labels 2023-07-26 13:27:01 +02:00

Pratik Borhade added

Type

Known Issue