Regression: GPencil Line Art modifier creates extra (offset) strokes on collection instances #102503

New Issue

System Information
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 522.30

Blender Version
Broken: version: 3.0.0, 3.5
Worked: version: 2.93.6

Caused by d1e0059eac

Short description of error
A grease pencil lineart object in an instance of a collection that is in the same scene and contains the modifier's target will show extraneous lines corresponding to the projections of the instanced collection.

Exact steps for others to reproduce the error
From the default startup:

Create a new collection in the scene ("Collection 2")
Move the default cube in "Collection 2"
Create a new blank Grease Pencil object in new collection
Add a lineart modifier to GPencil and set its source to the default cube
Create instances of "Collection 2" in the scene.
Change viewport display modes, or use another method to trigger a redraw

First 5 steps included in file
#102503.blend

Here is a screenshot of what I see:

**System Information** Operating system: Windows-10-10.0.22621-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 522.30 **Blender Version** Broken: version: 3.0.0, 3.5 Worked: version: 2.93.6 Caused by d1e0059eac **Short description of error** A grease pencil lineart object in an instance of a collection that is in the same scene and contains the modifier's target will show extraneous lines corresponding to the projections of the instanced collection. **Exact steps for others to reproduce the error** From the default startup: 1. Create a new collection in the scene ("Collection 2") 2. Move the default cube in "Collection 2" 3. Create a new blank Grease Pencil object in new collection 4. Add a lineart modifier to GPencil and set its source to the default cube 5. Create instances of "Collection 2" in the scene. 6. Change viewport display modes, or use another method to trigger a redraw First 5 steps included in file [#102503.blend](https://archive.blender.org/developer/F13936399/T102503.blend) Here is a screenshot of what I see: ![image.png](https://archive.blender.org/developer/F13913966/image.png)

Added subscriber: @SmugRainbowPony

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscriber: @ChengduLittleA

Added subscriber: @PratikPB2123

Added subscriber: @lichtwerk

Changed status from 'Confirmed' to: 'Needs User Info'

Just to make this report somewhat complete:

Worked: version: 2.93.6

Cannot repro, or better: I can repro the same bug in 2.93
@SmugRainbowPony : what makes you think it was working there?

Just to make this report somewhat complete: > Worked: version: 2.93.6 Cannot repro, or better: I can repro the same bug in 2.93 @SmugRainbowPony : what makes you think it was working there?

@lichtwerk , neither I can repro in 2.93LTS. So I kept "working version" as it is in description :)
Could you check with following file?

Open file
{nav Shift A > Collection Instance > Collection 2}
Switch shading mode
#102503.blend

@lichtwerk , neither I can repro in 2.93LTS. So I kept "working version" as it is in description :) Could you check with following file? - Open file - {nav Shift A > Collection Instance > Collection 2} - Switch shading mode [#102503.blend](https://archive.blender.org/developer/F13936399/T102503.blend)

In #102503#1447455, @lichtwerk wrote:
Cannot repro, or better: I can repro the same bug in 2.93
@SmugRainbowPony : what makes you think it was working there?

Initially when testing, I would go through the steps and see if I got extra strokes.

I opened 2.93.6 and tested again.
Opening the report file I provided with 2.93.6 does give extra strokes

but when I go through the steps in a new 2.93.6 file, the problem doesn't appear

@lichtwerk did you go through the steps or open the file?

Apparently my provided file isn't test-reliable, though, so it should be worth deleting it from the report.

> In #102503#1447455, @lichtwerk wrote: > Cannot repro, or better: I can repro the same bug in 2.93 > @SmugRainbowPony : what makes you think it was working there? Initially when testing, I would go through the steps and see if I got extra strokes. I opened 2.93.6 and tested again. Opening the report file I provided with 2.93.6 does give extra strokes ![image.png](https://archive.blender.org/developer/F13936435/image.png) but when I go through the steps in a new 2.93.6 file, the problem doesn't appear ![image.png](https://archive.blender.org/developer/F13936432/image.png) @lichtwerk did you go through the steps or open the file? Apparently my provided file isn't test-reliable, though, so it should be worth deleting it from the report.

In #102503#1447461, @PratikPB2123 wrote:
Could you check with following file?

That file has the Source Type set to Object.
If you set it to Collection and choose Collection 2 and do the rest of the steps, then yes, I get duplicate lineart as reported here in 2.93

> In #102503#1447461, @PratikPB2123 wrote: > Could you check with following file? That file has the `Source Type` set to `Object`. If you set it to `Collection` and choose `Collection 2` and do the rest of the steps, then yes, I get duplicate lineart as reported here in 2.93

@PratikPB2123 : you changed the report description to be obect instancing, but the title still says collection instancing.
But I can confirm THAT behavior was working in 2.93 and not master, so you just found another bug :)

