Grease Pencil Build and Simplify Modifier Order Ignored #66744

New Issue

Philip Holzmann · 2019-07-12T10:31:53+02:00

Philip Holzmann commented

2019-07-12 10:31:53 +02:00

System Information
Operating system: Windows 10 64 bit
Graphics card: Nvidia GTX 750 Ti

Blender Version
Broken: blender-2.80.0-git.d663048696b2-windows64

Short description of error
If a Grease Pencil Object has both a Simplify and Build Modifier, it doesn't matter which order they come in.
It always behaves as if the Simplify Modifier came after the Build Modifier.

I'd expect Simplify before Build to behave as if the Simplify Modifier was applied first.

Exact steps for others to reproduce the error
GreaseBuild.blend
From left to right:

Simplify before Build
Build before Simplify
Simplify before Build, with Simplify applied

As you can see, 1 and 2 behave the same (when you play the animation).
However, I'd expect 1 to behave the same as 3.

**System Information** Operating system: Windows 10 64 bit Graphics card: Nvidia GTX 750 Ti **Blender Version** Broken: blender-2.80.0-git.d663048696b2-windows64 **Short description of error** If a Grease Pencil Object has both a Simplify and Build Modifier, it doesn't matter which order they come in. It always behaves as if the Simplify Modifier came after the Build Modifier. I'd expect Simplify before Build to behave as if the Simplify Modifier was applied first. **Exact steps for others to reproduce the error** [GreaseBuild.blend](https://archive.blender.org/developer/F7601868/GreaseBuild.blend) From left to right: 1. Simplify before Build 2. Build before Simplify 3. Simplify before Build, with Simplify applied As you can see, 1 and 2 behave the same (when you play the animation). However, I'd expect 1 to behave the same as 3.

Philip Holzmann commented

2019-07-12 10:31:53 +02:00

Added subscriber: @Foaly

Antonio Vazquez was assigned by Sebastian Parborg

2019-07-12 11:00:28 +02:00

Antonio Vazquez commented

2019-07-12 13:52:25 +02:00

IIRC this is how is designed because there are several types (internally) of modifiers... modifiers that change geometry, modifiers that generate geometry and modifiers that use time.

I will review, but I think this is a problem of communicate this and explain how and why the modifiers are evaluated in that way.

IIRC this is how is designed because there are several types (internally) of modifiers... modifiers that change geometry, modifiers that generate geometry and modifiers that use time. I will review, but I think this is a problem of communicate this and explain how and why the modifiers are evaluated in that way.

Antonio Vazquez commented

2019-07-12 16:12:49 +02:00

Added subscriber: @ZedDB

Antonio Vazquez commented

2019-07-12 16:12:49 +02:00

@ZedDB I have been looking at the code, and the build modifier must be evaluated before the others modifiers due this modifier needs to read all frames to decide what to do, but the other modifiers only read the current frame and strokes.

Run Build before is done for data access and also for performance, so all geometry modifiers (Build, Mirror and Array) run first, and then all modify modifiers. Time modifier plays totatlly different.

I don't think we can change this or consider as a bug, but a limitation of what you can do with modifiers... maybe we could add some type of warning on modifier panel to inform about this.

Note: For 2.81 I'm going to replace where the modifiers are evaluated (see #66294). I have the change done in greasepencil branch, but we decided not to move to 2.80 and wait for 2.81.

@ZedDB I have been looking at the code, and the build modifier must be evaluated before the others modifiers due this modifier needs to read all frames to decide what to do, but the other modifiers only read the current frame and strokes. Run Build before is done for data access and also for performance, so all geometry modifiers (Build, Mirror and Array) run first, and then all modify modifiers. Time modifier plays totatlly different. I don't think we can change this or consider as a bug, but a limitation of what you can do with modifiers... maybe we could add some type of warning on modifier panel to inform about this. Note: For 2.81 I'm going to replace where the modifiers are evaluated (see #66294). I have the change done in greasepencil branch, but we decided not to move to 2.80 and wait for 2.81.

Sebastian Parborg commented

2019-07-12 16:32:08 +02:00

@antoniov How about we make it so that the build modifier adds a warning to its UI if it is not first in the stack?

Antonio Vazquez commented

2019-07-12 16:40:03 +02:00

Yes, this is the idea... I have seen this before in the code for some modifiers, but don't remember where

Antonio Vazquez was unassigned by Dalai Felinto

2019-12-23 16:33:48 +01:00

Dalai Felinto commented

2019-12-23 16:33:48 +01:00

Added subscriber: @antoniov

Bastien Montagne commented

2020-01-27 16:58:48 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2020-01-27 16:58:48 +01:00

That is a fairly sever usability issue, order in the stack should always be actual order of evaluation. If some modifiers need to run first, then they should be forcefully put in first positions of the stack.

We have that with regular Object modifier e.g., Multires cannot be moved or added after a modifier like Build, because the latter breaks access to mesh orig data needed by multiress…

It is most likely too late to address that in 2.82, but would consider it a show-stopper for 2.83 then. You cannot expect users to guess the actual order of evaluation, they have to get what they see here. ;)

That is a fairly sever usability issue, order in the stack should **always** be actual order of evaluation. If some modifiers need to run first, then they should be forcefully put in first positions of the stack. We have that with regular Object modifier e.g., Multires cannot be moved or added after a modifier like Build, because the latter breaks access to mesh orig data needed by multiress… It is most likely too late to address that in 2.82, but would consider it a show-stopper for 2.83 then. You cannot expect users to guess the actual order of evaluation, they have to get what they see here. ;)

Antonio Vazquez commented

2020-01-27 17:05:45 +01:00

@mont29 Are there any tag to force a modifier to be first in stack?

Bastien Montagne commented

2020-01-27 17:16:12 +01:00

@antoniov For 'regular' data check eModifierTypeFlag_RequiresOriginalData flag in BKE_modifier.h. However if you have three different 'stages' you'll probably need another extra tag for the second stage?

@antoniov For 'regular' data check `eModifierTypeFlag_RequiresOriginalData` flag in `BKE_modifier.h`. However if you have three different 'stages' you'll probably need another extra tag for the second stage?

Antonio Vazquez self-assigned this 2020-01-28 22:44:12 +01:00

Antonio Vazquez commented

2020-01-28 22:44:12 +01:00

I'm going to refactor the modifier loop to use the order on the stack. All the changes will be done in greasepencil-refactor branch, because we have changed all modifiers evaluation for the new drawing engine.