This is achieved now by using LANPR engine’s preview (YEAH:wink:). For three algorithms in LANPR, the results are all instantly visible if you adjust the value, because It uses OpenGL to render preview lines and it is fast. In freestyle any tweaks will require re-render of the scene, too slow for protrotyping.
This is also ok, as the render engine’s infrastructure is now full up and running, adding such support would be considered easier than implementing the engine itself.
This is a great paper. I’ve read that, but it involves a lot more aspects other than geometry, which would add a lot of complexity. So this should be put off until anyone else who is interested about implementing it.
We have EEVEE now it couldn’t be more simpler to do cartoon shading
The Snake method is implemented base on the same approach as JOT/WYSIWYG NPR, but line extraction is a bit different (which cause some artifacts, need optimization) than them. There’s a newer paper about line temporal coherence which deals flickering lines in animaiton. I’ll try to link it later.
Hi, Ace_Dragon, I’m told by the developers that overlay problem will be solved until they finish developing the viewport composition system. So don’t worry about that.
Hi zanzio, this is a good question though. On my view, it’s kinda like both. Freestyle is too slow and sometimes buggy. In my code, at least it’s fast enough (multithread) and also accurate. And my method produce intersection lines, which Freestyle is incapable of. I decide not to implement some of the rarely used functions in Freestyle. So it’s kinda back-forth a bit. Maybe I would like to say LANPR is just like Freestyle, but it’s fast and accurate, it even comes with a real time one right? So be happy
1 level of occlusion. Front Lines/ Hidden lines is sufficient and is mostly what is expected.
Most of people don’t search to distinct several level of occlusion inside one object.
More levels of occlusion is wanted between different objects.
Object on foreground. Object on second plane. Object on background.
But this is frequently done at compositing. So if it is possible to create a mask that handles object+external contour thick lines, user can achieve most of wanted cases.
I have difficulties to build your branch under ubuntu 16.04.
It fails at 48%.
It is searching a file named DNA_listbase.h. But file is named DNA_listBase.h in sources.
Complete building log
Hi! Thanks for joining the discussion and for working on LANPR. You seem to be making great progress and I hope your work will be merged for Blender 2.8
Whilst not terribly experienced with Freestyle, I have used it in the past and all I can say is that it was far too complicated just to get a simple line render. If you are able to achieve the results shown in your Twitter posts without creating several layers, each with different masks and thickness settings, then it will be amazing. A lot of the time users just want something very simple, such as a thick border outline and slightly thinner internal edges with intersections.
Is it possible in LANPR to scale line thickness based on scene data such as depth, edge angle, crease etc? You mentioned it should be possible to convert to SVG, do you have any plans to convert to other forms of vector representation, such as Grease Pencil, or for LANPR to work with Grease Pencil in some other way?
Hold on I’ll check it, no problem under Win VC14 though… probably some stupid thing I messed.
Edit: VC14 works, don’t quite know where the problem is, standby.
This is a new idea to me, I can spend some time considering how to achieve this.
So making it easier to use, yes, I may create some presents (wait until I find a way to do so:) ), then for some basic usages you can get youe scene running in several clicks.
Yes. (need improvements) Grease pencil currently have nothing to do with LANPR, but there’s a chance that we can convert the line result between two things. But I can consider this as a future development as currently we don’t even have a F12 that works properly xD…
Quick updates: Multithread calculation achieved, fast CPU render made possible.
Now, selecting lines from specific obj, material, collection is also available.
Small bugs still presents on contour lines, will try to fix them.
Could you tell me why are the vertical lines thicker then the diagonal/horizontal ones?
And about those small bugs… are you talking about the gaps at corners?
From simple vector drawing experience they are like that because they are separate lines, not merged. Is it possible to merge them?
If not, putting round caps on their endings might solve the issue.
(These might be totally out of context in a 3d line drawing but why not share my thoughts…)
Oh, hi, the effect you are seeing is because viewport is stretched a bit and the coordinates are not, I’m using the basic draw calls to debug the feature though, will fix it.
Lines can be chained, so then there won’t be gaps, just give some time and it will be perfect:)
Caution: No F12. You DO NEED A CAMERA when using software rendering. Stop using Edge Split modifier if you get wired result. User instructions will come up shortly but with new ui it should be easy to figure out how everything works still have bugs, but results for most of the models are very good to go!
Unfortunately I keep getting constant crashes on previously saved blend files under this Blender build so I can only edit and jam in a session.
I also could not figure out how to changed the background color in Blender, all colors are by default black with 0 alpha - so setting up the line colors and thickness values is tedious.
@xp8110
Will there be a way to overlay your LANPR in realtime over say EEVEE or Cycles using their new viewport render layers? With the current roadmap I assume one would have to switch back and forth engines (or workspaces) and save the render results to then comp them together in the compositing editor. I would be great if there was a way to render with 2 engines at the same time, perhaps a priority once this engine gets stable and in the official branch.
Oh, forgot to mention (ahhhh) don’t use this version to save, there’s an unsolved data issue there. This version is considered (relatively) stable when running though… but crashes are expected…
the layer stuff haven’t finished developoing on engine’s side so we have to wait.
@xp8110
I noticed that the more I push the vieport FOV towards the maximum of 120 degrees lines turn see through almost like a xray effect. Will there be support for Orthographic projects?
So after learning that saving the blend file is not a good idea I can confirm that it crashes on some super high dense models, e.g. hundreds of objects with 3x subdevision enabled. Same with high dense particle systems.
Looking forward to future releases hopefully growing also more stable: Because there is plenty of stuff that I would like to throw at it to see what can be done.
so I can only edit and jam in a session.