render bug in freestyle #47111

New Issue

Torsten Mohr · 2016-01-02T18:27:42+01:00

Torsten Mohr commented

2016-01-02 18:27:42 +01:00

Hello,

in the attached render result there is a line that i can't explain. I also attached the BLEND file that directly leads to this render result.

{F271347}

Best regards
Torsten

Hello, in the attached render result there is a line that i can't explain. I also attached the BLEND file that directly leads to this render result. {[F271347](https://archive.blender.org/developer/F271347/bug_freestyle.blend)}![bug_freestyle.png](https://archive.blender.org/developer/F271345/bug_freestyle.png) Best regards Torsten

Torsten Mohr commented

2016-01-02 18:27:42 +01:00

Changed status to: 'Open'

Torsten Mohr commented

2016-01-02 18:27:42 +01:00

Added subscriber: @tmohr

Aaron Carlisle commented

2016-01-02 20:42:41 +01:00

Added subscriber: @Blendify

Ignatz commented

2016-01-03 14:17:51 +01:00

Added subscriber: @ignatz

Ignatz commented

2016-01-03 14:17:51 +01:00

I downloaded the blend file (bug_freestyle.blend) and had a look.

There is an extra line showing in the render, but I do not believe that this is really a freestyle bug.

The mesh is very simple, consisting of nothing more than extruded cubes which are then curved by the armature. This is actually producing non-planer mesh elements.

I think that what is happening is that when Blender breaks this down into (legal) triangular polys prior to the render we end up with some unexpected geometry.

If you just add in the "triangulate" modifier ahead of the armature modifier in the stack then the rendered result will be just fine.

Of course, this does beg the question as to just why there is a difference in the way that the render engine breaks down the mesh as opposed to the way that it happens when we use the triangulate modifier. That is, perhaps, the real bug here... if it is even a bug.

I downloaded the blend file (bug_freestyle.blend) and had a look. There is an extra line showing in the render, but I do not believe that this is really a freestyle bug. The mesh is very simple, consisting of nothing more than extruded cubes which are then curved by the armature. This is actually producing non-planer mesh elements. I think that what is happening is that when Blender breaks this down into (legal) triangular polys prior to the render we end up with some unexpected geometry. If you just add in the "triangulate" modifier ahead of the armature modifier in the stack then the rendered result will be just fine. Of course, this does beg the question as to just why there is a difference in the way that the render engine breaks down the mesh as opposed to the way that it happens when we use the triangulate modifier. That is, perhaps, the real bug here... if it is even a bug.

Bastien Montagne commented

2016-01-03 16:01:07 +01:00

Added subscribers: @kjym3, @mont29

Tamito Kajiyama was assigned by Bastien Montagne

2016-01-03 16:01:07 +01:00

Bastien Montagne commented

2016-01-03 16:01:07 +01:00

Let’s see what @kjym3 has to say about it. ;)

Tamito Kajiyama commented

2016-01-05 17:00:31 +01:00

Just to confirm what @ignatz said, adding a Triangulate mesh modifier gives Freestyle lines consistent with the Solid render component. Without the extra mesh modifier, Freestyle seems to compute lines based on geometry data that is different from what Cycles and the Blender Internal actually see.

So the problem is where that inconsistency of geometry data comes from. I've never seen this kind of discrepancy and I have no idea of how to fix it. @mont29, do you have any thoughts?

Just to confirm what @ignatz said, adding a Triangulate mesh modifier gives Freestyle lines consistent with the Solid render component. Without the extra mesh modifier, Freestyle seems to compute lines based on geometry data that is different from what Cycles and the Blender Internal actually see. So the problem is where that inconsistency of geometry data comes from. I've never seen this kind of discrepancy and I have no idea of how to fix it. @mont29, do you have any thoughts?

Anthony Edlin commented

2016-01-07 11:01:44 +01:00

Added subscriber: @AnthonyEdlin

Anthony Edlin commented

2016-01-07 11:01:44 +01:00

I did a little debugging on this and have a little more info to give.

First, this is only happening on cycles render, if you switch to blender internal the quads are split the same as freestyle is showing. Here are some renders:

Viewport:

Cycles:

Internal:

The function that is splitting the quads in the internal pipeline is check_non_flat_quads in convertblender.c file. There is a setting under Scene properties tab and on the Simplify panel called Skip Quad to Triangles. If you set this then this function is not called and you can see the result here:

It has the same quads as viewport and cycles but looks like there is some rendering artifacts at least with my settings.

Probably it would be good if quad splitting was consistent across viewport/internal/cycles but finding the best way to do that is probably beyond my knowledge right now. Hope that helps narrow down the issues here. Good luck.

