Page MenuHome

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

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.

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.

Event Timeline

Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.Feb 18 2020, 11:43 AM

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?

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:

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

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:

Still true of normal edit modifier however.

Bastien Montagne (mont29) changed the subtype of this task from "Report" to "Bug".