What you are talking about is more of a LOD thing - how many fragments(samples) are generated within a screen pixel. This is mainly due to the image resolution; for example, the figure below compares the extracted strokes from Pencil+4 and my algo, when viewport resolution is not enough to support outline samples:
I’d argue that in this case, purely geo-based algorithms like Pencil+4 suffer since the extracted strokes are complete but very dense and overlapped; they still need simplification to provide a natural LOD at the image - which again leads it back to image-based algorithms.
And that’s why I prefer a hybrid system - compute 3d lines from mesh edges, then raster them into pixels and link them to strokes. This allows us to benefit both from the geo- and image-based algorithms.
For more details about my thoughts on geo-based, image-based and hybrid line art systems:
[quote=“ChengduLittleA, post:11, topic:28078, full:true”]
From the paper demonstration, the performance is impressive. I’m not sure if you were to render very big how is that gonna slow down, and/or if the GPU is tiling the render, will there be stitches on those chains which would result in a visual “line” across the image. For comparison, I rendered a line art output on a 15000x10000 output… Which it just went fine because the performance is not resolution-sensitive (Which could also be a downside if you are rendering small, pixel based methods generally handles LOD naturally)
The benefit of current Line Art algorithm is that the entire pipeline being vector (which then naturally allows edit), and it does layered occlusion so it’s possible to have controlled see-through. For other usages I don’t see why we don’t give raster based algorithm a go.
I’ve been using the compute shaders in Blender and ported some basic shaders from my Unity project, it is not the best but barely enough for me to implement the algo.