Freestyle Line Edge Inconsistencies in Blender 2.79 #54532

New Issue

Zachary1234 · 2018-04-06T08:27:19+02:00

Zachary1234 commented

2018-04-06 08:27:19 +02:00

I have been working on an animation that involves some motion
of a number of mesh mode planes that have freestyle line edges on them.

There is a Freestyle Line Edge render detection issue, that I am aware of.
I am using the Blender Renderer in 64 bit Blender 2.79 stable.

I have to use Visibility, QI Detection 0,0 in order to attain
the effect that I need. I cannot use any other related
setting from the user interface at the same time here.

My video absolutely must move through a relative acute angle
between the camera and the Marked Freestyle Line edges
of relevence.

Consider one frame render at frame 480 for one example of the sort
of thing I just need a way to disable:

Animation.blend

**Aside from just "avoiding those acute angles",
or using an "always detect" mode for them, is there a way
to have those Freestyle Line Edges detected again?

Is this discrepency in Blender actually being fixed?
What is the rate of progress?

Is there a script or a Blender plugin that people can use in the mean time that
you can reply to me with, please?**

I have been working on an animation that involves some motion of a number of mesh mode planes that have freestyle line edges on them. There is a Freestyle Line Edge render detection issue, that I am aware of. I am using the Blender Renderer in 64 bit Blender 2.79 stable. I have to use Visibility, QI Detection 0,0 in order to attain the effect that I need. I cannot use any other related setting from the user interface at the same time here. My video absolutely must move through a relative acute angle between the camera and the Marked Freestyle Line edges of relevence. Consider one frame render at frame 480 for one example of the sort of thing I just need a way to disable: [Animation.blend](https://archive.blender.org/developer/F2611348/Animation.blend) ![issues01.png](https://archive.blender.org/developer/F2612568/issues01.png) ![issues02.png](https://archive.blender.org/developer/F2612570/issues02.png) ![issues03.png](https://archive.blender.org/developer/F2612573/issues03.png) ![issues04.png](https://archive.blender.org/developer/F2612575/issues04.png) ![issues05.png](https://archive.blender.org/developer/F2612577/issues05.png) ![issues06.png](https://archive.blender.org/developer/F2612579/issues06.png) **Aside from just "avoiding those acute angles", or using an "always detect" mode for them, is there a way to have those Freestyle Line Edges detected again? Is this discrepency in Blender actually being fixed? What is the rate of progress? Is there a script or a Blender plugin that people can use in the mean time that you can reply to me with, please?**

Tamito Kajiyama was assigned by Zachary1234

2018-04-06 08:27:19 +02:00

Zachary1234 commented

2018-04-06 08:27:19 +02:00

Added subscriber: @poweruserm

Philipp Oeser commented

2018-04-06 10:31:29 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2018-04-06 10:31:29 +02:00

Hi,

thx for your example file, but I have trouble grasping what your actual artistic intentions are here.
Could you be more specific in some areas:

what are "always detect" / "always detect by default" modes?
what is your source of the socalled "boolean variable solution" (could it be Freestyle Edge Marks? These can be inclusive/exclusive and can be combined as EdgeTypes with Visibility)
which edges are 'missing' on which frame? which edges should be hidden on which frame? Please provide renderings/screenshots with annotations exactly pointing at edges in question

Marking as incomplete for now...

Hi, thx for your example file, but I have trouble grasping what your actual artistic intentions are here. Could you be more specific in some areas: - what are "always detect" / "always detect by default" modes? - what is your source of the socalled "boolean variable solution" (could it be Freestyle Edge Marks? These can be inclusive/exclusive and can be combined as EdgeTypes with Visibility) - which edges are 'missing' on which frame? which edges should be hidden on which frame? Please provide renderings/screenshots with annotations exactly pointing at edges in question Marking as incomplete for now...

Zachary1234 commented

2018-04-06 12:11:30 +02:00

I have read this, and have updated the original post. How are things now?

Zachary1234 commented

2018-04-07 04:13:57 +02:00

I am serious about learning about either a temporary solution, learning what the present state of development is,
or setting in motion some progress on this FreeStyle Edge detection problem.

Is there a near solution in sight, can someone at Blender please implement a solution, is there a script
or add-on that people can use in the meantime?

I am serious about learning about either a temporary solution, learning what the present state of development is, or setting in motion some progress on this FreeStyle Edge detection problem. Is there a near solution in sight, can someone at Blender please implement a solution, is there a script or add-on that people can use in the meantime?

Tamito Kajiyama commented

2018-04-07 16:17:28 +02:00

Closed as duplicate of #49017

Tamito Kajiyama closed this issue

2018-04-07 16:17:28 +02:00

Tamito Kajiyama commented

2018-04-07 17:07:21 +02:00

As I mentioned in #49017, the only practical solution to the line rendering in your scene setup is the use of keyframes on FS edge marks.

FS edge marks can be animated, so that you can turn on/off selected edge marks at any specific frame.

An expected burden here is that the keyframes on FS edge marks are not easy to insert/delete interactively. The only way I am aware of is to use the Outliner in the Data-blocks mode: you find a toggle button representing an FS edge mark flag (as seen in the screen capture below) and insert/delete a keyframe using the usual right-click menu on the toggle button.

Obviously this method is too tedious to apply in practice, because finding the FS edge mark toggle button of a specific mesh edge is very time-consuming.

I would suggest relying on a simple script to insert keyframes on all FS edge marks of selected mesh objects.

# add keyframes on FS edge marks of selected mesh objects

import bpy

for ob in bpy.context.selected_objects:
    if ob.type == 'MESH':
        me = ob.data
        for e in me.edges:
            e.keyframe_insert(data_path='use_freestyle_mark')

Every time you run this script (by pressing the Run Script button in the Text Editor window in Blender), keyframes are added on FS edge marks of selected mesh objects at the current frame. A suggested workflow is as follows:

First of all, go to frame 1, mark only those FS edge marks for the FS lines relevant only at frame 1, select all mesh objects and run the script in the Object mode. This will ensure that all FS edge marks, either turned on or off, are properly keyframed at the beginning of animation.
Second, go to a frame at which you want to add/hide FS lines, add/clear FS edge marks in the Edit mode, select the mesh objects of updated FS edge marks, and run the script in the Object mode. This will ensure the updated FS edge marks are keyframed at the selected frame.

Repeat the second step as many times as you want until FS edge marks are fully keyframed over the entire animation frames.

Line rendering can be configured simply based on line visibility and edge types (using edge marks, obviously).

Here are renders of a few selected frames from your scene but after several FS edge marks are keyframed.

For your evaluation, here's the modified .blend file used to generate the renders above.

Animation_TK.blend

Hope this helps.

As I mentioned in #49017, the only practical solution to the line rendering in your scene setup is the use of keyframes on FS edge marks. FS edge marks can be animated, so that you can turn on/off selected edge marks at any specific frame. An expected burden here is that the keyframes on FS edge marks are not easy to insert/delete interactively. The only way I am aware of is to use the Outliner in the Data-blocks mode: you find a toggle button representing an FS edge mark flag (as seen in the screen capture below) and insert/delete a keyframe using the usual right-click menu on the toggle button. ![FS_edge_marks_in_outliner.png](https://archive.blender.org/developer/F2621818/FS_edge_marks_in_outliner.png) Obviously this method is too tedious to apply in practice, because finding the FS edge mark toggle button of a specific mesh edge is very time-consuming. I would suggest relying on a simple script to insert keyframes on all FS edge marks of selected mesh objects. ``` # add keyframes on FS edge marks of selected mesh objects import bpy for ob in bpy.context.selected_objects: if ob.type == 'MESH': me = ob.data for e in me.edges: e.keyframe_insert(data_path='use_freestyle_mark') ``` Every time you run this script (by pressing the Run Script button in the Text Editor window in Blender), keyframes are added on FS edge marks of selected mesh objects at the current frame. A suggested workflow is as follows: - First of all, go to frame 1, mark only those FS edge marks for the FS lines relevant only at frame 1, select all mesh objects and run the script in the Object mode. This will ensure that all FS edge marks, either turned on or off, are properly keyframed at the beginning of animation. - Second, go to a frame at which you want to add/hide FS lines, add/clear FS edge marks in the Edit mode, select the mesh objects of updated FS edge marks, and run the script in the Object mode. This will ensure the updated FS edge marks are keyframed at the selected frame. # Repeat the second step as many times as you want until FS edge marks are fully keyframed over the entire animation frames. Line rendering can be configured simply based on line visibility and edge types (using edge marks, obviously). Here are renders of a few selected frames from your scene but after several FS edge marks are keyframed. ![frame_001.png](https://archive.blender.org/developer/F2621827/frame_001.png) ![frame_124.png](https://archive.blender.org/developer/F2621832/frame_124.png) ![frame_171.png](https://archive.blender.org/developer/F2621834/frame_171.png) For your evaluation, here's the modified .blend file used to generate the renders above. [Animation_TK.blend](https://archive.blender.org/developer/F2621852/Animation_TK.blend) Hope this helps.

Zachary1234 commented

2018-04-08 04:31:54 +02:00

Thank you, that is all very excellent.

How is the root of the matter going to be repaired?
Is there or will there be an effort
to enhance the Blender Freestyle Line detection
so that a brute force method like this won't be needed,
but that things will simply be detected "on their own",
appropriately, the first time?

Thank you, that is all very excellent. How is the root of the matter going to be repaired? Is there or will there be an effort to enhance the Blender Freestyle Line detection so that a brute force method like this won't be needed, but that things will simply be detected "on their own", appropriately, the first time?

Zachary1234 commented

2018-04-08 04:38:37 +02:00

The other thing, is that there are still inconsistencies in your "patched" aproach:

This means that the Freestyle Line edge detection is still not behaving properly.

Is there a patch that doesn't require so many key frames for things?

Will this whole business be fixed in Blender, on it's own?

What is the progress in this area?

The other thing, is that there are still inconsistencies in your "patched" aproach: ![Problem01.png](https://archive.blender.org/developer/F2626921/Problem01.png) This means that the Freestyle Line edge detection is *still* not behaving properly. Is there a patch that doesn't require so many key frames for things? Will this whole business be fixed in Blender, on it's own? What is the progress in this area?

Tamito Kajiyama commented

2018-04-08 16:22:04 +02:00

I don't really expect any further progress that would lead to a fix of the issue due to coincident planes.

The reported problem actually comes from the fact that your scene setup has many coincident planes (i.e., one lies exactly on top of the other). When you have a pair of coincident planes, you cannot tell which one is on top of the other from a mathematical point of view --- they are on the identical plane.

That is not a Freestyle-specific problem. In geometry-based rendering engines like the Blender Internal and Cycles, coincident planes result in a visual artifact due to z-fighting. The coincident planes have the same depth from the camera, so that the visibility of the planes are mathematically undefined --- you cannot tell which one hides the other. If you google a solution for z-fighting, then you'll end up in finding a suggestion that you manually add a small displacement to one of the planes so that they are no longer coincident.

Exactly the same reasoning applies to the line visibility issue you spotted in Freestyle. When a mesh edge is coincident with a plane (i.e., the edge lies exactly on the plane), you cannot tell mathematically whether the line is hidden by the plane or not. This is an inherent limitation of geometry-based rendering and not specific to Freestyle.

Consider adding a displacement to selected planes so as to avoid plane coincidence. If that is not applicable, then it is likely that the only practical solution is the manual brute-force approach based on animated FS edge marks.

I don't really expect any further progress that would lead to a fix of the issue due to coincident planes. The reported problem actually comes from the fact that your scene setup has many coincident planes (i.e., one lies exactly on top of the other). When you have a pair of coincident planes, you cannot tell which one is on top of the other from a mathematical point of view --- they are on the identical plane. That is not a Freestyle-specific problem. In geometry-based rendering engines like the Blender Internal and Cycles, coincident planes result in a visual artifact due to z-fighting. The coincident planes have the same depth from the camera, so that the visibility of the planes are mathematically undefined --- you cannot tell which one hides the other. If you google a solution for z-fighting, then you'll end up in finding a suggestion that you manually add a small displacement to one of the planes so that they are no longer coincident. Exactly the same reasoning applies to the line visibility issue you spotted in Freestyle. When a mesh edge is coincident with a plane (i.e., the edge lies exactly on the plane), you cannot tell mathematically whether the line is hidden by the plane or not. This is an inherent limitation of geometry-based rendering and not specific to Freestyle. Consider adding a displacement to selected planes so as to avoid plane coincidence. If that is not applicable, then it is likely that the only practical solution is the manual brute-force approach based on animated FS edge marks.

Zachary1234 commented

2018-04-09 03:27:53 +02:00

My stance in raising this as a bug report, or a formal issue with the Freestyle development group,
is overcoming this present state of response.

Freestyle line edges, particularly in terms of all options, are an incomplete implementation
if they cannot consistently render in situations like this.

Z-Fighting with surfaces is a simple issue that is overcome by appropriate surface engineering,
appropriate intersection, or even sharing exactly the same surface material variable.

In a different kind of situation, where intersecting surfaces are required, as part of a more
"virtualised" animation construction, correct dynamic line allocation is a must.
Since Blender also supports animation capabilities.

However this discrepency is seen, it is a discrepency, since there is no way,
either using groups or the 20 layers system, to perform stacking
of planes with Freestyle Line edges at one location, but to always
have the appropriate extent of the line included at render,
as well as having the line at all, irrespective of camera angle.

Is it possible to find anyone who will address this issue
by changing how these marked edges are included for
render in the Blender 3D software?

My stance in raising this as a bug report, or a formal issue with the Freestyle development group, is overcoming this present state of response. Freestyle line edges, particularly in terms of all options, are an incomplete implementation if they cannot consistently render in situations like this. Z-Fighting with surfaces is a simple issue that is overcome by appropriate surface engineering, appropriate intersection, or even sharing exactly the same surface material variable. In a different kind of situation, where intersecting surfaces are required, as part of a more "virtualised" animation construction, correct dynamic line allocation is a must. Since Blender also supports animation capabilities. However this discrepency is seen, it is a discrepency, since there is no way, either using groups or the 20 layers system, to perform stacking of planes with Freestyle Line edges at one location, but to always have the appropriate extent of the line included at render, as well as having the line at all, irrespective of camera angle. Is it possible to find anyone who will address this issue by changing how these marked edges are included for render in the Blender 3D software?

Zachary1234 commented

2018-04-10 07:17:14 +02:00

For the sake of my model, I need a way to have coincident planes, coincident plane edges and Freestyle Line marks on those.
In order to model sheets of zero thickness, and for a form of stacking to occur such that various planes and edges are visible,
as stacked from top down.

I can't use grouping or layers to help me, and it does not make sense that even in the same frame, some edges are included
in a similar situation to edges that are not.

I also am trying to find someone who can develop on this issue, either to change the defaulting for
marked Freestyle Line Edges, or to include some kind of an option to help.

?

For the sake of my model, I need a way to have coincident planes, coincident plane edges and Freestyle Line marks on those. In order to model sheets of zero thickness, and for a form of stacking to occur such that various planes and edges are visible, as stacked from top down. I can't use grouping or layers to help me, and it does not make sense that even in the same frame, some edges are included in a similar situation to edges that are not. I also am trying to find someone who can develop on this issue, either to change the defaulting for marked Freestyle Line Edges, or to include some kind of an option to help. ?

Zachary1234 commented

2018-04-16 04:08:06 +02:00

Can someone please reply to me here, subscribe to, or participate in my thread,
who can assist me better with my questions here?

Can someone please reply to me here, subscribe to, or participate in my thread, who can assist me better with my questions here?

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Freestyle Line Edge Inconsistencies in Blender 2.79 #54532

Repeat the second step as many times as you want until FS edge marks are fully keyframed over the entire animation frames.