Custom normals corrupted by triangulation after data transfer modifier is applied. #44878

New Issue

Drongle McMahon · 2015-05-28T22:11:34+02:00

Drongle McMahon commented

2015-05-28 22:11:34 +02:00

Reproduction: The file provided (triang_nmls.blend) contains five smooth shaded objects. One cube, "nml_source", is used as the source for controlling the custom normals of the other objects by the Data Transfer modifier. It has auto-smooth with angle set to 72 degrees so that the custom normals of each face are the same as that face's face normal, pointing along one of the major axes. The object "tran" was derived by applying the bevel tool to a duplicate of the cube, followed by deletion of half the vertices. It has auto-smooth angle set to 180 degrees. A Data Transfer modifier is applied to control the custom normals of the derived object so that they point along major axes instead of being interpolated between adjacent face normals. Three further objects were derived in the same way, then subjected to different sequences of further modifications. For "tran_tri", all faces were triangulated. The Data Transfer modifier remains in the stack. For "tran_tri_apply", all faces were triangulated and then the Data Transfer modifier was applied. For "tran_apply_tri", the Data Transfer modifier was applied and then the faces were triangulated. These three sequences can be reproduced by starting with "tran".

Expected behaviour: Custom normals are properties of (polygon(corner)). When higher order polygons of polygons are triangulated, some corners are split into two new (triangle(corner)) by new diagonals. Where this occurs, it is expected that both(all) the new (triangle(corner)) would receive the same custom normal as the (polygon(corner)) that was split. For the objects here, that would leave all custom normals pointing along the major axes.

Observed behaviour: When triangulation is done after applying the Data Transfer modifier ("tran_apply_tri"), the custom normals at two of the vertices do not point along the expected directions.

This effect was originally observed with much more complex mesh, in which case may normals were found to point in unexpected directions.

Note: the objects here are all UV mapped, but no differences were found with similar models without UV mapping.

To investigate the behaviour of the objects upon export with the Collada exporter, all four derived objects were selected and exported with and without the exporter apply modifiers option, and with and without the exporters triangulation option. All other options were unchecked. The results were consistent with the above observations under the assumption that the exporter applies modifiers before triangulation. That is to say that if the exporter was relied on for both functions, then (two of) the exported normals were not in the expected directions along major axes. (The export tests were done with nightly build Blender 2.74 dc15860 in which a bug in the triangulation had been fixed).

triang_nmls.blend

Reproduction: The file provided (triang_nmls.blend) contains five smooth shaded objects. One cube, "nml_source", is used as the source for controlling the custom normals of the other objects by the Data Transfer modifier. It has auto-smooth with angle set to 72 degrees so that the custom normals of each face are the same as that face's face normal, pointing along one of the major axes. The object "tran" was derived by applying the bevel tool to a duplicate of the cube, followed by deletion of half the vertices. It has auto-smooth angle set to 180 degrees. A Data Transfer modifier is applied to control the custom normals of the derived object so that they point along major axes instead of being interpolated between adjacent face normals. Three further objects were derived in the same way, then subjected to different sequences of further modifications. For "tran_tri", all faces were triangulated. The Data Transfer modifier remains in the stack. For "tran_tri_apply", all faces were triangulated and then the Data Transfer modifier was applied. For "tran_apply_tri", the Data Transfer modifier was applied and then the faces were triangulated. These three sequences can be reproduced by starting with "tran". Expected behaviour: Custom normals are properties of (polygon(corner)). When higher order polygons of polygons are triangulated, some corners are split into two new (triangle(corner)) by new diagonals. Where this occurs, it is expected that both(all) the new (triangle(corner)) would receive the same custom normal as the (polygon(corner)) that was split. For the objects here, that would leave all custom normals pointing along the major axes. Observed behaviour: When triangulation is done after applying the Data Transfer modifier ("tran_apply_tri"), the custom normals at two of the vertices do not point along the expected directions. This effect was originally observed with much more complex mesh, in which case may normals were found to point in unexpected directions. Note: the objects here are all UV mapped, but no differences were found with similar models without UV mapping. To investigate the behaviour of the objects upon export with the Collada exporter, all four derived objects were selected and exported with and without the exporter apply modifiers option, and with and without the exporters triangulation option. All other options were unchecked. The results were consistent with the above observations under the assumption that the exporter applies modifiers before triangulation. That is to say that if the exporter was relied on for both functions, then (two of) the exported normals were not in the expected directions along major axes. (The export tests were done with nightly build Blender 2.74 dc15860 in which a bug in the triangulation had been fixed). [triang_nmls.blend](https://archive.blender.org/developer/F180966/triang_nmls.blend)

Drongle McMahon commented

2015-05-28 22:11:34 +02:00

Changed status to: 'Open'

Gaia Clary was assigned by Drongle McMahon

2015-05-28 22:11:34 +02:00

Drongle McMahon commented

2015-05-28 22:11:34 +02:00

Added subscriber: @Drongle

Gaia Clary was unassigned by Bastien Montagne

2015-05-29 13:14:33 +02:00

Bastien Montagne self-assigned this 2015-05-29 13:14:33 +02:00

Bastien Montagne commented

2015-05-29 13:14:33 +02:00

Added subscriber: @GaiaClary

Bastien Montagne commented

2015-05-29 13:17:40 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2015-05-29 13:17:40 +02:00

Bastien Montagne commented

2015-05-29 13:17:41 +02:00

This has nothing to do with collada…

Thanks for the report, but this is known limitation of custom normals currently - they survive rather well deformations, but not changes in topology. This may be addressed (at least partially) in future, but is not considered a bug.

This has nothing to do with collada… Thanks for the report, but this is known limitation of custom normals currently - they survive rather well deformations, but not changes in topology. This may be addressed (at least partially) in future, but is not considered a bug.

Drongle McMahon commented

2015-05-29 13:49:42 +02:00

Thanks for looking at it anyway. A pity, as this reduces the utility of custom normals. However, for my purposes at least, I can work around it. It affects Collada because the corruption of the normals happens in the Collada exporter when both apply modifiers and triangulation options are checked. In that case, it appears to the user as a failure of the Collada exporter. The report was initially constructed in that context, the underlying cause only becoming evident in constructing the simple case. If it were possible, Inversion of the order of triangulation and application of this modifier in the exporter would solve an otherwise obscure problem. However, I suppose that's impossible because other modifiers must precede triangulation. In that case, changing the default of the triangulation export option to off may help many users avoid the problem. So if the underlying problem can't be addressed, its effect on Collada export, that appears to users as a failure of the exporter, might still be alleviated by changes to the exporter.

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

Custom normals corrupted by triangulation after data transfer modifier is applied. #44878