@PratikPB2123 : you changed the report description to be obect instancing, but the title still says collection instancing. But I can confirm THAT behavior was working in 2.93 and not master, so you just found another bug :)

btw. I would recommend setting the collection in the lineart modifier to TARGET and not ASSET in the original file (but that doesnt resolve the issue either).

If you set it to Collection and choose Collection 2 and do the rest of the steps, then yes, I get duplicate lineart as reported here in 2.93

Can indeed reproduce in 2.93 if I do so. But "Object" was mentioned as the source type for the modifier in the original report.
Maybe we can unify both the issues in this single report :)

you changed the report description to be object instancing, but the title still says collection instancing.

Report title and description still suggests to create instance of a collection, no?

> If you set it to `Collection` and choose `Collection 2` and do the rest of the steps, then yes, I get duplicate lineart as reported here in 2.93 Can indeed reproduce in 2.93 if I do so. But "Object" was mentioned as the source type for the modifier in the original report. Maybe we can unify both the issues in this single report :) > you changed the report description to be object instancing, but the title still says collection instancing. Report title and description still suggests to create instance of a collection, no?

So there are two issues here, then?

Instanced lineart with object source type worked in 2.93 and not master
Instanced lineart with collection source never worked

am I correct?
Should I create another ticket for the collection version?

So there are two issues here, then? - Instanced lineart with object source type worked in 2.93 and not master - Instanced lineart with collection source never worked am I correct? Should I create another ticket for the collection version?

I would actually prefer to have two separate reports (reason being we can call one a regression, the other one not)

Changed status from 'Needs User Info' to: 'Confirmed'

Opened new report: #102649 (Instancing collection of LineArt with collection source creates extra strokes)

Added subscriber: @ZedDB

Caused by d1e0059eac

CC @ChengduLittleA
CC @ZedDB

Caused by d1e0059eac CC @ChengduLittleA CC @ZedDB

It's really weird. I shall take a look. From the look of it it's because line art recursively loaded linked collections. I'll see how to prevent it

I can confirm that this function never worked as one would assume. However... If you move the grease pencil object outside the Collection 2, there will be no ghosting, suggesting that it's not line art itself loading stuff twice, but the GP object being actually instanced... I tend to keep the the current logic as-is because it's doing what it supposed to do, and line art can't really control whether the line art object itself should be instanced (nor does it have any way to tell if itself is being instanced), so my suggestion is simply not putting line art inside any of the instanced collection.

I can confirm that this function never worked as one would assume. However... If you move the grease pencil object outside the Collection 2, there will be no ghosting, suggesting that it's not line art itself loading stuff twice, but the GP object being actually instanced... I tend to keep the the current logic as-is because it's doing what it supposed to do, and line art can't really control whether the line art object itself should be instanced (nor does it have any way to tell if itself is being instanced), so my suggestion is simply not putting line art inside any of the instanced collection. ![图片.png](https://archive.blender.org/developer/F13968292/图片.png) ![图片.png](https://archive.blender.org/developer/F13968295/图片.png)

