Page MenuHome

Bevel modifier alternates face UV island along face-loop
Closed, ResolvedPublic


System Information
OSX 10.9.1

Blender Version
It happens with every version I've tried

Short description of error
When I bake an object space normal map using either BI or Cycles, the normals for the polygons created by the bevel modifier are inverted for every second poly along the UV seams.

When I invert all the normals for the model, the faces which were not visible in the baked texture now become visible and the ones which were visible become no longer show in the map.

This does not happen for camera renders.

Exact steps for others to reproduce the error
Here are two screen captures showing the model/baked texture/modifier settings. One model has outward facing normals and the other has normals that are pointing inwards.

I've also attached a .blend file with the setup.



Event Timeline

marc dion (marcclintdion) updated the task description. (Show Details)
marc dion (marcclintdion) raised the priority of this task from to Needs Triage by Developer.
marc dion (marcclintdion) set Type to Bug.

It turns out that the extra polys are just being attached to alternating islands so there are extra seams being created so I guess this is still a bug but it's different then I originally reported.

Here's a screen capture of what it looks like applied to the model with no margin overdraw. There are seams showing up in a jigsaw pattern all along the seam which should be a straight line.

Here's how it looks once the model is displayed using the baked normal map, the zigzag pattern is clearly visible.

Campbell Barton (campbellbarton) renamed this task from baking using bevel modifier has inverted normals along the UV seams for every second poly to Bevel modifier alternates face UV island along face-loop.Mar 16 2015, 3:51 AM

After thinking about this for a while, I think that using a Segment setting of 1 is the wrong approach for this technique since the tool is forced to make decisions on where the Bevel's virtual faces should end up in UV coordinates.

It seems best to use even integers for the number of segments since using uneven numbers introduces ambiguity into the results.

Using 2 segments works fine when the Limit Method is set to None but this makes the underlying polygons very obvious along curved surfaces.

To deal with the smoothing issue, I've set the Limit Method to Angle but now the UV's become torn as shown in the next image.

The results make it seem as if Limit Method = Angle and Limit Method = None are using two different methods to interpret the UV's. Maybe the method for 'None' can be ported over to 'Angle'.

I've seen UV's tear like this many times when using various Edit Mode generative tools since I tend to work on UV's right from the start of the model. (For that issue, I'm still looking for the pattern, nothing solid to report there yet ;)

Perhaps a temporary code work-around could be used if nothing else works.

If Bevel were to perform some version of bpy.ops.uv.unwrap(-,-) after it calculates the UV offsets then it would be a straight-forward matter for an artist to add a second UV layer(or have the code do this) and then re-bake the normal map to the original coordinates afterwards.

That's easier then adding , and afterwards removing again, dozens of perimeter loops and insets so a Subdivision Modifier can be used.

I think this new problem with torn UV's sort of makes this a different bug report. Let me know if you would prefer a separate report filed, (or you can just change the title again :)

just noticed another problem with the UV interpolation. The resulting bake is not using up the full UV island space. There is a fairly substantial gap between the boundary and where the colors are being filled in.

I've marked off some of the gaps with white lines in the following image.

The next image shows the result without a Bevel Modifier being active.

I'm not sure what bug is being reported here any more. Yesterday I committed a bunch of changes to the way UVs are interpolated with the bevel tool/modiifer. It fixed another bug where there was 'tearing' of UVs. So maybe it fixed some of the problems being reported here.

Marc, would it be possible to retry with a build after yesterday and see if there is still a bug that you would like addressed?

Bastien Montagne (mont29) lowered the priority of this task from Normal to Needs Information from User.Aug 13 2015, 2:28 PM

You fixed it Howard thanks. :) I tried seven models and they all came out fine so far as this bug report goes.

Howard Trickey (howardt) closed this task as Resolved.Aug 13 2015, 5:49 PM

Thanks, Marc. I'm closing this bug then.