Page MenuHome

Custom Normals from a Data Transfer do not save properly
Closed, ArchivedPublic

Description

System Information
macOS Catalina Version 10.15.7
MacBook Pro (16-inch, 2019)
Processor 2.3 GHz 8-Core Intel Core i9
Memory 16 GB 2667 MHz DDR4
Startup Disk Macintosh HD
Graphics AMD Radeon Pro 5500M 4 GB
Intel UHD Graphics 630 1536 MB
Serial Number C02F34R5MD6N

Blender Version
Broken: N/A
Worked: N/A

Short description of error
When I add (not apply) more than one Data Transfer Modifier with custom normals to an object, the second Data Transfer Modifier visually has no effect on the model. Toggling the realtime on and off does fix this, but this never saves. As a result, I need to toggle it on and off again.

Exact steps for others to reproduce the error
For my case, I have a cylinder that is subdivided between the two ends, which are not capped with geometry. This cylinder is also shaded smooth with Auto Smooth enabled. Then, I have another similar cylinder and have the vertices of one end carefully align with the other. The same process applies for the free end of the original cylinder. With both cylinders alined to the ends of my original one, I create two Vertex Groups for my original cylinder. Each one contains the vertices of the and end of the cylinder. Then, I create two Data Transfer Modifiers for my cylinder and give each one the separate vertex groups. The Source objects for each modifier corresponds with the ends that contain the vertex groups. For instance, the cylinder on top of the original cylinder is used as the source for the modifier with the Vertex Group containing the top vertices. Then, I check the Face Corner Data box, select Custom Normals, and set the Mapping to Nearest Face Interpolated.

If there is no visible change on the mesh caused by the second Data Transfer Modifier, toggle the Realtime option on and off for this modifier. Save the Blender project and then reload the scene to see if the modifier is still visible on the mesh. If it is not, then toggle the Realtime option on and off again. Also, I must admit that I am creating a character model crafted from multiple separate mesh objects that are all using Data Transfer modifiers to provide the illusion that they are one mesh. If both ends of the initial cylinder look like they are joined to its additional cylinders, then I would suggest creating other cylinders that also have this same experiment applied to it. I'll even provide a file that actually has the problem in action if necessary.

Event Timeline

I actually have an update on the situation. I think this is related to employing a high amount of DataTranfer modifiers instead. You see, I have a mesh piece that is not "double-ended" and the Normals do not save properly. So at this point, even providing a mesh piece with just one DataTranfer modifier is acting wonky as long as all those other mesh pieces have that same modifier. At this point, my project now employs 10 of those.

Bastien Montagne (mont29) changed the task status from Needs Triage to Needs Information from User.Oct 22 2021, 3:32 PM

Please follow our reporting guidelines (https://www.youtube.com/watch?v=JTD0OJq_rF4) and provide a minimal test .blend file to help demonstrate and reproduce the issue.

I’m confused. How did I not report the bug properly? I will provide you the file I have, but if there is anything else I missed, I would like you to let me know.

Thanks, indeed that blend file was the missing bit.

If you open it you'll see in the console that you have dependency cycle, which prevents depsgraph to provide evaluated source mesh to the second datatransfer modifier:

Dependency cycle detected:
  OBUpArmL/Geometry Component/GEOMETRY_EVAL() depends on
  OBLowArmL/Geometry Component/GEOMETRY_EVAL() via 'DataTransfer Modifier'
  OBBaseLArmLjoin1/Transform Component/TRANSFORM_FINAL() via 'Hook Modifier'
  OBBaseLArmLjoin1/Transform Component/TRANSFORM_SIMULATION_INIT() via 'Simulation -> Final Transform'
  OBBaseLArmLjoin1/Transform Component/TRANSFORM_EVAL() via 'Transform Eval -> Simulation Init'
  OBBaseLArmLjoin1/Transform Component/TRANSFORM_PARENT() via 'Eval'
  OBBaseLArmLjoin1/Transform Component/TRANSFORM_LOCAL() via 'ObLocal -> ObParent'
  OBBaseLArmLjoin1/Transform Component/TRANSFORM_INIT() via 'Transform Init'
  OBUpArmL/Geometry Component/GEOMETRY_EVAL() via 'Vertex Parent'
Dependency cycle detected:
  OBUpArmR/Geometry Component/GEOMETRY_EVAL() depends on
  OBLowArmR/Geometry Component/GEOMETRY_EVAL() via 'DataTransfer Modifier'
  OBBaseLArmRjoin1/Transform Component/TRANSFORM_FINAL() via 'Hook Modifier'
  OBBaseLArmRjoin1/Transform Component/TRANSFORM_SIMULATION_INIT() via 'Simulation -> Final Transform'
  OBBaseLArmRjoin1/Transform Component/TRANSFORM_EVAL() via 'Transform Eval -> Simulation Init'
  OBBaseLArmRjoin1/Transform Component/TRANSFORM_PARENT() via 'Eval'
  OBBaseLArmRjoin1/Transform Component/TRANSFORM_LOCAL() via 'ObLocal -> ObParent'
  OBBaseLArmRjoin1/Transform Component/TRANSFORM_INIT() via 'Transform Init'
  OBUpArmR/Geometry Component/GEOMETRY_EVAL() via 'Vertex Parent'

No bug here, thanks for the report anyway.