Leave Spring
  1/1  
 于2019/06/19

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.
 于2019/06/17

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

 于2019/06/10

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! :)


YimingWu

 于2019/06/06

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.


YimingWu

 于2019/06/04

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.

Update

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.


YimingWu

 于2019/06/03

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.

Yiming

 于2019/05/10

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.
  • ...

drawback

Detailed Discussion

Composition

comp

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.

ui_level

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.

distributed

distributed

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.

GPencil

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

  1/1