Freestyle renders extra lines #36350

New Issue

Robert Boom · 2013-08-02T11:55:55+02:00

Robert Boom commented

2013-08-02 11:55:55 +02:00

%%%--- Operating System, Graphics card ---
1st PC: Win7 64bit & Quattro 2000
2nd PC: Win7 64bit & Nvidia 560ti

- Blender version with error, and version that worked ---

2.68a

- Short description of error ---

Freestyle produces lines through objects as they are transparent
I build a moving staircase and some lines of the glass roof appear "randomly" through the walls.

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

I just created objects + render. %%%

%%%--- Operating System, Graphics card --- 1st PC: Win7 64bit & Quattro 2000 2nd PC: Win7 64bit & Nvidia 560ti - Blender version with error, and version that worked --- 2.68a - Short description of error --- Freestyle produces lines through objects as they are transparent I build a moving staircase and some lines of the glass roof appear "randomly" through the walls. - Steps for others to reproduce the error (preferably based on attached .blend file) --- I just created objects + render. %%%

Robert Boom commented

2013-08-02 11:55:55 +02:00

Changed status to: 'Open'

blender-admin commented

2013-08-02 11:55:55 +02:00

#39134 was marked as duplicate of this issue

Atomic commented

2013-08-05 20:19:19 +02:00

%%%Sounds similar to my reported bug as well.
https://projects.blender.org/tracker/index.php?func=detail&aid=36366&group_id=9&atid=498%%%

%%%Sounds similar to my reported bug as well. https://projects.blender.org/tracker/index.php?func=detail&aid=36366&group_id=9&atid=498%%%

Tamito Kajiyama commented

2013-08-08 01:08:57 +02:00

%%%Thank you for reporting the problem. Apparently Freestyle has a bug in line visibility computation when edges are hid by large faces. I will look into the issue. For now, try to reduce the size of individual faces in the roof mesh Gare.000 (e.g., by selecting all faces and applying WKEY > Subdivide twice). By this way most extra lines would disappear.%%%

sadi gase commented

2014-03-12 17:47:01 +01:00

Changed status from 'Open' to: 'Duplicate'

sadi gase closed this issue

2014-03-12 17:47:01 +01:00

sadi gase commented

2014-03-12 17:47:01 +01:00

✘ Merged into #39134.

Bastien Montagne commented

2014-03-12 18:01:06 +01:00

Changed status from 'Duplicate' to: 'Open'

Bastien Montagne reopened this issue

2014-03-12 18:01:06 +01:00

Bastien Montagne commented

2014-03-12 18:01:06 +01:00

Added subscriber: @mont29

Shinsuke Irie commented

2014-03-12 20:25:49 +01:00

Added subscriber: @IRIEShinsuke

Tamito Kajiyama commented

2014-03-13 01:44:50 +01:00

Added subscriber: @ccinage

Tamito Kajiyama commented

2014-03-13 01:44:50 +01:00

◀ Merged tasks: #39134.

Tamito Kajiyama commented

2014-08-28 04:35:57 +02:00

The reported problem has not been resolved yet, but an intermediate report of bug hunting is presented below from a technical perspective.

The issue is only seen with a perspective camera. The cause of the problem was identified in a wrong assumption made in the design of a grid data structure used to accelerate line visibility computations.

It is recalled that line visibility computations involve many ray-casting tests to find intersections between a line segment (ray) and a triangle (occluder). A naive way is to do the tests for all triangles in the scene regardless of the line segment at hand. Instead, Freestyle employs a sophisticated way to make the tests faster by means of a grid data structure. First, the 3D camera space in front of the view point is divided into grid cells, and all triangles in the scene are assigned to the grid cells that intersect with it. Then for each ray-casting test, the grid cells that intersect with the line segment are identified, and only the triangles that belong to the grid cells are considered for line-triangle intersection detection.

