Vertex Weight Proximity not working for Grease Pencil Thickness Modifier #105640

New Issue

Closed

opened 2023-03-10 16:54:56 +01:00 by Christoph Werner · 12 comments

Christoph Werner commented

2023-03-10 16:54:56 +01:00

System Information
Operating system: Windows 11
Graphics card: GeForce RTX 3090

Blender Version
Broken: 3.3.4 LTS, 3.5, 3.6
Works: 3.4

Short description of error
Transferring vertex weights by using the vertex weight proximity modifer is not working for Thickness Modifiers in Grease Pencil.

Exact steps for others to reproduce the error
See the attached .blend file.

Load the file into Blender 3.4 -> All works like expected. Line Art thickness is controlled by camera distance.
Load the file into Blender 3.3.4 LTS -> No LineArt is visible.

**System Information** Operating system: Windows 11 Graphics card: GeForce RTX 3090 **Blender Version** Broken: 3.3.4 LTS, 3.5, 3.6 Works: 3.4 **Short description of error** Transferring vertex weights by using the vertex weight proximity modifer is not working for Thickness Modifiers in Grease Pencil. **Exact steps for others to reproduce the error** See the attached .blend file. 1. Load the file into Blender 3.4 -> All works like expected. Line Art thickness is controlled by camera distance. 2. Load the file into Blender 3.3.4 LTS -> No LineArt is visible.

tutorial_distance_lineart_001.blend1

217 KiB

Christoph Werner added this to the 3.3 LTS milestone 2023-03-10 16:54:56 +01:00

Christoph Werner added the

labels 2023-03-10 16:54:56 +01:00

Christoph Werner changed title from ~~Vertex Weight proximity not working for Grease Pencil Thickness Modifier~~ to Vertex Weight Proximity not working for Grease Pencil Thickness Modifier

2023-03-10 16:56:48 +01:00

YimingWu added the

labels 2023-03-10 17:21:44 +01:00

YimingWu self-assigned this 2023-03-10 17:21:54 +01:00

Pratik Borhade commented

2023-03-13 04:38:52 +01:00

Member

Thanks for the report. Can confirm this in 3.5/3.6 too.

Thanks for the report. Can confirm this in 3.5/3.6 too.

Pratik Borhade added

and removed

labels 2023-03-13 04:39:17 +01:00

Brecht Van Lommel commented

2023-03-14 16:41:10 +01:00

Owner

Did you confirm it as working or broken in 3.5? If it's broken in 3.5 the milestone should be changed to that.

Did you confirm it as working or broken in 3.5? If it's broken in 3.5 the milestone should be changed to that.

Pratik Borhade commented

2023-03-14 17:00:23 +01:00

Member

@brecht , 3.4 is good version.
3.3.4, 3.5 and 3.6 are affected by this issue.
I'll bisect this.

@brecht , 3.4 is good version. 3.3.4, 3.5 and 3.6 are affected by this issue. I'll bisect this.

Brecht Van Lommel modified the milestone from 3.3 LTS to 3.5

2023-03-14 17:04:21 +01:00

Brecht Van Lommel commented

2023-03-14 17:04:58 +01:00

Owner

I'll change the milestone to 3.5 assuming we may want to fix this for that release still, and then backport the fix to 3.3.

I'll change the milestone to 3.5 assuming we may want to fix this for that release still, and then backport the fix to 3.3.

Philipp Oeser commented

2023-03-16 10:06:47 +01:00

Member

