In T58669#594388, @Henry Schreiner (henryschreiner) wrote:

Nevermind, if I load factory defaults, the current default works fine with freestyle. Something is wrong with how the collections interact with freeing FreeStyle in the old file. (There might be a bug hidden in here, but it could just be a bug in the old defaults file). Thanks for fixing this by the way, it's great!

I think I already used the texture in that file but I'm not sure. If I did, sorry :( Then the lineset drawing order is already broken. It should be tested with a completely new file, maybe.

1. So first you'd toggle the Freestyle on (in the Render Settings)
2. Then you'd create 2 linesets. First one could be named "Red" for example, and set to "Visible" lines. Second lineset, "Green" could be set to "Hidden" like I've done, so the linesets draw different lines, but they can of course also both be drawing "Visible" lines. Then you'll only see the topmost color (Red) though, because Green gets drawn first and then Red over it.
3. Now rerender the image but switch the listing so that Green is above and Red is below. Green should appear on top in the render.
4. Now place a texture to either of the linesets and rerender. Its lines will appear below the other lineset lines.

Thanks for explanation.

It's this setting here:

@Jeroen Bakker (jbakker) Displacement modifier is not involved in T46716 so it's a different issue.

Freestyle Line renderer is an unmaintained area in Blender. The current file renders correctly, but by shifting the camera it can still appear. Seems like a limitation of the implementation.

Freestyle Line renderer is an unmaintained area in Blender. As we won't be solving this in the near future the tracker rules state that we need to register this as a known issue.

Thanks for additional information.

Freestyle Line renderer is an unmaintained area in Blender. As we won't be solving this in the near future the tracker rules state that we need to register this as a known issue. I have re-render this issue and it seems to be solved.

Freestyle Line renderer is an unmaintained area in Blender. As we won't be solving this in the near future the tracker rules state that we need to register this as a known issue

Issue seems like a functional limitation of the implementation. But it works as intended. Freestyle Line renderer is an unmaintained area in Blender. @Doxin (Doxin) issue has improved, so closing the report for now. As freestyle merges edges dashes it cannot be used to create the intended style rely-able. Best to use post processing (screen space dashing) or non dashed/thin/less contrasted lines in the original example

Original file cannot be accessed anymore. Next time, please upload it to the tracker so we can make sure that the file is accessible always.
I will close this issue as freestyle is working as expected. New developments isn't a bug. As freestyle isn't actively developed and it isn't clear what needs to be done I will register this issue as TODO/invalid.

I am not able to reproduce this issue with the latest blender build. @deusexvagina if you have a case that is still not working, please open up another report with an as small as possible blend file that we can use to reproduce the issue.

As this ticket is about a possible memory leak I tried to reproduce the leak, but was not able to do so. This scene is too complex. Memory leaks should also be detected with smaller scenes. So will mark this issue as Invalid. Please upload an as small as possible blend file that shows the issue at hand.

Freestyle Line renderer is an unmaintained area in Blender. As we won't be solving this in the near future the tracker rules state that we need to register this as a known issue.

I tested it here in blender 2.83.
Blender does not hang but it takes a long time to cancel.
It also takes a long time to compute.
So apparently freestyle only cancels when it finishes computing.

@Sybren A. Stüvel (sybren)
The line thickness has been a property that can be animated since 2.7x, so I would say the reported issue in 2.8x should be fixed.

In T72213#850668, @Sybren A. Stüvel (sybren) wrote:

@ivan (ivan2312345) Please write down the steps to reproduce this issue. Reading a short list of steps makes it much easier for a developer to understand than downloading multiple videos and watching them. Furthermore, writing it down makes it possible for a search engine to pick up on keywords in your description, and thus allow others to find the issue based on those steps.

The patch below fixes at least the UI updates in Blender, when scrubbing the timeline. However, when animating the line thickness and rendering, FreeStyle still uses a constant thickness. @Tamito Kajiyama (kjym3) is still supported? Should this be fixed, or is it a known limitation, and should we just not allow animating those values?

I can reproduce the issue without any modifiers (so no fcurve modifier and no freestyle modifier), simply by keying the line style base thickness.

This is just a stupid typo in rB2e6159a4, fix incoming.

@ivan (ivan2312345) Please write down the steps to reproduce this issue. Reading a short list of steps makes it much easier for a developer to understand than downloading multiple videos and watching them. Furthermore, writing it down makes it possible for a search engine to pick up on keywords in your description, and thus allow others to find the issue based on those steps.

Multi-report (different issues in a single report) are not accepted as valid reports.
To properly track issues we need them to be reported separately.
So closing.

I tested the attached file in 2.83 and the result still does not seem right:

I can confirm the crash. It occurs in the function do_version_curvemapping_walker that was introduced in rB2e6159a4
@Jeroen Bakker (jbakker), is this one for you?

Hi, thanks for your patch.

Ah yes, that method was moved will check tomorrow.

I can confirm the error:

AttributeError: 'CurveMap' object has no attribute 'evaluate'