In the case of a perspective camera, a specific grid data structure called spherical grid is used based on a spherical projection that maps a 3D camera-space point (x, y, z) into a point (u, v, w) in the spherical grid space as follows (implemented in SphericalGrid::Transform::sphericalProjection()):

u = atan(x / z)
v = atan(y / z)
w = sqrt(x * x + y * y + z * z);

Spherical grid cells are arranged in rows and columns. Each row and column correspond to a disjoint range of u and v values, respectively. Camera-space polygons are first mapped to the grid space, and then assigned to grid cells based on the u and v values of the projected vertex coordinates.

After many hours of bug hunting, the cause of the issue was finally identified in the wrong assumption that the spherical projection maps a camera-space triangle onto another triangle in the grid space. In fact the transformed shape is no longer a triangle. The assignment of grid-space polygons into grid cells were performed based on a triangle-rectangle intersection algorithm (implemented in GeomUtils::overlapTriangleBox()). Since the grid-space polygon is not a triangle, the algorithm fails in some cases, especially when a big triangle spans over many grid cells. The figure below visualizes this point:

In the figure, grid-space u and v coordinates are denoted as theta_x and theta_y, respectively. The black circles indicate grid-space vertices mapped from a camera-space triangle by the spherical projection. The red triangle is what the present spherical grid structure assumes as a projection result, whereas the blue shape shows the correct mapping result. The blue one intersects with the highlighted grid cell in the top-right corner of the figure, while the red triangle does not. Hence this triangle is not assigned to the grid cell, resulting in a failure of ray-casting tests and thus wrong line visibility.

As an attempt to address the documented bug, a new polygon-cell intersection algorithm was implemented. The idea was to find intersections between a camera-space triangle and a square pyramid that corresponds to a spherical grid cell. This approach was discontinued however, since it was learned that the spherical projection in question generates grid cells that cannot be represented by 3D geometry in the camera space.

It is now clear that a completely new grid data structure for perspective cameras is necessary to properly address the reported problem. That's all for now. More updates will follow.

