Leave Filter
Prev   2/2  
Week 5 Report

Week 5 Report

GPencil Selection

This week

Feature Line Modifier

Major stuff

  1. Fixed LANPR now uses master "color" and "thickness" instead of following contour values.
  2. Done Stroke modifier now fully functional (includes target layer/material and line type selecting).
  3. Done Added LANPR settings for collection, now fully functional.
  4. Done Now you can set "Include/Exclude/OcclusionOnly" flags to objects and collections, to control what lines are needed. See below for how it works.
  5. Fixed LANPR now uses two separate threshold values for image-space and geometry space chaining. See below for explanation.
  6. Fixed Stroke sample modifier now re-written to accept bone weights in GPencil strokes. Which is also useful without LANPR.
  7. Temporary There's a "bake" button for baking frames in an animated scene into GPencil frames.

Minor Fixes

  1. if() statements now all use {} brackets to prevent potential merge errors.
  2. Comments all changed into /* */ style to follow C standard.
  3. UI fixes, hide/deactivate items when needed to make it more logical to operate on.

From the Last Week

  1. Done Stroke generation from object modifier.
  2. Fixed Chaining occlusion errors.
  3. Fixed Chain now only includes one type of lines.

Next week

  1. Chain optimization functions, including:
    • discard of very short segments
    • small loop preventing
    • overlapping reduction.
  2. GP Modifiers:
    • pattern
    • random
    • backbone stretch improvements
    • "sketch modifier"???
    • see this document for a more clear idea what this is.
  3. LANPR and GPencil frame data should be automatically updated by Depsgraph.
  4. Better have a button that only re-create strokes for current object (by the Feature Line modifier). GP strokes are not deleted when LANPR is updating them, this could lead to overlapping.

About Object/Collection Usage Flag

Collection Flag

Object Flag

This is how the usage flag works.

By default, Collection is set to "Include", which means this collection will be included into LANPR's feature line calculation. For object, the default is "Inherent", which means it follows its parent collection's settings.

If you set object's usage to "Occlusion Only", the object will still take part in LANPR's calculation, however, no lines will be produced by this object, but it can still occlude other object in the calculation. If the flag is "Exclude", LANPR will ignore this object completely, as if it didn't exist at all.

For collection, you can also set it to "Occlusion Only" and "Exclude", but if you only set the flag, the object within this collection who also happens to have a Feature Line modifier will still be included into calculation. To prevent this from happening, check the "force" option below. Then the children objects and those recursive children collections are all forced to follow the rule.

You need to set target GPencil object for strokes to appear, which applies to both objects and collections.

(注意:How to generate strokes: As of now, you need to manually click "Update" in LANPR, then click "Update" in any one of your Feature Line modifiers, and tab your GPencil object to trigger re-draw.)

About Stroke Chaining in LANPR

Chaining Thresholds

LANPR produces accurate occlusion info, yet in 3D space, those lines might be very jaggy and not good for applying a texture. Thus we need a good chaining algorithm. Currently it performs ok, LANPR uses two step chaining method now, geometry-space and image-space chaining, they can produces smooth lines in most cases, yet some cases it's hard to say which way is better.

Image space chaining

For bumpy surfaces, one might rely more on image-space chaining to erase those non-continuous bumps along a curve, however for many hard-surface scenarios, it is more important to keep the geometric information accurate. So now LANPR incorporates two threshold values for users to choose which way they want. Set thresholds to zero will disable the corresponding chaining step.

The image to the right shows a result of an image-space prioritized chaining. In which you can see the spatial result is incorrect, but it gives a smoother approximate in image space projection, which is useful in many cases, especially in rendering animated characters. Thus the two-threshold solution is necessary.

