GSoC 2019 LANPR Development and Feedbacks

Hey fellas, I’m YimingWu who is taking part of GSoC 2019 development for LANPR.

I created this page for development specific topics. Please feel free to suggest anything :smiley:


Week1 Report is here:

There have been some discussions on how to integrate LANPR with current workflow of EEVEE and Cycles. More info will come. And also of course please share your thoughts below.


These are very minor points, but can I suggest moving the LANPR panel from the Scene tab to the Render tab. I think that’s more consistent with how Cycles and Eevee do things.

Also, it would be nice to set some default values so that you see something as soon as you switch to the LANPR renderer.

1 Like

Thanks for the suggestions. Yes, I guess I will put it into render panel. When I was making UI for LANPR I refereed to how Freestyle was doing it. Now I think it doesn’t matter where it should locate.

As for present, there is only one button that creates the only present I made now, Maybe will do for now but will definitely add some useful presents in the future when we settled on a solid workflow design.

Hi, thanks for contributing to Blender! I have some questions/suggestions related to your week 1 report. I see you’ve added Grease Pencil stroke generation. Does this create 3D strokes along the countours of the objects, or are the strokes relative to the view (2D, as if drawn on a glass screen)? If I understand your report correctly, the old Freestyle code can create 2D GP, and your LANPR code can generate 3D GP strokes. And they are created at render time.

Is it possible to ‘bake’ the LANPR result out into the scene as Grease Pencil (that stays in the scene regardless of whether LANPR is enabled)? This would save performance, since maybe you would only have to re-generate lines on a per-object basis while animating. Also, artists could refine individual strokes and materials iteratively. In the short term, this would make it possible to mix LANPR and EEVEE without compositing.


1 Like

Yes - my main advice is to not look at how Freestyle was integrated. We should rather aim to integrate LANPR in the most optimal, flexible, and logical way.

As for the render panels, note that you can use sub-panels to organize panels in a hierarchy.

Design-wise, the solution for how to integrate isn’t entirely obvious.

The simplest/cleanest solution is to simply add it as a separate render engine, and then use other methods to combine it with Eevee, Cycles or other renderers. This also makes it possible to completely skip Eevee or Cycles if you just want to render lines alone.

Another way would be to integrate it more like Grease Pencil, which is more transparent and perhaps convenient, although also somewhat more messy.


Are there other plans about how Blender should integrate different render engines? What seems logical to me from an end-user point of view would be to allow each view layer to override the current render engine, then you can composite them together however you like. That’s probably a bigger project than is feasible here, of course.

1 Like

Here I have this week’s update here because it’s already Friday. I may still update some process during the weekends.

1 Like

Week 3 update!



Awesome! Thanks for keeping us updated :smile: .

1 Like

I love this <3

Keep on!

I think I saw something about this a couple of years ago, probably another GSOC . Its the same developer ? How much is the progress since then ? anyhting already impemented ? (new to Blender)

Yep Yiming also worked on LANPR on gsoc18
@LazyDodo has gracefully provided us with daily builds on rightclickselect Graphicall

As for stuff you can get the build and start playing around. Atm I’d say user experience is pretty “meh” but it is definitely pretty interesting and promising, though.



Here’s the late update of this week.

I managed to get the object->gp selection working today. Here’s a preview image of it

Some image-space reduction problems are still there, but I’m getting close.
Next week will mainly implement automatic stroke generation.


The reduction in 3D space looks like this. Should add a switch to change which algorithm to use depending on what kinds of models are in the scene.


There are 2 things that don’t work in Layer Settings subpanel of LANPR render settings.

First, unique level setting that corresponds to QI Begin. User have to enable Use Multiple Levels button and to set a coherent QI End value.
Second thing is that when Same Style option is enabled, precised value for thickness is used as a factor/multiplier of itself for types of strokes different from Contour.
When option is disabled, Stroke thickness is as before meaningful for Contour and a factor/multiplier limited to a value between 0 and 1 for other types.
In both cases, that does not make sense to have a multiplier dependent to Contour thickness.
It is easier to see a value of reference and set an higher value to have a bigger stroke or a lower value to obtain a thinner one.

In case of stroke thickness, user don’t make a sophisticated comparison : “This kind of stroke should be 2/3 of this one.If this one is 2/3 of main one, this one have to be 1/6 of main one.”
It is really. "This one should look thinner and this one should look wider. "
So, user does it comparing types of strokes 2 by 2 with absolute values. That is really simpler than making comparison 3 by 3 with values relative to thickness of main stroke type.

So, it would help to fix this, first. Because, currently, using modifiers do not seem to take into account any thickness setting, too (from LANPR render settings or from GP object settings).

Hi Ronan! Thank you very much for the feedback!

The multiple level button is for simplicity, so that when adding multiple layers, user will only adjust this one value if they are using single layer. But could be further simplified by providing a “visible/invisible” switch, and use QI when necessary.

Thickness thing is a legacy design, which should be changed. Preferably using the “main thickness” strategy. However GP is also able to control thickness using modifiers and layers, so if that is the case we need think more about how this is best handled. Yes, currently the GP stuff does not handle thickness at all.

I’ll write down these into the notes. Thank you for testing these out :smiley: !

1 Like

As for today’s progress, you are now able to do LANPR->GP animations with a “Bake” operation, it will generate GP strokes for all the frames between the start and end. You will need to specify object’s GP target or collection’s GP target in order for the strokes to appear. However, automatic updates on frame changes is not yet available.



“Bake” will hung up your UI until it’s done. so use smaller frame range to test how long it might take before you click the botton.


Week 5 Report is here. A bunch of fixes and many features are now complete.
See the report for how to use object/collection flags and stroke chaining thresholds.

Happy weekends every one!


Just trying out LANPR on a project, it seems a bit conveluted to get started… my only success has been:

  1. switch to LANPR engine
  2. enable LANPR
  3. Under CPU, click default line layers
  4. Switch to GPU
  5. Switch to Material Mode

This will give the whole scene the edge rendering look i am after. However, if i press f12 or try viewport rendering it doesnt work.

Any suggestions on how to get CPU based LANPR working, and how to render out frames, would be much appreciated.