Many thanks to Brecht for the revision! It works just fine as far as I tested.

Hi Dalai,

Just for record, I quote from D3084 the reason of reverting:

It turned out that I was testing the patch based on an old copy of the blender2.8 branch. After a merge-and-push, a Freestyle-enabled Eevee F12 render leads to a crash. I should have tested the merged code before pushing it to the repository. I have just revered the commit for now. The crash comes from a to-do item described as Note 2 of the commit rBc14925bddf9b, and related work seems ongoing on the temp-render-depsgraph branch. I will wait for the things settled and then bring the patch back to the repository.

It turned out that I was testing the patch based on an old copy of the blender2.8 branch. After a merge-and-push, a Freestyle-enabled Eevee F12 render leads to a crash. I should have tested the merged code before pushing it to the repository. I have just revered the commit for now. The crash comes from a to-do item described as Note 2 of the commit rBc14925bddf9b, and related work seems ongoing on the temp-render-depsgraph branch. I will wait for the things settled and then bring the patch back to the repository.

Since this is the first time I touched the Eevee related area of code, I would add three of you as a tentative group of reviewers. Please, introduce a better reviewer if any.

Thanks Brecht and Dalai for the prompt reviews. I was not aware the "Use Freestyle" option was missing also in master. My bad, sorry Dalai for the confusion.

Thank you all for the prompt reviews, and thanks @Brecht Van Lommel (brecht) for spotting the cause of the crash. I confirmed that fixing the suggested line of code resolved the crash. But still the copying of Cycles options from one scene to another does not work. Even after the RNA_STRUCT_BEGIN(&freestyle_cycles_ptr, prop) ... RNA_STRUCT_END block as in the removed code block, the Cycles parameter values remain the default ones (e.g., cycles.samples is 128 no matter how it is set in the user-defined scene). Any suggestions of where to check out?

Animated edge marks could be a partial solution (a workflow in this approach could be tedious and even not applicable in some cases though) -- see https://wiki.blender.org/index.php/User:Kjym3/DevFundProject/InterimReport for more information.

Just a report of a compilation error with VS 2015. A comment is inlined.

I confirmed this is a regression from the 2.76 release. I will look into the issue.

Thanks Bastien for the triage, and I confirmed the issue on my side. I will look into it as soon as time permits.

If I remember correctly, I didn't even consider the possibility of imposing the constraint that there must be at least one lineset. It is easy to check if there's a lineset, and I was not aware of negative effects due to an empty set of linesets.

Thanks @Sergey Sharybin (sergey) for the triage. I will look into the reported issue.

Thanks a lot @Bastien Montagne (mont29), I will look into the reported issue when time permits.

Thanks @Sergey Sharybin (sergey), I will look into the reported issue.

Scaling down the mesh objects by a factor of 10 and zooming the camera into the scaled objects to compensate the smaller sizes would give a correct line rendering result. This means that there is an issue related to numerical precision (i.e., float and double in C/C++). I will further test the code and make an attempt to fix the problem.

Just to confirm what @Ignatz (ignatz) said, adding a Triangulate mesh modifier gives Freestyle lines consistent with the Solid render component. Without the extra mesh modifier, Freestyle seems to compute lines based on geometry data that is different from what Cycles and the Blender Internal actually see.

The patch compiles fine and the binary runs without hassle. By choosing a font containing CJK glyphs (e.g., meiryo.ttc) curve text objects in the edit mode accept key operations from the Japanese MS-IME on Windows 7.

Freestyle requires filled faces to render lines along selected edges of the faces.

@Sergey Sharybin (sergey) Yes I am and thanks for the triage. Will look into the reported issue as soon as time permits.

Hi Doxin,
Many thanks for the problem report. I can confirm the problem is reproducible on my end. Blender 2.75a gives much better results out of the same crate5.blend file, so the issue is considered a regression. I will take a closer look into the documented bug asap.

You have chosen the Inside thickness position option in your 'test' line style. The first two cases as to objects 'Cube' and 'Cube.001' suffer from a technical limitation of the Inside thickness option.

@Bastien Montagne (mont29) Indeed the reported assertion failures are not related to the crash. I am still not sure why these assertion failures occur because they are from a checking of a condition addressed by an old issue T39669. It seems that some degenerate faces are involved (and Freestyle are not good at treating them).

Confirmed the crash on both Windows and Linux using the latest master d8233d230885 as of this writing. The reported problem seems a regression because:

• Cycles in the latest master leads to a crash;
• Cycles in Blender 2.75a does not crash; and
• the Blender Internal of the latest master does not crash either.

The input scene (i.e., an auto-generated scene populated with meshes representing Freestyle strokes) is the same for all the three cases, and the only difference is the use of Cycles. I guess there is a recent change that causes a crash within Cycles.

Thank you Campbell for the proposed fix.

Independent quick tests on Ubuntu 14.04 LTS using Fcitx-Mozc showed that the over-the-spot input style works nicely as seen in the following screen captures of the Text Editor and the scene name entry. Functionality-wise the present patch looks quite operational.

Usually Freestyle strokes are open and not closed (do not loop). If strokes are open, filling them is likely to cause visual artifacts. As of this writing, it is a responsibility on the user side to make sure that the strokes to be filled are closed.

The fix is very much appreciated, thanks Brecht.

Many thanks for the fix Brecht!

Thank you @Sergey Sharybin (sergey) for the proposed fix.

One more inline comment.

Thanks for the patch updates. A few inline notes are found below.

Thanks for the patch submission. Here are my notes on some of the posed questions.

Hi flokkievids,

I believe we can assume that a Material object always exists and never gets freed while a wrapper FrsMaterial for it exists. As we discussed FrsMaterial objects will be created on the fly when underlying Material objects needs to be exposed to style modules in Python during the Freestyle line rendering process. During Freestyle rendering, Material objects won't be freed. By the same token, we don't really need a default material for FrsMaterial.

In D1416#29653, @Folkert de Vries (flokkievids) wrote:

So, I think that it is best to rewrite FrsMaterial as a read-only interface to Material, while removing all unneeded fields/attributes. This allows us to implement custom methods to this type to make the integration with the rest of the Freestyle codebase easier.

Do you think it is easier to remove FrsMaterial completely and instead use Material?