Page MenuHome

render bug in freestyle
Closed, ResolvedPublic



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.

Best regards



Event Timeline

Torsten Mohr (tmohr) raised the priority of this task from to Needs Triage by Developer.
Torsten Mohr (tmohr) updated the task description. (Show Details)
Torsten Mohr (tmohr) set Type to 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 (mont29) lowered the priority of this task from Needs Triage by Developer to Normal.Jan 3 2016, 4:01 PM

Just to confirm what @Ignatz (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. @Bastien Montagne (mont29), do you have any thoughts?

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:




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.

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

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

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