Freestyle Line Edge Inconsistencies in Blender 2.79 #54532

Closed
opened 5 years ago by poweruserm · 13 comments

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

issues01.png

issues02.png

issues03.png

issues04.png

issues05.png

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?**

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?**
kjym3 was assigned by poweruserm 5 years ago
Poster

Added subscriber: @poweruserm

Added subscriber: @poweruserm
Collaborator

Added subscriber: @lichtwerk

Added subscriber: @lichtwerk
Collaborator

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

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

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

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?
kjym3 commented 5 years ago
Collaborator

Closed as duplicate of #49017

Closed as duplicate of #49017
kjym3 closed this issue 5 years ago
kjym3 commented 5 years ago
Collaborator

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

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
frame_124.png
frame_171.png

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

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?
Poster

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

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?

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?
kjym3 commented 5 years ago
Collaborator

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

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?
Poster

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. ?
Poster

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
Interest/Alembic
Interest/Animation & Rigging
Interest/Asset Browser
Interest/Asset Browser Project Overview
Interest/Audio
Interest/Automated Testing
Interest/Blender Asset Bundle
Interest/Collada
Interest/Compositing
Interest/Core
Interest/Cycles
Interest/Dependency Graph
Interest/Development Management
Interest/Eevee & Viewport
Interest/Freestyle
Interest/Geometry Nodes
Interest/Grease Pencil
Interest/ID Management
Interest/Images & Movies
Interest/Import/Export
Interest/Line Art
Interest/Masking
Interest/Modeling
Interest/Modifiers
Interest/Motion Tracking
Interest/Nodes & Physics
Interest/Overrides
Interest/Performance
Interest/Performance
Interest/Physics
Interest/Pipeline, Assets & I/O
Interest/Platforms, Builds, Tests & Devices
Interest/Python API
Interest/Render & Cycles
Interest/Render Pipeline
Interest/Sculpt, Paint & Texture
Interest/Text Editor
Interest/Translations
Interest/Triaging
Interest/Undo
Interest/USD
Interest/User Interface
Interest/UV Editing
Interest/VFX & Video
Interest/Video Sequencer
Interest/Virtual Reality
legacy module/Animation & Rigging
legacy module/Core
legacy module/Development Management
legacy module/Eevee & Viewport
legacy module/Grease Pencil
legacy module/Modeling
legacy module/Nodes & Physics
legacy module/Pipeline, Assets & IO
legacy module/Platforms, Builds, Tests & Devices
legacy module/Python API
legacy module/Rendering & Cycles
legacy module/Sculpt, Paint & Texture
legacy module/Triaging
legacy module/User Interface
legacy module/VFX & Video
legacy project/1.0.0-beta.2
legacy project/Asset Browser (Archived)
legacy project/BF Blender: 2.8
legacy project/BF Blender: After Release
legacy project/BF Blender: Next
legacy project/BF Blender: Regressions
legacy project/BF Blender: Unconfirmed
legacy project/Blender 2.70
legacy project/Code Quest
legacy project/Datablocks and Libraries
legacy project/Eevee
legacy project/Game Animation
legacy project/Game Audio
legacy project/Game Data Conversion
legacy project/Game Engine
legacy project/Game Logic
legacy project/Game Physics
legacy project/Game Python
legacy project/Game Rendering
legacy project/Game UI
legacy project/GPU / Viewport
legacy project/GSoC
legacy project/Infrastructure: Websites
legacy project/LibOverrides - Usability and UX
legacy project/Milestone 1: Basic, Local Asset Browser
legacy project/Nodes
legacy project/OpenGL Error
legacy project/Papercut
legacy project/Pose Library Basics
legacy project/Retrospective
legacy project/Tracker Curfew
legacy project/Wintab High Frequency
Meta/Good First Issue
Meta/Papercut
migration/requires-manual-verification
Module › Animation & Rigging
Module › Core
Module › Development Management
Module › Eevee & Viewport
Module › Grease Pencil
Module › Modeling
Module › Nodes & Physics
Module › Pipeline, Assets & IO
Module › Platforms, Builds, Tests & Devices
Module › Python API
Module › Render & Cycles
Module › Sculpt, Paint & Texture
Module › Triaging
Module › User Interface
Module › VFX & Video
Platform/FreeBSD
Platform/Linux
Platform/macOS
Platform/Windows
Priority › High
Priority › Low
Priority › Normal
Priority › Unbreak Now!
Status › Archived
Status › Confirmed
Status › Duplicate
Status › Needs Information from Developers
Status › Needs Information from User
Status › Needs Triage
Status › Resolved
Type › Bug
Type › Design
Type › Known Issue
Type › Patch
Type › Report
Type › To Do
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#54532
Loading…
There is no content yet.