Custom normals from normal edit modifier ignored by further modifiers #73941

New Issue

Nathan Vasil · 2020-02-17T20:01:20+01:00

Nathan Vasil commented

2020-02-17 20:01:20 +01:00

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: 77d23b0bd7
Also broken: Blender 2.83 alpha hash f6d5a95513

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.blend

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.

**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: `77d23b0bd7` 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.blend](https://archive.blender.org/developer/F8345578/custnormdisp1.blend) 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.

Nathan Vasil commented

2020-02-17 20:01:20 +01:00

Added subscriber: @vasiln

Richard Antalik commented

2020-02-18 11:43:51 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2020-02-18 14:30:16 +01:00

Added subscribers: @mont29, @lichtwerk

Philipp Oeser commented

2020-02-18 14:30:16 +01:00

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 090b8c14d2 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 090b8c14d2 for the Normal Edit modifier will at least get rid of the assert for me... see D6878

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

> 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 090b8c14d2 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 090b8c14d2 for the Normal Edit modifier will at least get rid of the assert for me... see [D6878](https://archive.blender.org/developer/D6878) @mont29: in the end, this would be nice to support but it is not supported atm., so not a bug?

Nathan Vasil commented

2020-02-18 18:30:08 +01:00

In #73941#875216, @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.blend

> In #73941#875216, @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.blend](https://archive.blender.org/developer/F8348380/custnormdisp2.blend)

Bastien Montagne commented

2020-02-18 18:34:21 +01:00

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

Nathan Vasil commented

2020-02-18 19:20:48 +01:00

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.blend

Still true of normal edit modifier however.

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.blend](https://archive.blender.org/developer/F8348463/custnormdisp3.blend) Still true of normal edit modifier however.

Bastien Montagne self-assigned this 2020-02-19 10:17:08 +01:00

blender-admin commented

2020-02-19 12:22:58 +01:00

This issue was referenced by cfdb5b9a8b

This issue was referenced by cfdb5b9a8b07bcea1c490e52570eb129c7f3ad43

Bastien Montagne commented

2020-02-19 12:28:57 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Bastien Montagne closed this issue

2020-02-19 12:28:57 +01:00

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 from normal edit modifier ignored by further modifiers #73941