I'm confused with "it's doing what it's supposed to do"

The lineart modifier is told to outline a specific object, not a collection, or several objects, just the one.
It should, when instanced with that object, behave as a copy after evaluation.

See these screenshots of 2.93:

Screenshot 1 is the ghosting situation we've been talking about, and doesn't ghost at all.

Screenshot 2 has been provided to further discuss "what I expect from instanced lineart".
It shows that the instance is obstructing the original cube to the camera, therefore the lineart doesn't draw some lines, and those are reflecting in the instance.
While unwanted in most cases, this is what I expect from an instanced lineart.

The repeating of the instances in the lineart doesn't strike me as "what it is supposed to do", because the instances are not part of the target, even when instanced.
What I see from all the ghosting screenshots is that the original GP object gets fed the instanced object as a source for the lineart modifier, thus it appearing as well on the instanced GP lineart.

Now things would be different if the manual and the UI were clearer about the nature of the lineart object's source type. "Object" sounds like a single object to me. But if it is meant to include instances of said objects, then yes it's doing what it's supposed to do, it just was never clear to the user that it was supposed to do this.

I am noting now that the lineart modifier has a setting checkbox to include or exclude instanced objects in the computation. When turned off, the ghosting doesn't appear, while the instanced lineart stays.

This makes sense. I think the manual (and maybe the UI) should be clearer about what having "object source type" and "instanced objects" together means.
I personally would expect the "Object" source type to mean a single object, not all of its instances, and the "instanced objects" setting to have meaning only when targeting several objects with, say, the scene or collection source types.

I'd like to know what others think about this.
At any rate, the behaviour changed after 2.93, and if it's not a regression, then it's a change of specs that hasn't been made clear in the UI and manual.

I'm confused with "it's doing what it's supposed to do" The lineart modifier is told to outline a specific object, not a collection, or several objects, just the one. It should, when instanced with that object, behave as a copy after evaluation. See these screenshots of 2.93: ![image.png](https://archive.blender.org/developer/F13968546/image.png) ![image.png](https://archive.blender.org/developer/F13968551/image.png) Screenshot 1 is the ghosting situation we've been talking about, and doesn't ghost at all. Screenshot 2 has been provided to further discuss "what I expect from instanced lineart". It shows that the instance is obstructing the original cube to the camera, therefore the lineart doesn't draw some lines, and those are reflecting in the instance. While unwanted in most cases, this is what I expect from an instanced lineart. The repeating of the instances in the lineart doesn't strike me as "what it is supposed to do", because the instances are not part of the target, even when instanced. What I see from all the ghosting screenshots is that the *original* GP object gets fed the *instanced* object as a source for the lineart modifier, thus it appearing as well on the instanced GP lineart. Now things would be different if the manual and the UI were clearer about the nature of the lineart object's source type. "Object" sounds like a single object to me. But if it *is* meant to include instances of said objects, then yes it's doing what it's supposed to do, it just was never clear to the user that it was supposed to do this. I am noting now that the lineart modifier has a setting checkbox to include or exclude instanced objects in the computation. When turned off, the ghosting doesn't appear, while the instanced lineart stays. This makes sense. I think the manual (and maybe the UI) should be clearer about what having "object source type" and "instanced objects" together means. I personally would expect the "Object" source type to mean a single object, not all of its instances, and the "instanced objects" setting to have meaning only when targeting several objects with, say, the scene or collection source types. I'd like to know what others think about this. At any rate, the behaviour changed after 2.93, and if it's not a regression, then it's a change of specs that hasn't been made clear in the UI and manual.

Added subscribers: @mendio, @antoniov

The repeating of the instances in the lineart doesn't strike me as "what it is supposed to do", because the instances are not part of the target, even when instanced.

What I see from all the ghosting screenshots is that the original GP object gets fed the instanced object as a source for the lineart modifier, thus it appearing as well on the instanced GP lineart.

