freestyle edge marks not working #36425

New Issue

Markus Schulz · 2013-08-09T15:40:09+02:00

Markus Schulz commented

2013-08-09 15:40:09 +02:00

%%%--- Operating System, Graphics card ---
Linux Mint 13, MATE 64 bit in vmware 9 workstation.

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

blender-2.68a-linux-glibc211-x86_64 from this web page.

- Short description of error ---

Some marked edges are not rendered.

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

See blend and png

%%%

%%%--- Operating System, Graphics card --- Linux Mint 13, MATE 64 bit in vmware 9 workstation. - Blender version with error, and version that worked --- blender-2.68a-linux-glibc211-x86_64 from this web page. - Short description of error --- Some marked edges are not rendered. - Steps for others to reproduce the error (preferably based on attached .blend file) --- See blend and png %%%

Markus Schulz commented

2013-08-09 15:40:09 +02:00

Changed status to: 'Open'

Anthony Edlin commented

2013-09-09 17:16:13 +02:00

%%%Hi, thanks for the report.

I don't think this is mainly a problem with freestyle. The edges that aren't drawn in freestyle in your sphere mesh are bad because they have several edges/verts/faces right on top of each other. You can see this by selecting and moving them or by selecting everything and doing a remove doubles. If you move them or mark the hidden edges then there are no problems.

You can also recreate this problem from scratch by following these steps:

Create a UV sphere with no freestyle edge marks.
Select a single edge line on the side facing the camera.
Press E to extrude and then right click to cancel the movement. This creates faces right on top of the edge you had selected.
Deselect everything.
Box select the area that you extruded from and some edges around it.
Mark as freestyle edges.
Render with proper freestyle settings and notice that the edges you extruded from aren't rendered even though it looks like they are marked.

If you really want these edges rendered then select them and use something like alt-S to scale them up just slightly so that they aren't in the same place as other faces and they will render. If you didn't mean to create these edges then just select everything and do a remove doubles. Then remark the now revealed edges and you should be good to go.

Good luck.%%%

%%%Hi, thanks for the report. I don't think this is mainly a problem with freestyle. The edges that aren't drawn in freestyle in your sphere mesh are bad because they have several edges/verts/faces right on top of each other. You can see this by selecting and moving them or by selecting everything and doing a remove doubles. If you move them or mark the hidden edges then there are no problems. You can also recreate this problem from scratch by following these steps: 1. Create a UV sphere with no freestyle edge marks. 2. Select a single edge line on the side facing the camera. 3. Press E to extrude and then right click to cancel the movement. This creates faces right on top of the edge you had selected. 4. Deselect everything. 5. Box select the area that you extruded from and some edges around it. 6. Mark as freestyle edges. 7. Render with proper freestyle settings and notice that the edges you extruded from aren't rendered even though it looks like they are marked. If you really want these edges rendered then select them and use something like alt-S to scale them up just slightly so that they aren't in the same place as other faces and they will render. If you didn't mean to create these edges then just select everything and do a remove doubles. Then remark the now revealed edges and you should be good to go. Good luck.%%%

Markus Schulz commented

2013-09-14 00:09:12 +02:00

%%%Thanks for the explanation! I just used the default sphere and I was not aware that it has doubles. I would never figured this out on my own, I only have very basic Blender knowledge. The big question would be are the double needed in the default?%%%

Anthony Edlin commented

2013-09-14 02:49:04 +02:00

%%%As far as I can tell, the default UV sphere does not have double faces anywhere. Most likely it was just a miss button press. Given that the common shortcut to mark freestyle edges is ctrl+e, and the shortcut for extruding is just e, it seems likely that someone would accidentally press e and extrude and then right click to cancel. But because by default e is bound to the "extrude and move" macro it only cancels the move part and not the extrude, which leaves the extra faces in the same spot as what you had selected. This right click to cancel the move of an extrude is pretty commonly used by modellers if they for instance want to scale the extruded geometry.%%%

