This option should probably called "Stroke Depth Offset" or just "Depth Offset" as Stroke offset could also mean other types of offset.

In D12046#318195, @Henrik Dick (weasel) wrote:

This option should probably called "Stroke Depth Offset" or just "Depth Offset" as Stroke offset could also mean other types of offset.

Good point

Things that should change:

• extend hardrange of the property to allow for very big and even negative numerical input outside of the usual range.
• math is incorrect for orthographic cameras -> make the math use the projection matrix to cover both cases.

Here is a couple points to think about:

• do we really need to lock the slider, deactivate the offset and show a warning if "In Front" is active? Why not just leave it functional, even if pointless? Maybe it will be useful for someone when they can select custom cameras.
• what happens if the object is close to the camera, maybe clamp to the cameras near plane so the lines stay visible.

I meant that I am not sure that this detection of "In Front" from the modifier is needed at all.
Maybe it would be better if the modifier just didn't know about it and therefore it would not influence the output.
As long as it does, the warning is obviously very good.

Most important snippet from my question was: "Do we really need to deactivate the offset, if "In Front" is active?"
What is your reasoning there?
In general: just because you don't see a use for a case right now doesn't mean somebody else won't find a use, so
I always try to be as non restrictive to the user as possible.
(same for value hardranges. IMO hardranges should only come from implementation limits, not from what makes sense)

That's a good point. Maybe the modifier should not care about the "in-front" state. The reason for that is this function being mainly designed for allowing depth interaction between line art stroke and scene objects while not having z-fights, so if in-front is on, there will be no depth interaction so this extra offset step is not needed, which saves some cpu cycles.

I can see some weird use cases where this offset is used to create specific visual effect, not sure if this also aligns with the design purpose of line art, but people can use it that way 🤔

Another reason that the modifier should care about in-front state is because line art can show occluded lines, if in-front is off we don't generate extra lines because they are supposed to be hidden by depth in the viewport. If the user wasn't aware of the state of the in-front option when creating line art object, they may not understand why e.g. hidden lines can't be shown correctly.

Please don't forget that Line Art is a Grease Pencil Modifier, and as we discussed before, the main problem with the In Front aproach by default is that it doesn't work well with other Grease Pencil object in the scene.
For 2D Artist is key to have a nice integration between a 3D NPR background using line art and their 2D animations using standard Grease Pencil object. The Stroke Offset property allow that integration.

We should keep working on a better Stroke Offset that avoids most of the Z fighting problems or find alternative solution to that Line Art-Hand Draw stroke combination problem.

@Matias Mendiola (mendio) given that we now have a panel where user can choose between in-front or offset let's try to re-evaluate our position on default state.

First off... do we have some stats data on how many users use Lineart with other GP objects?
My initial position was "default in-front ON" to solve issues with other GP objects.

However, I find that such scenes only account for < 10% of time. Hence I find myself often manually go through object settings and toggle it in viewport display (because you do one or two steps already and the F9 panel is long gone).

In short, because of experience I would now change my default position to "in-front ON"

@YimingWu (NicksBest): latest patch does not apply to master for me:

error: patch failed: source/blender/makesdna/DNA_gpencil_modifier_defaults.h:307
error: source/blender/makesdna/DNA_gpencil_modifier_defaults.h: patch does not apply

In D12046#319972, @Matias Mendiola (mendio) wrote:

Please don't forget that Line Art is a Grease Pencil Modifier, and as we discussed before, the main problem with the In Front aproach by default is that it doesn't work well with other Grease Pencil object in the scene.
For 2D Artist is key to have a nice integration between a 3D NPR background using line art and their 2D animations using standard Grease Pencil object. The Stroke Offset property allow that integration.

We should keep working on a better Stroke Offset that avoids most of the Z fighting problems or find alternative solution to that Line Art-Hand Draw stroke combination problem.

I completely agree on this and think that we should work on solutions which bring the different blender objects together.
The next patch could be a "contour offset" or "normal offset" to get rid of z-fighting on the contours.
(Also for thick outlines it's way better to offset them to the outside to avoid shrinking the model)

I actually think that in the future the In-Front option should be replaced by something that is not seemingly viewport bound (It's causing confusion).
One current solution for rendering is to disable the Z render pass. Maybe we could have a solution like that, that would work in the viewport and in the render.

Hi @Matias Mendiola (mendio) @Antonio Vazquez (antoniov) can we get approval on this patch? (default in-front on) It does seem halted now but the other two later patches are approved. Do artists have opinions about it?

The reason being:

• From what I've gathered, most of time line art users are not using the offset function to make it interact with other gpencil objects...
• EEVEE for GP or an alternative composition solution does not seem to be any time soon...

The offset value slider is also added on the object_add panel so it should be quite clear what the option will do.

Thanks!

@Henrik Dick (weasel) . @Antonio Vazquez (antoniov), @Matias Mendiola (mendio) what is the status of this? still candidate for 3.0?

I think this is a crucial feature - it solves for the first time having a drawn GP object with lineart in a single scene.