Ahh I see. Yeah I can confirm the behaviour is like in your screenshot when object is selected as source. The way line art works now does imply that instanced object would be selected together with the original one. I believe the change from 2.93 is we introduced a new object loading method for line art and it behaves this way to make sure that child particle (instanced object) being selected by the source object, rather than with the parent for better control when there's a lot of particles in the scene. This behaviour change in collection instance+object source selection is likely the by-product of this.

I am noting now that the lineart modifier has a setting checkbox to include or exclude instanced objects in the computation. When turned off, the ghosting doesn't appear, while the instanced lineart stays.

Yes, that option is also used to quickly toggle instances (original intention is for particles) so it won't take too long to calculate when you adjust parameters.

This makes sense. I think the manual (and maybe the UI) should be clearer about what having "object source type" and "instanced objects" together means.

I agree... I need to think of a better way to reflect this in the manual and the UI. The current "object source" logic does allow finer controls over particles, but it made it weird when it's from collection instanced objects rather than particles. I need to check if code-wise line art could distinguish these two types of scenarios when loading objects. If not then we might need to come up with something different at least on the interface.

Thanks for the feedback. Let's see if GP guys have some more input on this.

@antoniov @mendio @ZedDB

> The repeating of the instances in the lineart doesn't strike me as "what it is supposed to do", because the instances are not part of the target, even when instanced. What I see from all the ghosting screenshots is that the *original* GP object gets fed the *instanced* object as a source for the lineart modifier, thus it appearing as well on the instanced GP lineart. Ahh I see. Yeah I can confirm the behaviour is like in your screenshot when object is selected as source. The way line art works now does imply that instanced object would be selected together with the original one. I believe the change from 2.93 is we introduced a new object loading method for line art and it behaves this way to make sure that child particle (instanced object) being selected by the source object, rather than with the parent for better control when there's a lot of particles in the scene. This behaviour change in collection instance+object source selection is likely the by-product of this. > I am noting now that the lineart modifier has a setting checkbox to include or exclude instanced objects in the computation. When turned off, the ghosting doesn't appear, while the instanced lineart stays. Yes, that option is also used to quickly toggle instances (original intention is for particles) so it won't take too long to calculate when you adjust parameters. > This makes sense. I think the manual (and maybe the UI) should be clearer about what having "object source type" and "instanced objects" together means. I agree... I need to think of a better way to reflect this in the manual and the UI. The current "object source" logic does allow finer controls over particles, but it made it weird when it's from collection instanced objects rather than particles. I need to check if code-wise line art could distinguish these two types of scenarios when loading objects. If not then we might need to come up with something different at least on the interface. Thanks for the feedback. Let's see if GP guys have some more input on this. @antoniov @mendio @ZedDB

I haven't looked at the code, but I think it probably should be possible to determine what cube should be used as the render engine does render the cube correctly?
It feels a bit weird otherwise that the workbench render engine can get the correct triangles while the modifier can not.

Of course I know it is not as simple because we can't use the same API and the render engine.
However it doesn't seems like it should be impossible either.

I haven't looked at the code, but I think it probably should be possible to determine what cube should be used as the render engine does render the cube correctly? It feels a bit weird otherwise that the workbench render engine can get the correct triangles while the modifier can not. Of course I know it is not as simple because we can't use the same API and the render engine. However it doesn't seems like it should be impossible either.

Added subscriber: @ThomasDinges

Any updates here please? @antoniov @mendio would be good to get your feedback so this high priority report can be solved.

@ThomasDinges Sorry, but we don't know this area of the code... @ChengduLittleA Do you have any update of this high priority bug?

Changed status from 'Confirmed' to: 'Resolved'

I don't think the current code logic is gonna change unless there's modification to the dg evaluation path. So as long as this can be mitigated by either putting the gp object out of the instanced collection or disable instanced objects in line art, I think this problem can be marked as resolved.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Regression: GPencil Line Art modifier creates extra (offset) strokes on collection instances #102503