The reported problem has not been resolved yet, but an intermediate report of bug hunting is presented below from a technical perspective. The issue is only seen with a perspective camera. The cause of the problem was identified in a wrong assumption made in the design of a grid data structure used to accelerate line visibility computations. It is recalled that line visibility computations involve many ray-casting tests to find intersections between a line segment (ray) and a triangle (occluder). A naive way is to do the tests for all triangles in the scene regardless of the line segment at hand. Instead, Freestyle employs a sophisticated way to make the tests faster by means of a grid data structure. First, the 3D camera space in front of the view point is divided into grid cells, and all triangles in the scene are assigned to the grid cells that intersect with it. Then for each ray-casting test, the grid cells that intersect with the line segment are identified, and only the triangles that belong to the grid cells are considered for line-triangle intersection detection. In the case of a perspective camera, a specific grid data structure called spherical grid is used based on a spherical projection that maps a 3D camera-space point (x, y, z) into a point (u, v, w) in the spherical grid space as follows (implemented in `SphericalGrid::Transform::sphericalProjection()`): ``` u = atan(x / z) v = atan(y / z) w = sqrt(x * x + y * y + z * z); ``` Spherical grid cells are arranged in rows and columns. Each row and column correspond to a disjoint range of u and v values, respectively. Camera-space polygons are first mapped to the grid space, and then assigned to grid cells based on the u and v values of the projected vertex coordinates. After many hours of bug hunting, the cause of the issue was finally identified in the wrong assumption that the spherical projection maps a camera-space triangle onto another triangle in the grid space. In fact the transformed shape is no longer a triangle. The assignment of grid-space polygons into grid cells were performed based on a triangle-rectangle intersection algorithm (implemented in `GeomUtils::overlapTriangleBox()`). Since the grid-space polygon is not a triangle, the algorithm fails in some cases, especially when a big triangle spans over many grid cells. The figure below visualizes this point: ![spherical_tri.png](https://archive.blender.org/developer/F107080/spherical_tri.png) In the figure, grid-space u and v coordinates are denoted as theta_x and theta_y, respectively. The black circles indicate grid-space vertices mapped from a camera-space triangle by the spherical projection. The red triangle is what the present spherical grid structure assumes as a projection result, whereas the blue shape shows the correct mapping result. The blue one intersects with the highlighted grid cell in the top-right corner of the figure, while the red triangle does not. Hence this triangle is not assigned to the grid cell, resulting in a failure of ray-casting tests and thus wrong line visibility. As an attempt to address the documented bug, a new polygon-cell intersection algorithm was implemented. The idea was to find intersections between a camera-space triangle and a square pyramid that corresponds to a spherical grid cell. This approach was discontinued however, since it was learned that the spherical projection in question generates grid cells that cannot be represented by 3D geometry in the camera space. It is now clear that a completely new grid data structure for perspective cameras is necessary to properly address the reported problem. That's all for now. More updates will follow.

Aaron Carlisle commented

2014-12-10 15:33:01 +01:00

Added subscriber: @Blendify

Julian Eisel commented

2015-01-02 14:54:32 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2015-01-02 14:54:32 +01:00

@kjym3, If I understand correctly this would require some bigger refactoring? Just asking because this shouldn't be handled as a bug report in this case, more like a limitation/todo.

Tamito Kajiyama commented

2015-01-02 15:08:26 +01:00

It's true that addressing the reported problem requires a major code revision. The cause of the bug has already been identified, but a bit more coding time is needed on my side to fix it properly. I would keep this report as a bug and not a to-do item, because it's a priority bug that I have seen many Freestyle users suffering from.

J.R.I.B. commented

2015-03-03 15:18:00 +01:00

Added subscriber: @faerietree

WK Bong commented

2015-04-25 08:26:52 +02:00

Added subscriber: @WeeKwongBong

agnes swart commented

2016-03-10 12:32:29 +01:00

Added subscriber: @agnesswart

Dmitry Sankov commented

2016-03-11 17:24:48 +01:00

Added subscriber: @subGlitch

Dmitry Sankov commented

2016-03-11 17:30:45 +01:00

Guys, any news regarding this issue?
For me it is actually a big problem, because sometimes it is very inconvenient to work with subdivided meshes.
Please please please fix it.

Guys, any news regarding this issue? For me it is actually a big problem, because sometimes it is very inconvenient to work with subdivided meshes. Please please please fix it.

asmwarrior commented

2016-04-28 02:14:05 +02:00

Added subscriber: @ollydbg

asmwarrior commented

2016-04-28 02:14:05 +02:00

Hi, what is the status of this bug, are there any development progresses on this bug? Subdivision the face or the line to solve this issue is not quite good method, and it takes a lot of time.
See my similar detailed bug report in Any feature in Blender which can show front edges and back edges differently like in Sketchup - Blender Stack Exchange.
Thanks.

Hi, what is the status of this bug, are there any development progresses on this bug? Subdivision the face or the line to solve this issue is not quite good method, and it takes a lot of time. See my similar detailed bug report in [Any feature in Blender which can show front edges and back edges differently like in Sketchup - Blender Stack Exchange](http://blender.stackexchange.com/questions/49183/any-feature-in-blender-which-can-show-front-edges-and-back-edges-differently-lik). Thanks.

Bjorn Andersson commented

2017-05-16 10:00:54 +02:00

Added subscriber: @BAndersson

Bjorn Andersson commented

2017-05-16 10:00:54 +02:00

Hi, this bug seems to have a long history....
You seem to have figured out the underlaying problem down to the last detail. Good work!

I'd like to contribute with an observation that might help someone until this is fixed:
The problem is reduced when the focal length of the camera is increased.
It does not seem to depend so much on the distance to the object.
The focal lenght seems to be the major contributor in this case and increasing it above 60mm greatly improves the rendering.

Hi, this bug seems to have a long history.... You seem to have figured out the underlaying problem down to the last detail. Good work! I'd like to contribute with an observation that might help someone until this is fixed: The problem is reduced when the focal length of the camera is increased. It does not seem to depend so much on the distance to the object. The focal lenght seems to be the major contributor in this case and increasing it above 60mm greatly improves the rendering.

Fred Sprinkle commented

2019-09-26 16:32:55 +02:00

Added subscriber: @FredSprinkle

Fred Sprinkle commented

2019-09-26 16:32:55 +02:00

I'm not a developer, but I have been wrestling with this problem a lot as I'm trying to use Freestyle lines for a client animation project using Eevee (I know, risky).

This issue happens with almost all Edge Types. And even if objects are not touching.

During animations the issue appears and then disappears on certain frames with no rhyme or reason.

Things that seem to cause issues:
SubSurf Modifier
Objects Touching

Things that might cause issues:
Large planes
Imperfections in topology
Edge Type math (the issue seems to get worse the more edge types I have checked, but correlation doesn't equal causation)

I'm not a developer, but I have been wrestling with this problem a lot as I'm trying to use Freestyle lines for a client animation project using Eevee (I know, risky). This issue happens with almost all Edge Types. And even if objects are not touching. During animations the issue appears and then disappears on certain frames with no rhyme or reason. Things that seem to cause issues: SubSurf Modifier Objects Touching Things that might cause issues: Large planes Imperfections in topology Edge Type math (the issue seems to get worse the more edge types I have checked, but correlation doesn't equal causation) ![2019-09-26-07_25_28-Blender-Render.jpg](https://archive.blender.org/developer/F7775878/2019-09-26-07_25_28-Blender-Render.jpg)

YimingWu commented

2019-09-27 02:51:32 +02:00

Added subscriber: @ChengduLittleA

YimingWu commented

2019-09-27 02:51:32 +02:00

This problem of random appearing/disappearing lines is due to freestyle's occlusion algorithm. Upcoming LANPR patch will include a smooth contour modifier that deals with freestyle's line problems on subdivided models. We may not be fixing freestyle at the moment and will be focused on LANPR.

Tamito Kajiyama was unassigned by Dalai Felinto

2019-12-23 16:38:52 +01:00

Germano Cavalcante commented

2020-01-16 01:56:44 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-01-16 01:56:44 +01:00

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

This report has been open for a long time.
Since it is not resolved I will indicate as a Known Issue.

I tested the attached file in 2.83 and the result still does not seem right: ![freestyle_wrong_lines.png](https://archive.blender.org/developer/F8280905/freestyle_wrong_lines.png) This report has been open for a long time. Since it is not resolved I will indicate as a `Known Issue`.

Jacob commented

2022-05-22 23:05:20 +02:00

Added subscriber: @oculometric

Jacob commented

2022-05-22 23:05:20 +02:00

hi guys, i know this thread is old and a 'known issue' but i've got something even worse to add on to this. i've attached a blend file where freestyle is generating lines, where there is NO LINE to be drawn. Not hidden/occluded edges, not boolean based edges, but lines where there is no boundary, edge, contour, or crease at all. these lines are just popping up out of no-where at all. i'm really confused.

blender version: 3.1.2
build hash: cc66d1020c
platform: Windows 10 64 bit

AA-11.blend

hi guys, i know this thread is old and a 'known issue' but i've got something even worse to add on to this. i've attached a blend file where freestyle is generating lines, where there is NO LINE to be drawn. Not hidden/occluded edges, not boolean based edges, but lines where there is no boundary, edge, contour, or crease at all. these lines are just popping up out of no-where at all. i'm really confused. blender version: 3.1.2 build hash: cc66d1020c3b platform: Windows 10 64 bit ![Inkedwhatthefuck_LI.jpg](https://archive.blender.org/developer/F13098208/Inkedwhatthefuck_LI.jpg) [AA-11.blend](https://archive.blender.org/developer/F13098211/AA-11.blend)

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Freestyle renders extra lines #36350