Original To-dos

  1. Startup and shaders support two extra "color" and "thickness" values.
  2. Fix pointer conversion. Should use prev/next for nodes instead of "item".
  3. GP modifier only create strokes that are in corresponding level / QI Range.
  4. GP modifier layer and material selection should go all the way to zero.
  5. GP modifier material.
  6. C-styled comment.
  7. Line type selection for both scene controlled and object modifier controlled stroke generation.
  8. Object/Image space priority option when chaining. This provides a choice for different kinds of models. Now use two thresholds.
  9. Red-out modifier name when GP target is not set. Filter only GP objects in list.
  10. Selectively clean/update strokes for a specific object. "Update" in the modifier should only update strokes that are related to this object.
  11. New GP sample function. Calculate accurate segment count. Use list pointer to store dynamic items.
  12. Collection LANPR UI.
  13. Collection LANPR target usage. With object filter for LANPR calculation.
  14. Single condition line fixes.
  15. Chain picked flag.
  16. Collection updates. Remaining strokes goes into collection target.
  17. Logic selection for objects and collections.
  18. 2D/3D thresholds for chaining.
  19. Add uniform thickness and color values in shaders.
  20. Chain split(no connection) at different types, need a switch for this in standalone mode. (Name as "Allow GP type selection"?) Switch not needed.
  21. Chain type and occlusion level debug.
  22. Sample function needs to handle weights.
  23. Shader errors. Should give shader errors when GPU mode fails to compile.
  24. Semi-Automatic bake.
  25. Automatically update.
Week 4 Report

Week 4 Report

This week

object modifier

  1. Moved stroke generation modifier to Object.
  2. UI modifications for easier use. Now named "CPU/GPU" modes for clarity.
  3. Default values now loaded with blender startup.
  4. Image-space chain reduce now have a threshold value to allow precision adjustments.
  5. Added "Include/Exclude/Occlusion Only" settings in collection.

I had three tests during the week and finally over all of them :D. Time to clean stuff up.

Things from the last week

  1. About intersection algorithm: Intersection lines do need to be clipped since visible segments could also penetrate near clipping plane. Very rare condition, but needed.
  2. Image-space chaining bug is solved from point 4 above.

Still to come

  1. Actual stroke generation functions and automation.
  2. Split chains based on their types.
  3. Check for potential segment type errors.
  4. Look for the problems in GPU mode. Now producing wrong transformations on Intel Graphics, could be a problem with DRW.
Modifier based LANPR selection design

Modifier based LANPR selection design

Mainly notes, will categorize into a design document later after basic implementation.

Object modifier side

It should have such properties:

Property Value Notes
Usage Include/OcclusionOnly/Exclude "Exclude" option will remove the object completely from line calculation thus the object will not occlude anything.
Types Contour, Crease, Mark, Material, Intersection, ModifierOriginal ModifierOriginal type is for marking the similar edges from the enabled "mesh" icon.
Target GPencil object selector
Replace Replace existing GPencil frame
Layer Which layer to put GPencil strokes into. Allow only one layer for now?
Material The material indes it should use.
OcclusionRange The QI range in Freestyle. For allowing different occlusion level using different material and line config, add another LANPR modifier.
VertexGroup Select vertex group for in/exclusion Enough, no need to combine material logic.

Main Panel under Render Tab

Mainly global configurations. Properties worth mentioning are listed below.

Property Value Notes
Enabled False/True LANPR checkbox, delete lanpr buffer hen disabled.
MasterMode CPU/GPU/EdgeDetection (At least change the UI name into a more intuitive way) No idea whether to keep EdgeDetection or not.
SameStyle False/True Use the same style for different line layers. Only effective when not using GPencl.

Collection side

Property Value Notes
Usage Include/OcclusionOnly/Exclude Same as in LANPR modifier
Force False/True Force objects with LANPR modifiers to follow the rule

Material side

Add material

Week 3 Report

Week 3 Report

Things from the last week

  1. Fixed engine_free() callback, now no memory leaks on LANPR side.
  2. Fixed LANPR shader free problems.
  3. Software mode now support camera lens shift. Should be usable with any camera configurations now. (Only fisheye not implemented)
  4. Implemented Image-space chain connection to reduce jaggy lines.
  5. After some back and forth, finally settled down on a more solid design for Bridging LANPR with Blender and how to use GPencil modifiers. More information to come.
  6. Minor bug fixes.