I did a little debugging on this and have a little more info to give. First, this is only happening on cycles render, if you switch to blender internal the quads are split the same as freestyle is showing. Here are some renders: Viewport: ![Viewport.png](https://archive.blender.org/developer/F271814/Viewport.png) Cycles: ![Cycles.png](https://archive.blender.org/developer/F271816/Cycles.png) Internal: ![Internal.png](https://archive.blender.org/developer/F271818/Internal.png) The function that is splitting the quads in the internal pipeline is check_non_flat_quads in convertblender.c file. There is a setting under Scene properties tab and on the Simplify panel called Skip Quad to Triangles. If you set this then this function is not called and you can see the result here: ![SkipQuad.png](https://archive.blender.org/developer/F271823/SkipQuad.png) It has the same quads as viewport and cycles but looks like there is some rendering artifacts at least with my settings. Probably it would be good if quad splitting was consistent across viewport/internal/cycles but finding the best way to do that is probably beyond my knowledge right now. Hope that helps narrow down the issues here. Good luck.

Bastien Montagne commented

2016-01-12 14:16:13 +01:00

@kjym3 Spent some time on this this morning, was suspecting some mismatch in tessellation between freestyle and the renderers, but…

I tried forcing one 'middle edge' or the other in both BlenderFileLoader::insertShapeNode() check places, but gave me no change in result, which I find pretty odd. :|

Freestyle does only work on triangles, right?

@kjym3 Spent some time on this this morning, was suspecting some mismatch in tessellation between freestyle and the renderers, but… I tried forcing one 'middle edge' or the other in both `BlenderFileLoader::insertShapeNode()` check places, but gave me no change in result, which I find pretty odd. :| Freestyle does only work on triangles, right?

Anthony Edlin commented

2016-01-18 19:15:45 +01:00

Really I don't think it's a freestyle issue. Freestyle just uses blender's internal render database to get tri/quads. In this case if you use internal render and not cycles render you get the freestyle lines to match up. So issue is that internal render and cycles render do not do same quad splitting. You can see all of this in my post above. The function that does the internal render database quad splitting is check_non_flat_quads(). I'm not sure how cycles does quad splitting but it seems to always match viewport so it probably just always splits on vert index rather then doing any normals testing like check_non_flat_quads() does.

So possible fixes to this could be.

Make internal render not do the quad splitting, or make it always split on index rather then testing which way to split. This I think would make internal/cycles/freestyle/viewport all have same look, but could make old files internal render different.
Make cycles use same quad splitting as internal. You would have to reimplement check_non_flat_quads() in cycles somewhere. This would make internal/cycles/freestyle have same look, but viewport would show different quad splits in some cases, unless you could also reimplement check_non_flat_quads() for viewport also. Could also make old cycles renders different.
You could also change freestyle to detect which renderer is being used and also make sure it is sent non-split quads from internal renderers database. This way freestyle could split quads either like internal render or like cycles render based on which is being used at the time. Internal render and cycles render would still have inconsistent quad splitting.

I personally think trying to make quad splitting consistent is the way to go.

Really I don't think it's a freestyle issue. Freestyle just uses blender's internal render database to get tri/quads. In this case if you use internal render and not cycles render you get the freestyle lines to match up. So issue is that internal render and cycles render do not do same quad splitting. You can see all of this in my post above. The function that does the internal render database quad splitting is check_non_flat_quads(). I'm not sure how cycles does quad splitting but it seems to always match viewport so it probably just always splits on vert index rather then doing any normals testing like check_non_flat_quads() does. So possible fixes to this could be. 1) Make internal render not do the quad splitting, or make it always split on index rather then testing which way to split. This I think would make internal/cycles/freestyle/viewport all have same look, but could make old files internal render different. 2) Make cycles use same quad splitting as internal. You would have to reimplement check_non_flat_quads() in cycles somewhere. This would make internal/cycles/freestyle have same look, but viewport would show different quad splits in some cases, unless you could also reimplement check_non_flat_quads() for viewport also. Could also make old cycles renders different. 3) You could also change freestyle to detect which renderer is being used and also make sure it is sent non-split quads from internal renderers database. This way freestyle could split quads either like internal render or like cycles render based on which is being used at the time. Internal render and cycles render would still have inconsistent quad splitting. I personally think trying to make quad splitting consistent is the way to go.

Brecht Van Lommel commented

2019-02-01 12:35:14 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-02-01 12:35:14 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2019-02-01 12:35:14 +01:00

Brecht Van Lommel commented

2019-02-01 12:35:14 +01:00

This is solved in 2.8, where freestyle uses the same triangulation as everywhere else in Blender.

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

render bug in freestyle #47111