Hi! It’s Yiming here and I have a new proposal for improving line art feature in the new grease pencil designs:
UPDATED: 2023/03/18
It includes performance and usability topics, please feel free to comment and share your thoughts on this and I think we can make line art better together!
I think that issue of flexibility is created by the fact, that we are asking a grease pencil object to do everything.
If what is expected for performance is use of a 2D buffer from GPU, why making the feature dependent of a 3D object. Especially, at time of Viewport compositor.
I think that some LineArt compositing nodes producing effects in viewport, through viewport compositor, using Z pass, Normal pass, cryptomatte, AOVs and/or a specific viewlayer input should be a target.
That being said, it is great to obtain geometry in 3D space from camera, that can be edited, sculpted, duplicated, animated with offsets in 3D space, converted back into meshes and curves …
3D is part of flexibility.
But I think that would be a mistake to keep everything in Line Art nodes , next to geometry nodes.
That will be redundant and transfer complexity, at modifier stack level, between geometry nodes modifiers and LineArt nodes modifiers, if nodetree were separated.
Can you confirm that proposal is about creating Line Art nodes as a categories of GN nodes ?
What is exposed in you LineArt Segment Vertex node, LineArt Adjust Segment node, LineArt Chain Property node does not seem sufficient to create changes along stroke.
In Curve nodes of geometry nodes, we have a Spline Parameter node that makes this kind of tweaking a piece of cake.
I would expect an Index node, too, to make those nodes work with easy “less/more than integer” setups.
I would expect ability to use those nodes with LineArt Selection node.
To create a Depth Offset or Angle Splitting, we would need GN nodes.
So, I suppose that is the case that we are talking about a category of GN nodes. But I may misunderstand.
Proposal talking about upstream and downstream procedurally generated geometry is not clear.
Are we talking about nodes for a LineArt modifier, that could take a GN modifier as entry, and be followed by another GN modifier ? about a category of GN nodes, for Grease Pencil objects only ? about a category of GN nodes for any object type, where setup used to generate meshes can be reused to influence Line Art Strokes ?
It looks like the last one.
In that case, for meshes, Output should precise GP layer, too, not just GP object.
For GP objects, if GN modifier is added to them, ultimate output expected would be a simple Geometry output, but also with GP layer indication.
At the opposite of tree, I suppose that Edge Marks would be considered as an attribute.
So, LineArt Calculation node should be able to handle named attribute.
It is hard to have an idea if it will be sufficient, if we don’t know what GN nodes will be supported, too.
Currently, stylization is done by GP modifiers more than LineArt modifier.
GN nodes supported have to be able to replace those GP modifiers.
Some of them, like Outline and Envelope, are not so obvious to replace by GN made for meshes or curves.
GP Material tweaking from LineArt modifier is also minimal.
It looks like nodes to tweak a Fill material is out of scope.
But nodes to tweak Stroke material, will there be able to assign a different texture to start/middle/end of stroke ? to enable/disable Holdout, Self Overlap options ? or to change Line type ?
Will there be an extension of abilities of GP materials or do we stay with few basic abilities ?
I agree with zeauro here, it’d be great to have this as a part of GN nodes.
When I was trying line art (with the name confusing me a bit) I was always looking to add artistic outlines to meshes which demanded a bit more flexibility. With all the geo nodes stuff one could maybe make things like pencil stroke outlines and the likes. Something I was hoping for was bigger freedom when crating outlines and shadows, and this way we could have presets stored as node groups the same way the hair object does.
Yes, that’s actually a important issue here. Feature line stuff are generally image-space boundaries, and in the sense of traditional art, the line art doesn’t happen at one certain stage: Some are used to define object boundaries, some are there for suggesting form but technically there’s no hard lines, and some are used to shade stuff. To mimic/replicate how artist do those things, we actually need a fully customizable render pipeline, which allows us to feed results from each stage back to some previous ones and redo some renderings.
Generating line art from raster passes does have a lot of benefits but also leaves some other problems like sub-pixel resolution not adequate enough. (Which would also be a problem in the “biased” algorithm in the proposal) It would be best if we can actually have a render pipeline that can be rerouted as needed but I’m not quite sure if that’s aligned with the current roadmap of blender (and even if it does, it’s gonna be a really complex structure).
Can you confirm that proposal is about creating Line Art nodes as a categories of GN nodes ?
I’m not quite sure how this works internally, but I think this is indeed what I meant. It then allows us to combine GN nodes with line art.
Proposal talking about upstream and downstream procedurally generated geometry is not clear.
Here it’s meant to provide a generic array, which is gonna be very similar to regular mesh data, or an array structure similar to sverchok. Like… a “Geometry” socket with internal structure of a series of points and a list of edge pairs.
setup used to generate meshes can be reused to influence Line Art Strokes ?
Yeah, it should be no difference plugging in procedurally generated meshes or existing ones.
Currently, stylization is done by GP modifiers more than LineArt modifier.
That’s where we have most of our limitations currently. Line Art has a lot more data than it’s exposed to GP (or anything), now it’s almost impossible to stylize strokes based on normal and light direction, by using “Line Art Nodes” we can have those pieces of information available without going through the GP stroke container which then gets rid of most of the stuff.
It looks like nodes to tweak a Fill material is out of scope.
Line art does not generate enclosed regions, thus this does not apply to line art. However it can exist as a generic GPencil node.
But nodes to tweak Stroke material, will there be able to assign a different texture to start/middle/end of stroke ? to enable/disable Holdout, Self Overlap options ? or to change Line type ?
Of course there can be. The proposal is just an simple example of how the node system might be like.
Will there be an extension of abilities of GP materials or do we stay with few basic abilities ?
I believe the new GP is gonna have the same material as EEVEE, so fingers crossed
Presets is gonna be part of the node tree thing I believe, it’s then gonna be much easier for people to use line art.
Ok. I don’t see a problem in the flow of nodes in the graph of this mock-up.
I am just wondering, at what point, those nodes could be redundant with geometry nodes creating GP strokes from scratch like Curve or Mesh nodes.
Will GP strokes generated by GN be simply curves converted into GP strokes, like volumes are converted meshes, or will there be a GP sub-menu with many specific nodes, like Curve and Mesh sub-menus ? or a GP sub-menu with an intermediate amount of nodes, like Instances and Points sub-menus ?
We have a global Join Geometry node able to join any type of data.
It would be normal to have it able to join GP primitives.
But will LineArt segments be considered as GP strokes before chaining is done ?
If it is the case, LineArt Selection node, LineArt Intersection Selection node and LineArt Adjust Segment will probably be redundant with generic GN used to select GP geometry and adjust GP attributes.
If it is not the case, will those nodes able to handle Grease Pencil Read nodes and Utilities nodes ?
What is exposed in the example seems to be insufficient for more complicated case.
I talked about ability to customize along stroke in my previous post.
You confirmed that more data like normal and light direction will be exposed.
Absence of occlusion level seems to be a limitation that would have to be compensated by GN.
Any people, willing to simulate a transparent object, would like, at least, a 0-1 range.
So, if a geometry node workaround, duplicating geometry and deleting front faces, has be used for that, too :
my conclusion is that generic Geometry Nodes for GP should probably be done before LineArt nodes.
That is possible to start a branch with your design. But that design would probably have to evolve with introduction of more generic GN nodes.
Compared to solving the visibility cuts using generic geometric nodes, Line Art internal algorithm is much much more optimized. You can do a feature line detection with geo nodes relatively quickly, and if that satisfies the usage requirements where you only use depth to compose the lines to get occlusion, it’s then more convenient.
I’m not sure how we will approach this exactly, until we get a basic geo nodes setup for GP (or a relatively light subsystem of geo nodes) so we can build on top of it. If the data isn’t in line art internal format, it should be compatible with existing geo nodes.
No this is the case where data is represented as line art internal data structures for preserving those line art specific properties.
my conclusion is that generic Geometry Nodes for GP should probably be done before LineArt nodes.
Exactly, we are not basically thinking about the possibilities, and geo nodes for GP is the most likely approach, so by doing this, other developers will be aware that line art (or similar stuff?) should be taken into account then we won’t go into a weird mess.
OK. So, in that case, we need Line Art data to be compatible with nodes from Geometry category.
And specific Line Art data should have its own Read, Sample and Write nodes.
LineArt Segment Vertex and LineArt Chain Property nodes, as in mock-up, will not be sufficient.
We will need nodes to adjust LineArt data at chain level.
I am thinking about fields like a Chain Parameter Factor, Chain Parameter Index, Chain Resolution, a LineArt Adjust Chain node (similar to Line Art Adjust Segment but at chain level) and operation nodes to smooth, displace, split, trim, delete chains.
If Line Art algorithm is more optimized for that or some Line Art data is lost by conversion to GP data, it is valuable to have nodes to tweak chains and not just segments.
The node-lineart proposal is updated with a newer design to reflect on the knowledge of how GN works, and I try to make the node compatible with existing generic GN stuff.
Could use a bit more feedback 
Thanks guys!
Hello !
I just wanted to say that I really like the direction it’s taking !
Is there any area you’d like feedback on ?
Hi, anything really. Maybe also concerns on the design, like if you could imagine some scenarios that can’t be handled better with this kind of node-based designs than the original line art, etc.
Really excited to see where this is going!
Maybe I’m just just not fully understanding line art but to me it’s not super clear what a “chain” is in this context. Is it it’s own type of geometry?
Do the Filter Chain and Filter Intersection nodes have any uses outside of line art? What would happen if I take the output curves of a Mesh to Curve node and plug them into a Filter Chain node? Would it always output nothing since the curves don’t have the required data for filtering?
I guess what I’m asking is: Do you think the filtering and selecting of strokes could be done through means already available in geometry nodes rather than introducing lineart specific nodes?
Here’s a mock up of how I would intuitively expect a Line Art node to look like:
You input geometry, view, and light information and it outputs curves. All the lineart specific information like occlusion, edge type (contour, intersection…) etc. would also be an output of the node that could then be used with all the nodes already available in geometry nodes.
I hope this example tree illustrates the idea, though I’m sure some specifics are a bit wonky:
Do you think something like that makes sense at all from an implementation perspective?
I also wonder if the light and view information would have to be provided through object sockets of if it could be more general by using vector sockets. Can all necessary information of the view and light for the line art calculation be broken down to basic socket types like vectors and floats? There was prototypes of a Camera info and it would be very flexible to not always have to rely on objects that exist in the scene.
Hi! Yes and no… The chain is like “a stroke”, which is (planned to be) exposed as a generic geometry same as what you see in GN, however it may lose some information that’s stored in lineart internal data type.
Do the Filter Chain and Filter Intersection nodes have any uses outside of line art
No, because it will filter those geometries based on lineart-custom-attributes. (maybe not a good idea? but this is the only way we could make it happen under current architecture)
Actually yeah, because information is stored as attributes (that is to say, the geometry is exposed as generic types), you can use existing GN attribute nodes to filter and alter stuff.
Do you think something like that makes sense at all from an implementation perspective?
Principally it’s roughly gonna be how that works, yeah. Maybe just different in some minor details, the logic seems right on.
I also wonder if the light and view information would have to be provided through object sockets of if it could be more general by using vector sockets.
Good point on the light direction… I’ll note it down in the doc. We still need camera object input tho, but light… yeah it’s possible to provide just a direction then it’s equivalent as the sun type.
OK today I updated the proposal yet again. This is after I had some more discussion with Hans et.al.
Basically what we are trying to do is to hand over filtering functionality completely over to attributes, so line art won’t need to record any specific object-reference data internally, this also makes it easy to pass stuff around with generic GN data types.
Feedbacks are welcomed!
Hi, this feature is also now proposed in the updated doc 