Still to come

  1. Intersection lines needs near-far clipping before perspective division and coordinate shift. Need to prove this isn't needed.
  2. Perspective correction for occlusion points on the chains or use world-space split points.
  3. Still have some VBO utility structures not cleared correctly when LANPR exits.
  4. Move stroke generation modifier into Object modifiers as part of the design.
  5. Implement the new LANPR to GP path, including selections and generation.
  6. Image-space chaining reported to have some bugs in it. Look into it during the weekend.

I typically do more things in the weekends because I'm still enrolling in school. So expect updates before Monday. Happy weekend every one! :)


A more detailed modifier proposal for GPencil and LANPR

A more detailed modifier proposal for GPencil and LANPR

What is this all about?

Grease Pencil has received a lot of great improvements since Blender2.8. LANPR used to render all the strokes by its own. Now GPencil already have some style and texture options that we are able to use, so It is also reasonable for LANPR to utilize this part of the functions. At the current stage, GPencil's modifiers and stroke material are of the most interests. Since Freestyle is well known for its ability to generate feature lines with artistic shapes and textures, and people loved it, so it is necessary for us to implement such kind of functions into LANPR.

Since we can already share data between LANPR and GPencil, we then need more stroke modifiers to help us achieve the target.This short proposal is dedicated to extending GPencil modifier development for better NPR rendering usages.

What are we lacking?

How do we get LANPR data into Grease Pencil eventually? Now it is done by manually calculate the feature lines, and then create GPencil modifiers. There's a need to automate the process, or at least to notify the user about LANPR data (Thanks for Antonioya for mentioning this). This process should be something like this:

  • Use stroke generation modifier to automatically set LANPR a default present. User can adjust those arguments later.
  • Use a operator similar to "Quick Smoke", the "Quick LANPR" should create the GPencil object and set up everything you needed.

To me the first solution may be better, since one can use the stroke generator with their existing GPencil objects, and later could utilize LANPR's line select functions to give different GPencil objects different strokes and effects. Both methods doesn't necessarily have to be executed in LANPR engine though, because GPencil is used to draw. Hence I also put it in this modifier proposal.

There are some requirements (which isn't of great importance if the only thing GPencil does is drawing) to meet specific needs for stylized rendering: Please give feedback on what you think is also necessary too.

  • Sketchy stroke effect, Which may include effects like:
    • random curves along the stroke
    • not accurately placed stroke tips
    • multiple strokes in similar directions
    • simplified stroke to represent a collection of similar strokes.
  • Graph with industrial characteristics, To be used in e.g. structural representations:
    • dot/dash/doubled line styles
    • adjustable line tips, e.g. caps, arrows or something else
    • regulated geometric patterns along the stroke e.g. sinus wave.

Current GPencil has some basic modifiers. But to make better use of them, which means to better adapt them to algorithm-generated strokes, few existing modifiers may need some re-works:

  • Simplify: When in adaptive mode doesn't preserve geometry features very well. It will lose turning points. See image for demonstration.
  • Noise: Only does "visually predictable" noise patterns, and it is only in 2D (appears to be only perpendicular to the stroke normal direction?). A noise back-end like something that we use in the animation curve editor would be much better in terms of randomness. See image for demonstration.
  • Thickness: Can adjust thickness factor, but not override the original, also not able to adjust influence from by the distance from two end points.

Combining those points can give us a general considerations for what functions that those modifiers should have:

  • Able to control the density and distribution of the points in a generated stroke.
  • Able to manipulate the geometric pattern of a stroke more freely.
  • Able to simplify single or multiple strokes at once, in a shape-preserve matter.
  • Able to sometimes deconstruct one stroke into multiple strokes to represent one shape.
  • Able to apply textures to strokes.
  • And most importantly, most factors that goes into operations above should be able to be randomized or regulated according to the desired outcome.

But also keep in mind, the modifier shouldn't be too general that setting up an effect could use too many of them, that is not how it works on the artists side. For example, a "Sketch modifier" is much more convenient than "Split, Multiply, Random, Offset". It is better to bare a mind that put user's not programmer's thought first, but I don't know how far can I go to be honest.

OK, but where are the proposed modifiers?

Propose to add such modifiers:

Stroke Generation modifier

  • Should automatically set up and call LANPR.
  • Should add options to be able to cache the frame result for GPencil.

Sampling modifier

  • To regulate/randomize the distance between adjacent points in a stroke, also control the density.
  • Able to place points using a length-based pattern to create e.g. dot and dash stuff.

Extend/Shrink modifier

  • Able to extend the end points, better with a curvature that can be controlled to follow the original stroke.
  • Able to shrink the stroke by/to a specific length.

Multiplication modifier

  • Able to duplicate segments around the original stroke, with optional randomness.
  • At the same time, it should also be able to split stroke into multiple separate strokes. Should add options to co-operate with Sampling modifier.

Simplify modifier [MODIFICATIONS]

  • Make it more shape-aware.
  • Should be able to merge multiple similar strokes into one.

Smooth modifier [MODIFICATIONS]

  • Add another algorithm to generate more controlled curve lines like Freestyle's Bezier modifier.

More stuff that is worth considering

There are some things that aren't specifically related to LANPR→GPencil modifier development. But they can also be relevant, opinions are welcomed.

One interesting comparison of LANPR now would be Pencil+. On technical side (and let's just ignore the cartoon highlight stuff it has), two things still needs improvements on LANPR's side. 1) Time-coherence of patterned/textured stroke. 2) perspective disortions. Will take some time to achieve, the algorithm itself isn't too hard. However, with GPencil, I can already see some different stylization approaches, such as time-based warping and even geometry re-generation from strokes.

