Page MenuHome
Create Task
Maniphest T73941

Custom normals from normal edit modifier ignored by further modifiers
Closed, ResolvedPublicBUG
Actions

Description

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 432.00

Blender Version
Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: rB77d23b0bd76f
Also broken: Blender 2.83 alpha hash f6d5a9551380

Short description of error
Setting custom normals via normal edit modifier does not affect further modifiers that use custom normals-- only the unmodified custom normal is used.

True of at least displace and data transfer modifiers-- not sure if any other modifiers use custom normals for anything.

Exact steps for others to reproduce the error

Attached file demonstrates a cube receiving radial normals from the camera, then displacing along custom normals. Apply the top most modifier (the normal edit modifier) and notice that the direction of displacement changes as custom normals are written to original custom normals.

custnormdisp1.blend547 KBDownload

I believe this should be treated as a bug because I think that the general intent is that applying the topmost modifier shouldn't be any different visually-- it should be what you see is what you get. (Outside of a few exceptions like corrective smooths bound to original coords, for obvious reasons.)

This behavior is also inconsistent with the behavior of custom normals set via a weighted normal modifier. When that modifier is used, it seems to affect further modifiers appropriately.

Ran into this while trying to make a live projection mesh, using techniques similar to those demonstrated in the file. Should still be doable with armatures and constraints, but that would be really fiddly.

Revisions and Commits

rB Blender
AbandonedD6878 Fix assert in modifier evaluation of normal edit.
rBcfdb5b9a8b07 Fix T73941: Custom normals from normal edit modifier ignored by further…

Related Objects

Event Timeline

Nathan Vasil (vasiln) created this task.Feb 17 2020, 8:01 PM
Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.Feb 18 2020, 11:43 AM
Richard Antalik (ISS) added a project: Modifiers.
Philipp Oeser (lichtwerk) added a revision: D6878: Fix assert in modifier evaluation of normal edit..Feb 18 2020, 2:28 PM
Philipp Oeser (lichtwerk) mentioned this in D6878: Fix assert in modifier evaluation of normal edit..
Philipp Oeser (lichtwerk) added subscribers: Bastien Montagne (mont29), Philipp Oeser (lichtwerk).Feb 18 2020, 2:30 PM

This behavior is also inconsistent with the behavior of custom normals set via a weighted normal modifier. When that modifier is used, it seems to affect further modifiers appropriately.

Not sure about this, can you provide an example file where this works?

Opening your file in a Debug build will assert for me:

BLI_assert failed: /blender/blenkernel/intern/modifier.c:971, modwrap_deformVerts(), at '!me || CustomData_has_layer(&me->pdata, CD_NORMAL) == 0'

I assume that same assert was meant in rB090b8c14d2fc: Fix (unreported) assert in modifier evaluation of weighted normals. for the weighted normals modifier?
That commit message also reads like custom normals are not passed around the modifier stack?

Currently modifier stack assumes there are no poly normals data passed
around, so in case a modifier generates such data, it has to clean it up
after usage.

Doing the same as in rB090b8c14d2fc for the Normal Edit modifier will at least get rid of the assert for me... see D6878

@Bastien Montagne (mont29): in the end, this would be nice to support but it is not supported atm., so not a bug?

Nathan Vasil (vasiln) added a comment.Feb 18 2020, 6:30 PM
In T73941#875216, @Philipp Oeser (lichtwerk) wrote:

Not sure about this, can you provide an example file where this works?

Just a quick test to explore the bug, but that's what it looks like to me. Here's a file where I've set custom normals and then use a weighted normal to "repair" those custom normals, and the repair looks like it's being used by the displace modifier:

custnormdisp2.blend531 KBDownload

Bastien Montagne (mont29) added a comment.Feb 18 2020, 6:34 PM

@Philipp Oeser (lichtwerk) poly normals are not custom/loop normals... The latter are for sure expected to be passed around in modifier stack.

Nathan Vasil (vasiln) added a comment.Feb 18 2020, 7:20 PM

I was mistaken about this being also true of data transfer modifier. Custom normals from a data transfer modifier are being read correctly by a displace modifier. For that matter, they're also reading custom normals from a normal edit modified mesh appropriately. In fact, this can be used as a workaround-- make one mesh, likely non-rendering, to get the normal edit modifier, and a second mesh to copy normals via data transfer from the first mesh.

Demonstrated in the following file, where you can see the behavior while moving the camera:

custnormdisp3.blend553 KBDownload

Still true of normal edit modifier however.

Bastien Montagne (mont29) claimed this task.Feb 19 2020, 10:17 AM
Bastien Montagne (mont29) added a project: Modeling.
Bastien Montagne (mont29) changed the subtype of this task from "Report" to "Bug".
Bastien Montagne (mont29) closed this task as Resolved by committing rBcfdb5b9a8b07: Fix T73941: Custom normals from normal edit modifier ignored by further….Feb 19 2020, 12:28 PM
Bastien Montagne (mont29) added a commit: rBcfdb5b9a8b07: Fix T73941: Custom normals from normal edit modifier ignored by further….
Philipp Oeser (lichtwerk) mentioned this in T84664: Crash/Assert with two modifiers that require normals data [e.g. DataTransfer].Jan 13 2021, 12:51 PM