Bastien Montagne commented

2013-10-04 15:21:09 +02:00

%%%Removing doubles indeed solves part of the issue, but their remain some marked edges that do not render, and some non-marked edges (quads' diagonals) that do render…%%%

Anthony Edlin commented

2013-10-04 15:41:41 +02:00

%%%Could you possibly be more specific, because I can not reproduce what you describe. If I remove doubles and look at what is still marked it renders exactly what is marked as freestyle edges. The line set includes crease, silhouette, border, and contour so of course those are drawn, but I don't see anything wrong with those either.%%%

Tamito Kajiyama commented

2013-10-05 02:04:18 +02:00

%%%I confirm the issues reported by Bastien. For some unknown reason related to temporary changes in trunk r59373, the fs_test.blend file renders diagonal lines in some of the quads of the sphere (with Remove Doubles applied). If the r59373 changes are reverted, the diagonal lines will disappear. I need to further investigate the real cause of this issue.
http://lists.blender.org/pipermail/bf-blender-cvs/2013-August/058501.html

I also tend to suspect something wrong in the mesh data, because I could not reproduce the issue no matter how I added a new mesh object and tried to mess up the mesh geometry by extrude and other mesh editing operations. If someone could figure out how to create mesh data that cause unwanted diagonal lines in quad faces, I would really appreciate it.%%%

%%%I confirm the issues reported by Bastien. For some unknown reason related to temporary changes in trunk r59373, the fs_test.blend file renders diagonal lines in some of the quads of the sphere (with Remove Doubles applied). If the r59373 changes are reverted, the diagonal lines will disappear. I need to further investigate the real cause of this issue. http://lists.blender.org/pipermail/bf-blender-cvs/2013-August/058501.html I also tend to suspect something wrong in the mesh data, because I could not reproduce the issue no matter how I added a new mesh object and tried to mess up the mesh geometry by extrude and other mesh editing operations. If someone could figure out how to create mesh data that cause unwanted diagonal lines in quad faces, I would really appreciate it.%%%

Anthony Edlin commented

2013-10-05 11:45:45 +02:00

%%%Confirmed on latest trunk.

I was able to reproduce by just adding another UV sphere and box selecting a good chunk of it and marking with freestyle edges. In fact, if I mark just 3 edges of small quad it pretty reliably gives the error, even on just a subdivided cube.

I don't think this issue has anything to do with what was reported in this bug report, so maybe rename or create a new report?%%%

%%%Confirmed on latest trunk. I was able to reproduce by just adding another UV sphere and box selecting a good chunk of it and marking with freestyle edges. In fact, if I mark just 3 edges of small quad it pretty reliably gives the error, even on just a subdivided cube. I don't think this issue has anything to do with what was reported in this bug report, so maybe rename or create a new report?%%%

Anthony Edlin commented

2013-10-07 09:23:57 +02:00

%%%It seems to be tied to chaining with sketchy and more then 1 round, it easily shows up when using those settings.

Is there an example file or bug report that was associated with why r59373 was added?%%%

%%%It seems to be tied to chaining with sketchy and more then 1 round, it easily shows up when using those settings. Is there an example file or bug report that was associated with why r59373 was added?%%%

Anthony Edlin commented

2013-10-09 19:59:43 +02:00

%%%So looking at the code it's not hard to see why it is doing this, just create a stroke with 2 acute angles in a row and it'll switch the verts. You can construct several edges with these properties if chaining is enabled. It's very easy when you have sketchy with rounds 2 or greater because at the end of the stroke it turns around, but you can easily create strokes that switch verts even in plain or sketchy with 1 round.

So the real question for me is why was r59373 added. It is clearly doing a vert switch if there are 3 edges in a row on the stroke with acute angles. The commit message doesn't really explain in depth the error and I don't have a file to test so at this point I can't really reproduce it or investigate a proper fix.%%%

%%%So looking at the code it's not hard to see why it is doing this, just create a stroke with 2 acute angles in a row and it'll switch the verts. You can construct several edges with these properties if chaining is enabled. It's very easy when you have sketchy with rounds 2 or greater because at the end of the stroke it turns around, but you can easily create strokes that switch verts even in plain or sketchy with 1 round. So the real question for me is why was r59373 added. It is clearly doing a vert switch if there are 3 edges in a row on the stroke with acute angles. The commit message doesn't really explain in depth the error and I don't have a file to test so at this point I can't really reproduce it or investigate a proper fix.%%%

Tamito Kajiyama commented

2013-10-10 00:55:02 +02:00

%%%Anthony,
Many thanks for the analyses of the issue. I think you have spotted a bug in the temporary fix in r59373.

The problem that the changes in r59373 were intended to address was the following. When two mesh edges intersect with each other in the 2D image coordinate system, a new vertex called TVertex is created. Specifically, when two edges AB and CD intersect at a 2D point P, the edge AB is split into two edges AA' and A'B, where A' is a new TVertex. Similarly, the edge CD is split into CC' and C'D, with a new TVertex C'. The problem is that for some unknown reason, TVertices may introduce a couple of quick stroke direction changes with in a sub-pixel distance. For instance, when a stroke is proceeding downward, two successive TVertices may appear in the stroke in such a way that the edge between the TVertices proceeds upward. This kind of quick stroke direction changes creates an annoying visual artefact.

The temporary fix in r59373 was intended to be a workaround for the quick stroke direction changes, but the conditions to identify them were too general (specifically, in the code at least an additional restriction about the length of the vector 'seg2' was necessary).

I am going to fix this bug asap (before the 2.69 release if time permits). Again thanks a lot for bringing my attention to the bug in the bug fix.%%%

%%%Anthony, Many thanks for the analyses of the issue. I think you have spotted a bug in the temporary fix in r59373. The problem that the changes in r59373 were intended to address was the following. When two mesh edges intersect with each other in the 2D image coordinate system, a new vertex called TVertex is created. Specifically, when two edges AB and CD intersect at a 2D point P, the edge AB is split into two edges AA' and A'B, where A' is a new TVertex. Similarly, the edge CD is split into CC' and C'D, with a new TVertex C'. The problem is that for some unknown reason, TVertices may introduce a couple of quick stroke direction changes with in a sub-pixel distance. For instance, when a stroke is proceeding downward, two successive TVertices may appear in the stroke in such a way that the edge between the TVertices proceeds upward. This kind of quick stroke direction changes creates an annoying visual artefact. The temporary fix in r59373 was intended to be a workaround for the quick stroke direction changes, but the conditions to identify them were too general (specifically, in the code at least an additional restriction about the length of the vector 'seg2' was necessary). I am going to fix this bug asap (before the 2.69 release if time permits). Again thanks a lot for bringing my attention to the bug in the bug fix.%%%

Anthony Edlin commented

2013-10-10 10:32:56 +02:00

%%%Tamito Kajiyama,
Great to hear you know what to do to fix this.

I'd like to investigate more into why the strange behavior with TVertex, but I can't reproduce any errors with splitting and chaining, it all seems to work fine as far as I can tell. Do you have a file or some simple steps to reproduce the problem with TVertex artifacts?

Thanks.%%%

%%%Tamito Kajiyama, Great to hear you know what to do to fix this. I'd like to investigate more into why the strange behavior with TVertex, but I can't reproduce any errors with splitting and chaining, it all seems to work fine as far as I can tell. Do you have a file or some simple steps to reproduce the problem with TVertex artifacts? Thanks.%%%

Tamito Kajiyama commented

2013-10-13 23:04:04 +02:00

%%%Anthony,
In the trunk revision 60731 I made a quick fix for the issue you identified through this discussion. The original problem still needs to be addressed, although the present workaround appears quite effective.

I have a test .blend file to reproduce the original problem, but the file cannot be released because of a non-disclosure agreement (the scene is part of production material under development by the reporter of the issue). I was trying to reproduce the issue from scratch, but so far no luck. The test scene consists of many buildings from near the camera to a distance, so that there are many hidden faces. The issue is mostly seen in a TVertex created at the intersection of a visible edge and a hidden edge.%%%

%%%Anthony, In the trunk revision 60731 I made a quick fix for the issue you identified through this discussion. The original problem still needs to be addressed, although the present workaround appears quite effective. I have a test .blend file to reproduce the original problem, but the file cannot be released because of a non-disclosure agreement (the scene is part of production material under development by the reporter of the issue). I was trying to reproduce the issue from scratch, but so far no luck. The test scene consists of many buildings from near the camera to a distance, so that there are many hidden faces. The issue is mostly seen in a TVertex created at the intersection of a visible edge and a hidden edge.%%%

Anthony Edlin commented

2013-11-25 21:15:33 +01:00

I added a testing file, but I don't think this is exactly related to this problem of subpixel tvertexes going in the wrong direction. It is more to do with some hidden lines showing up as visible. I still can't seem to reproduce the original issue.

The current fix for the original issue is, well, pretty much a hack, and really should not be left in forever without understanding why the original issue comes up. I'll keep trying to debug this as time permits, but without a reproducible blend it's kind of just taking stabs in the dark.

I added a testing file, but I don't think this is exactly related to this problem of subpixel tvertexes going in the wrong direction. It is more to do with some hidden lines showing up as visible. I still can't seem to reproduce the original issue. The current fix for the original issue is, well, pretty much a hack, and really should not be left in forever without understanding why the original issue comes up. I'll keep trying to debug this as time permits, but without a reproducible blend it's kind of just taking stabs in the dark.

Tamito Kajiyama commented

2014-05-25 09:11:40 +02:00

Here is an example .blend file for reliably reproducing the issue of thinning strokes due to TVertices (based on a production file by Light BWK after heavily stripping the original scene data to the minimum).

thinning_stroke.blend

In Blender 2.67 a thinning stroke was observed as shown below. There is a hidden mesh edge behind the point (i.e., a TVertex) at which the vertical line is thinning.

This issue was addressed by a workaround in 2.68. This temporary fix has been identified as a source of thinning strokes. A proper (but still partial) fix will be done later. Here is a render of the same example scene after the fix.

Here is an example .blend file for reliably reproducing the issue of thinning strokes due to TVertices (based on a production file by Light BWK after heavily stripping the original scene data to the minimum). [thinning_stroke.blend](https://archive.blender.org/developer/F90678/thinning_stroke.blend) In Blender 2.67 a thinning stroke was observed as shown below. There is a hidden mesh edge behind the point (i.e., a TVertex) at which the vertical line is thinning. ![thinning_stroke_267.png](https://archive.blender.org/developer/F90679/thinning_stroke_267.png) This issue was addressed by a workaround in 2.68. This temporary fix has been identified as a source of thinning strokes. A proper (but still partial) fix will be done later. Here is a render of the same example scene after the fix. ![thinning_stroke_fixed.png](https://archive.blender.org/developer/F90681/thinning_stroke_fixed.png)

Tamito Kajiyama commented

2014-05-26 04:00:25 +02:00

Changed status from 'Open' to: 'Resolved'

Tamito Kajiyama closed this issue

2014-05-26 04:00:25 +02:00

Tamito Kajiyama commented

2014-05-26 04:00:25 +02:00

The bug that made it necessary to introduce a temporary workaround for thinning strokes was fixed in two commits 08528f577d and fce731a175.

The bug that made it necessary to introduce a temporary workaround for thinning strokes was fixed in two commits 08528f577d and fce731a175.

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 edge marks not working #36425