There are another use that I've been mentioned to is rotoscoping. I don't quite grasp how this is going to work because we can already use stuff like cyptomatte for rendered passes. But could be something to look forward too. This will require further refines to LANPR chain algorithms, also the help from Smooth Contour modifier.


Week 2 Report

Week 2 Report

(Reported on Friday, still some weekend works to do, and I have two tests this week :( )

Solved problems from last week

  1. Fixed GPencil stroke vertex attribute error in chaining.
  2. Split stroke chains based on their occlusion levels.
  3. Fixed overlay method for GPencil strokes, now use Viewport Display→In Front.
  4. Fixed Triangle culling bug in LANPR geometry pre-processor.
  5. Fixed DPIX wrong object position error.

And something else

  1. GPencil modifier works:
    • A proposal on some new modifiers and some modifications to the existing ones, please check here.
    • Added a (experimental) sampling modifier and a end-point extending modifier, which proved it is possible to do such edits in the modifier.

Still unsolved problems

  1. engine_free() still not working for LANPR.
  2. When GPencil stroke generator is present, LANPR should automatically disable the line drawing output from itself and let GPencil handle the rest.

Weekends and the next week

  1. I'm pretty sure that I can grab my hand on the interface.
  2. Implement all proposed modifier, and integrate the suggestions from users and artists.
  3. According to the original plan, the near-far plane triangle intersection calculation should work flawlessly by the end of the week. Fixed
  4. If still have time, fix the camera lens "shift" support for software mode.
  5. Remove "snake mode" from being accessed?
  6. DPIX is broken under new DRW_view APIs.


After discussing with my mentors, I found out that It is better for me to fix most of the bugs, and make sure all the internal features working properly, then it makes more sense to implement the interface features. Which means this will be the priority for the next week.


Week 1 Report

Week 1 Report

GPencil Comp

Things have done

In this week, there are mainly following things to address:

  1. Naming for most parts of the code are now in Blender's style.
  2. Included a GPencil stroke generator. Capable of generating 2D chains from smooth contour modifier result (Sebastian's work) and from 3D chains computed by LANPR code(My part). Included an option for toggling drawing GPencil on overlay or with depth.
  3. GPencil stroke generator now support animation rendering from LANPR data, which execute stroke calculation directly in render, no need to use custom script.
  4. Cleaned up the memory allocation in LANPR's software mode. Now everything uses memory pool in software mode. The data is cached after calculation and freed at the beginning of the next frame or when the engine destroys.
  5. Other code cleanups.

The following week

  1. engine_free() from LANPR engine is not called when blender quits. Resulting in memory leaks. Maybe missing some registration parameters.
  2. Ctrl-Z will cause the render buffer to reset. Maybe should move the whole render buffer into g_data ?
  3. 3D chaining vertex attribute has a offest of 1, cause determined, suspect incorrect or duplicated vertex when generating GPencil stroke.
  4. New UI for composition, should support material/object/collection selector and the newly integrated GPencil functionality.
  5. LANPR engine should be able to toggle GPencil or internal render mode depending on the modifier and active engine selection.


LANPR User Interface Thoughts.

LANPR User Interface Thoughts.

Current State

In UI aspect, currently LANPR has some major draw backs:

  • Render is too complicated to set up, even for a very simple scene.
  • Lack of proper arrangement for so many options.
  • No presents.
  • Poorly integrated with Blender's internal UI structure. Need to switch back and forth to get parameters right.
  • Only have a very primitive composition support.
  • ...


Detailed Discussion



LANPR should come with composition by default. Here propose a viable way: When user enables LANPR line render in a EEVEE or Cycles scene, the scene is automatically link-duplicated into another scene in the background. User don't adjust the values in this scene directly, this linked scene is only for line rendering and composition. to the user, this process should be hidden or not of much interest, and they don't have to switch between engines to adjust values.

Line Set/Selection logic

The line style configuration has been confusing since Freestyle's time. LANPR uses similar principle for the same task, so the same problems inherited, such as QI range, inclusive/exclusive logic, select within collection... We do need these functions to achieve many desired effects, so we won't be removing them. However, to make stuff easier to use, understand and customize, the UI needs to be revisited in a different way.


Now the proposal:

For simple and straight forward situations, provide a default present. UI should include very few most frequently used properties, and hide everything else. For example, only color and line thickness is shown. Just like the Freestyle checkbox under render tab. (Consider re-use this)

When things get a little advanced, e.g. the user wants to adjust individual styles for different line types, then the interface should only show the entries which are being adjusted, untouched entries should be in sync with the master style. Current design is too stupid that sometimes you even need to set the color five times to get a consistent look.

As for object/material/collection based line selection, Here propose a way to simplify this process.

In Freestyle, Line selection is achieved under "Line Sets" panel, and there's a lot of things going on there. The interface is distracting and hard to understand (This is partly because Blender 2.7x has a layer/group system, in 2.8x it is replaced with unified collection). LANPR will remove this line selector section, instead it will be put under object/material/collection panels. Users will be able to adjust specific line set just like they are dealing with materials of an object, and the "inclusive/exclusive" selection logic will also become easier to understand within such context.

Feature Line Specific Properties

Crease angle, camera clipping, distance influence, fake lighting direction and many other stuff like these can be treated as global properties within LANPR's feature line extraction algorithm. However, taking one step further would be awesome.



For example, instead being set for every scene, crease angle can be treated as an material-specific value. Artists can specify different crease angle to different parts of an object to further convey smooth or complex rigid surfaces without making multiple line sets. Enabling different distance influence to selected objects in a scene can make them pop or fade out too.

The fake lighting thing can also be integrated with lamp materials, but this needs some more considerations.


Proposed design already separated the major parts of LANPR into other parts of the interface which makes the configuration more logically relatable, which is good. We still have some things that may be included in LANPR's own panel that has not been added yet. One of the most important part is the bridge to GPencil.

A great news recently is the support of GPencil Texture, which when combined with LANPR stroke output, and the smooth contour modifier by DarkDefender has the potential of replacing Freestyle's stroke style system. GPencil already got its effect system and a bunch of modifiers. So this can be considered of greater potential than Freestyle's own stuff.

How LANPR handles GPencil conversion is not clear yet. But the principle would be to use some sort of rule to tell LANPR when and how to convert the strokes into GPencil object for next step rendering, because we need to make use of GPencil's modifier, effects and texture (almost everything in it), so there has to be some sort of a pre-defined automation going on which handles GPencil conversion and rendering, especially with animation usages. This need some more research.

Guess that's it for today. Stay tuned for more updates.

Feedback through whatever way you would like to use :D.

Yiming Wu

Prev   2/2