Think this is a consequence by own 6aa29549e8 (see also #103887).

Seems the culprit commits mentioned in 6aa29549e8 were also missing the case in _DNA_DEFAULT_LineartGpencilModifierData (where LRT_GPENCIL_MATCH_OUTPUT_VGROUP was still put on .flags -- instead of .calculation_flags -- which 6aa29549e8 then exposed).

Assume we'll have to do some versioning here to correct this properly (otherwise we would have to check against both modifier_flags AND modifier_calculation_flags in existing modifiers), will see what I can do...

Think this is a consequence by own 6aa29549e889679112fd55f8d4a867c860646387 (see also #103887). Seems the culprit commits mentioned in 6aa29549e889679112fd55f8d4a867c860646387 were also missing the case in `_DNA_DEFAULT_LineartGpencilModifierData` (where `LRT_GPENCIL_MATCH_OUTPUT_VGROUP` was still put on `.flags` -- instead of `.calculation_flags` -- which 6aa29549e889679112fd55f8d4a867c860646387 then exposed). Assume we'll have to do some versioning here to correct this properly (otherwise we would have to check against both `modifier_flags` AND `modifier_calculation_flags` in existing modifiers), will see what I can do...

Philipp Oeser commented

2023-03-16 10:12:24 +01:00

Member

Just talked to @ChengduLittleA in chat, he'll take care

Just talked to @ChengduLittleA in chat, he'll take care

YimingWu commented

2023-03-16 14:28:14 +01:00

Member

Hi, I checked the problem and I think the issue is indeed with a wrongly assigned _DNA_DEFAULT_LineartGpencilModifierData. The correct way should be LRT_GPENCIL_MATCH_OUTPUT_VGROUP being inside .calculation_flags. Let me check if it's working correctly with the default value changed back.

Can't figure out what's going on. From the look of the file, both invert and match flags seems to work from modifier_flags, which isn't quite the intention. I need to check what exact is different from both versions

~~Hi, I checked the problem and I think the issue is indeed with a wrongly assigned `_DNA_DEFAULT_LineartGpencilModifierData`. The correct way should be `LRT_GPENCIL_MATCH_OUTPUT_VGROUP` being inside `.calculation_flags`. Let me check if it's working correctly with the default value changed back.~~ Can't figure out what's going on. From the look of the file, both invert and match flags seems to work from `modifier_flags`, which isn't quite the intention. I need to check what exact is different from both versions

Philipp Oeser commented

2023-03-16 14:40:22 +01:00

Member

@ChengduLittleA : it will work on new modifiers, but wont do the trick for the file reported (for that you need versioning code I think -- or check both flags as mentioned in my previous comment)

@ChengduLittleA : it will work on **new** modifiers, but wont do the trick for the file reported (for that you need versioning code I think -- or check both flags as mentioned in my previous comment)

YimingWu commented

2023-03-16 16:25:11 +01:00

Member

OK I know what's happening now.

From what I can see the 3.4 is actually the incorrect one, because the file have neither source nor target vertex group set, and internally the logic is wrong (3.4), where it refers flag value instead of the calculation_flag value.

It is needed to either enter the prefix of the vertex group name in the source, or choose an explicit target, or use "match output". So technically the 3.3lts, 3.5, 3.6 version has the correct behaviour. (Just open the file with 3.5/3.6 and enable "match output" alone would do the trick, and styles are correctly driven by properties as well)

The current logic in the code (not optimum as I'm seeing it today):

if enabled "match", then all vertex groups in target GP who has the exact same name from from source mesh objects will get the weight value from mesh.
if "filter source" is set, then only affects vertex groups whose name starts with the that string.
if "target" is set, then all filtered vertex weight will go into this one "target" vertex group.

I know the logic of this until even now is

still very confusing, and
there's really no clear explanation in the manual, and
the functionality itself is pretty obscure

... but I'm leaning towards implementing a more flexible weight transferring solution with future node-based line art.

OK I know what's happening now. From what I can see **the 3.4 is actually the incorrect one**, because the file have neither source nor target vertex group set, and internally the logic is wrong (3.4), where it refers `flag` value instead of the `calculation_flag value`. It is needed to either enter the prefix of the vertex group name in the source, or choose an explicit target, or use "match output". So technically the 3.3lts, 3.5, 3.6 version has the correct behaviour. (Just open the file with 3.5/3.6 and enable "match output" alone would do the trick, and styles are correctly driven by properties as well) The current logic in the code (not optimum as I'm seeing it today): - if enabled "match", then all vertex groups in target GP who has the exact same name from from source mesh objects will get the weight value from mesh. - if "filter source" is set, then only affects vertex groups whose name starts with the that string. - if "target" is set, then all filtered vertex weight will go into this one "target" vertex group. I know the logic of this until even now is 1) still very confusing, and 2) there's really no clear explanation in the manual, and 3) the functionality itself is pretty obscure ... but I'm leaning towards implementing a more flexible weight transferring solution with future node-based line art.

