Custom Normals DataTransfer breaks with non uniform scale #34
Assignees
Triager-bot
Clear assignees
Triager-bot
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Triager-bot/blender-bug-reports#34
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Original bug report: https://projects.blender.org/blender/blender/issues/157201
System Information
Operating system: Windows-11-10.0.26200-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 4060 Ti NVIDIA Corporation NVIDIA 591.86 Vulkan Backend
Blender Version
Broken: version: 5.1.0, branch: blender-v5.1-release, commit date: 2026-03-16 18:50, hash:
adfe2921d5f3Worked: (newest version of Blender that worked as expected)
Short description of error
I dont know if this was an issue before or not but i just noticed this in the lastest release.
in the screenshot/blender file i have 2 identical cubes with the data transfer modifier, left with a uniform scale, right with an x scale of 0,5
i would think that data transfer should transfer normals regardless of scale uniformity.
i tried this same setup out in the latest daily builds and this behaviour does persist
Exact steps for others to reproduce the error
Add DataTransfer Modifier with Face Corner Data and Custom normals
add any sort of non uniform scale to the object
Report is clear
LLM Reasoning
Got it, let's see. The bug report has a title, body with system info (but we ignore that), short description, and steps to reproduce. The description explains the issue: two cubes with data transfer modifier, one uniform scale, one non-uniform (x 0.5). They expect normals to transfer regardless of scale, but it's broken. Steps are clear: add DataTransfer with Face Corner Data and Custom normals, then add non-uniform scale. So the text is clear about what's wrong and how to reproduce. So the answer should be Yes.
JSON Data
{
"llm_judgement": true,
"processing_time": 7.637957
}
Report is specific
LLM Reasoning
Got it, let's analyze this bug report. The title is "Custom Normals DataTransfer breaks with non uniform scale". The body describes a specific scenario: two cubes with Data Transfer modifier, one with uniform scale, the other with x scale 0.5. The steps to reproduce are adding the modifier and applying non-uniform scale. This is about a specific issue because it's tied to a particular feature (DataTransfer modifier) and a specific condition (non-uniform scale). So the answer should be 'Specific'.
JSON Data
{
"llm_judgement": true,
"processing_time": 7.4111530000000005
}
Report flagged as NOT a duplicate by LLM
Data Transfer's modifier Face Corner Custom Normals Tranfer don't work as expected
https://projects.blender.org/blender/blender/issues/116069
System Information
Operating system: Windows 10
Graphics card: GTX1080ti
Blender Version
Broken: 4.1
Worked: 4.0
Short description of error
Data Transfer Face Corner Data Custom Normals Tranfer does not work as intended.
Data Transfer required Auto-Smooth, that is no longer supported. I suspect this could be the root of the issue.
Exact steps for others to reproduce the error
Open attached .blend with Blender 4.0 and with 4.1.
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the key sections: Description and Steps to Reproduce.
Bug Report 1:
Bug Report 2:
Now, check if the core issue is the same. Report 1 is about non-uniform scale causing custom normals data transfer to break. Report 2's steps involve an attached .blend (which we don't have), and the description mentions Auto-Smooth, but the title is about Face Corner Custom Normals not working as expected. The root cause in Report 1 is non-uniform scale, while Report 2's issue might be different (maybe related to Auto-Smooth removal). Since the steps and descriptions don't align—Report 1 has a clear step with non-uniform scale, Report 2 uses an attached file and mentions Auto-Smooth—they are not the same issue. So the answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 18.512925,
"duplicate_report_number": "116069"
}
Report flagged as NOT a duplicate by LLM
Regression: Custom normals data transfer modifier does not work
https://projects.blender.org/blender/blender/issues/111898
System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070 Ti/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 536.40
Blender Version
Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-07-26 17:27, hash:
234f866db237Worked: version: 4.0.0 Alpha, branch: main, commit date: 2023-07-15 18:34, hash:
a1a08610b60fSeems this is caused by 5e9ea9243b33916e693c5a4b900bcaf214882a96
Short description of error
The Data Transfer modifier when set to transfer Face Corner Data > Custom Normals often doesn't work or produces incorrect results.
Exact steps for others to reproduce the error
Modifier does not work
Cube.001and observe the normals flickering as the value changesLLM Reasoning
Got it, let's analyze the two bug reports. First, look at the descriptions and steps to reproduce.
Bug Report 1: The issue is about Custom Normals DataTransfer breaking with non-uniform scale. Steps involve adding DataTransfer modifier with Face Corner Data and Custom normals, then applying non-uniform scale.
Bug Report 2: The issue is that the Data Transfer modifier for Custom Normals often doesn't work or gives incorrect results. Steps include opening a .blend (authored in 3.6.2) and adjusting Mix Factor, observing flickering normals.
The key here is whether the core problem is the same. Bug 1 is about non-uniform scale causing issues with custom normals transfer. Bug 2 is about the modifier not working or incorrect results, possibly related to a regression (since it mentions a commit hash). The steps and descriptions don't match exactly—Bug 1 focuses on scale, Bug 2 on general failure or flickering. So they are different issues. Therefore, the answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 14.937736000000001,
"duplicate_report_number": "111898"
}
Report flagged as NOT a duplicate by LLM
Custom Normals via Data Transfer Modifier breaks smooth by angle
https://projects.blender.org/blender/blender/issues/154423
System Information
N/A
Blender Version
Broken: Blender 2.3 - 5.0.1
Worked: Never, looks like
Altering a mesh's Normals via the Data Transfer Modifier completely stops Sharp Edges from functioning.
My understanding of Modifiers is that a Modifier lower down in the stack is applied after Modifiers above them. That being the case, if I have a Data Transfer Modifier modifying the Normals of an object, then placing a Modifier that 'activates' a model's Sharp Edges- like Autosmooth or Edge Split- should then apply them over the Custom Normals.
But what happens currently is that, no matter where you place a Modifier that would 'turn on' Sharp Edges applied to the model, they never actually work
Exact steps for others to reproduce the error
Interestingly if you apply the
Data Transfer Modifier, enabling and disabling sharp edges starts to do something.LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the "Description of issue" and "Steps to reproduce".
Bug report 1 is about Custom Normals DataTransfer breaking with non-uniform scale. The steps are adding DataTransfer Modifier with Custom normals and a non-uniform scale.
Bug report 2 is about Custom Normals via Data Transfer Modifier breaking smooth by angle (like Autosmooth or Edge Split). The steps involve using Data Transfer on a cube, then trying to apply Sharp Edges (via Smooth by Angle) which doesn't work until the Data Transfer is removed/applied.
The core issues are different: one is about scale affecting normals transfer, the other is about modifiers that affect sharp edges not working with Data Transfer. So they're not the same issue. Therefore, the answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 13.035637,
"duplicate_report_number": "154423"
}
Report flagged as NOT a duplicate by LLM
Normals not properly updating when using a Deform modifier after a Data Transfer (Custom Normals) modifier
https://projects.blender.org/blender/blender/issues/94838
System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX TITAN X/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 472.12
Blender Version
Broken: version: 3.0.0, branch: master, commit date: 2021-12-02 18:35, hash:
f1cca30557Short description of error
If you transfer vertex Normals with the Data Transfer modifier, and then deform the mesh with modifiers placed afterwards, it does not properly update the Normals in many instances. However, it starts working if you put a modifier that alters the mesh after the Data Transfer and before the deforming modifier.
For example, if you do an Edge Split modifier and uncheck Edge Angle and have no edges marked Sharp Edges, then the problem does not occur. If you uncheck Sharp Edges, then it comes back. Or if you use a Decimate Modifier set on Planar with a tiny Angle Limit like 0.0001, the problem goes away even though the mesh hasn't actually changed.
Demonstration:
Plane A is having Normals transferred from B, which is having them transferred from C. A toon shader material is on to make it easy to see shading differences. Plane C is being bent into a Cylinder with a Simple Deform modifier.
DataTransfer_bug-1.blend
Exact steps for others to reproduce the error
Add an Edge Split modifier before the Deform modifier and uncheck Edge Angle. It should now look correct.
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.
Bug Report 1 is about Custom Normals DataTransfer breaking with non-uniform scale. The steps are adding a DataTransfer modifier with Custom normals and applying non-uniform scale. The issue is that the normals don't transfer correctly when there's non-uniform scaling.
Bug Report 2 is about Normals not updating when using a Deform modifier after Data Transfer (Custom Normals). The steps involve transferring normals, then deforming the mesh with a deform modifier, and the normals don't update properly. There's also mention of adding an Edge Split before the deform to fix it.
So the core issues are different: one is about non-uniform scale affecting data transfer, the other is about deform modifiers after data transfer causing normal updates to fail. The steps to reproduce are distinct—scale vs. deform modifier order. Therefore, they're not the same issue. So the answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 16.0258,
"duplicate_report_number": "94838"
}
Report flagged as NOT a duplicate by LLM
Objects with custom normals are different in 5.1
https://projects.blender.org/blender/blender/issues/154198
System Information
Operating system: Windows-11-10.0.26200-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 4090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 591.86 Opengl Backend
Blender Version
Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-02-10 11:39, hash:
cf9f1897aa99Broken: version: 5.1.0 Beta, branch: blender-v5.1-release, commit date: 2026-02-10 01:04, hash:
81857ea926a5Worked: 5.0
Short description of error
If a object with custom normals and auto smooth from a older version of Blender (E.g. 3.5) is opened in Blender 5.1, it's normals will change.
This seems to occur because a auto smooth modifier is added to the object when it is opened in Blender 5.1, but it isn't added in 5.0.
Technically adding a auto smooth modifier is correct since the object had auto smooth enabled in 3.5, but it's producing the wrong results.
Exact steps for others to reproduce the error
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the "Description of issue" and "Steps to reproduce".
Bug report 1 is about Custom Normals DataTransfer breaking with non-uniform scale. The steps involve adding a DataTransfer modifier with custom normals and applying non-uniform scale.
Bug report 2 is about objects with custom normals being different in 5.1, specifically when opening old files (like 3.5) where auto smooth is involved, leading to normal changes between versions.
The core issues are different: one is about DataTransfer modifier with scale, the other is about version differences in handling custom normals from older Blender files. So they're not the same issue. Therefore, the answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 12.571067,
"duplicate_report_number": "154198"
}