Page MenuHome

Freestyle renders extra lines
Open, Confirmed, MediumPublic

Description

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

Details

Type
Bug

Event Timeline

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

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 (ccinage) closed this task as a duplicate.Mar 12 2014, 5:47 PM

โœ˜ Merged into T39134.

Tamito Kajiyama (kjym3) added a comment.EditedAug 28 2014, 4:35 AM

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.

@Tamito Kajiyama (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.

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.

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.

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