Philipp Oeser commented

2023-03-17 09:52:43 +01:00

Member

@ChengduLittleA : dont think 3.3lts, 3.5, 3.6 version are actually correct either.

The purpose of DNA defaults was actually to enable Match Output by default.
This was more or less broken since your own 841df831e8 & 3558bb8eae (since it moved the flags).

3.3lts, 3.5, 3.6 version now read the flags from the right place (since my 6aa29549e8), but the default on new modifiers is still wrong.

So I think we should:

correct _DNA_DEFAULT_LineartGpencilModifierData (enable LRT_GPENCIL_MATCH_OUTPUT_VGROUP in .calculation_flags, remove from .flags)
in versioning code, transfer LRT_GPENCIL_MATCH_OUTPUT_VGROUP (found in .flags) to .calculation_flags)

I know the logic of this until even now is

still very confusing, and

there's really no clear explanation in the manual, and

the functionality itself is pretty obscure

... but I'm leaning towards implementing a more flexible weight transferring solution with future node-based line art.

This is your own code, no? Why not fix it like I outlined (this will at least keep the functionality intact until node-based lineart will see the light of day sometime in the future?)

Do you want me to cook up a patch?

@ChengduLittleA : dont think 3.3lts, 3.5, 3.6 version are actually correct either. The purpose of DNA defaults was actually to enable `Match Output` **by default**. This was more or less broken since your own 841df831e89d & 3558bb8eae75 (since it moved the flags). 3.3lts, 3.5, 3.6 version now read the flags from the right place (since my 6aa29549e889679112fd55f8d4a867c860646387), but the default on new modifiers is still wrong. So I think we should: - correct `_DNA_DEFAULT_LineartGpencilModifierData` (enable LRT_GPENCIL_MATCH_OUTPUT_VGROUP in `.calculation_flags`, remove from `.flags`) - in versioning code, transfer `LRT_GPENCIL_MATCH_OUTPUT_VGROUP` (found in `.flags`) to `.calculation_flags`) > I know the logic of this until even now is > > 2. still very confusing, and > 3. there's really no clear explanation in the manual, and > 4. the functionality itself is pretty obscure > > ... but I'm leaning towards implementing a more flexible weight transferring solution with future node-based line art. This is your own code, no? Why not fix it like I outlined (this will at least keep the functionality intact until node-based lineart will see the light of day sometime in the future?) Do you want me to cook up a patch?

YimingWu referenced a pull request that will close this issue

2023-03-17 13:22:48 +01:00

Fix #105640: LineArt: versioning for LRT_GPENCIL_MATCH_OUTPUT_VGROUP flag. #105852

YimingWu referenced this issue from a commit

2023-03-17 16:31:13 +01:00

Fix #105640: LineArt: Default value for LRT_GPENCIL_MATCH_OUTPUT_VGROUP flag.

YimingWu closed this issue

2023-03-17 16:31:13 +01:00

Blender Bot added

and removed

labels 2023-03-17 16:31:15 +01:00

YimingWu commented

2023-03-17 16:32:39 +01:00

Member

Note @ChristophWerner :

This fixes the default value assignment but due to the old flag bits are in conflict with used bits in the new flag variables, versioning changes are not included. This means you need to manually turn on the "Match output" option in those files saved with older versions. :)

Note @ChristophWerner : This fixes the default value assignment but due to the old flag bits are in conflict with used bits in the new flag variables, versioning changes are not included. This means you need to manually turn on the "Match output" option in those files saved with older versions. :)

Christoph Werner commented

2023-03-23 10:22:22 +01:00

Author

Ok. Understand. The "Match output" option works in 3.3.4 LTS for now.

Ok. Understand. The "Match output" option works in 3.3.4 LTS for now.

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

5 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#105640

No description provided.