Loop normals display not working if have custom split normals #57620

New Issue

Howard Trickey · 2018-11-05T02:25:20+01:00

Howard Trickey commented

2018-11-05 02:25:20 +01:00

System Information
MacOS 10.14. Intel HD Graphics 530 1536 MB

Blender Version
Broken: 2.8 hash 642fe9e0f2 Nov 4

Short description of error
If one sets up custom normals on a mesh and then modifies them, and enables loop normals in the overlay options, then the displayed normals stay at whatever the loop normals would be just for the face that the loop is for.

Exact steps for others to reproduce the error
This blend
cubecustomnorm.blend
was made by setting autosmooth on the cube, making the top edges sharp, setting the object to smooth shading, then using alt-L to enter normal editing mode, then using m (point at mouse) and moving the mouse a bit, and then left clicking. The matcap shows that normals are affected when doing this.

The commit 478899dee7 appears to have added loop normal display support so I'll assign to fclem but maybe the problem is due to a number of TODOs in draw_cache_impl_mesh.c about "real loop normals".

**System Information** MacOS 10.14. Intel HD Graphics 530 1536 MB **Blender Version** Broken: 2.8 hash 642fe9e0f2a95 Nov 4 **Short description of error** If one sets up custom normals on a mesh and then modifies them, and enables loop normals in the overlay options, then the displayed normals stay at whatever the loop normals would be just for the face that the loop is for. **Exact steps for others to reproduce the error** This blend [cubecustomnorm.blend](https://archive.blender.org/developer/F5377734/cubecustomnorm.blend) was made by setting autosmooth on the cube, making the top edges sharp, setting the object to smooth shading, then using alt-L to enter normal editing mode, then using m (point at mouse) and moving the mouse a bit, and then left clicking. The matcap shows that normals are affected when doing this. The commit 478899dee771 appears to have added loop normal display support so I'll assign to fclem but maybe the problem is due to a number of TODOs in draw_cache_impl_mesh.c about "real loop normals".

Howard Trickey commented

2018-11-05 02:25:20 +01:00

Added subscriber: @howardt

blender-admin commented

2018-11-05 02:25:20 +01:00

#57658 was marked as duplicate of this issue

Clément Foucault was assigned by Howard Trickey

2018-11-05 02:26:53 +01:00

Howard Trickey commented

2018-11-05 02:26:53 +01:00

I'm not sure if this should be assigned to Clement, Campbell, or someone else. Also not sure if this is a bug that is intended to be fixed before the beta.

Clément Foucault commented

2018-11-05 15:45:11 +01:00

Added subscriber: @ideasman42

Clément Foucault commented

2018-11-05 15:45:11 +01:00

Seems like a TODO in add_overlay_tri.

/* TODO real loop normal */

I might have a look if @ideasman42 is too busy.

Seems like a TODO in add_overlay_tri. ``` /* TODO real loop normal */ ``` I might have a look if @ideasman42 is too busy.

Philipp Oeser commented

2018-11-07 10:36:10 +01:00

Added subscribers: @skywalger, @rboxman

Jan Javůrek commented

2018-11-07 11:32:50 +01:00

the overlay also displays bad amount of normals, in 2.79 it works as it should by my opinion:
2.79
2.8

the overlay also displays bad amount of normals, in 2.79 it works as it should by my opinion: ![obrazek.png](https://archive.blender.org/developer/F5413898/obrazek.png) 2.79 ![obrazek.png](https://archive.blender.org/developer/F5413946/obrazek.png) 2.8

blender-admin commented

2018-11-16 00:45:13 +01:00

This issue was referenced by a915da221f

This issue was referenced by a915da221fa838dbdb846120c9ef8c0b381c3dfe

Clément Foucault commented

2018-11-16 00:45:43 +01:00

Changed status from 'Open' to: 'Resolved'

Clément Foucault closed this issue

2018-11-16 00:45:43 +01:00

Howard Trickey commented

2018-12-03 15:02:01 +01:00

Changed status from 'Resolved' to: 'Open'

Howard Trickey reopened this issue

2018-12-03 15:02:01 +01:00

Howard Trickey commented

2018-12-03 15:02:01 +01:00

Campbell, your recent commit ff3601b9 seems to have broken some of the code that was written to fix this, or maybe just broke the code that fetches and uses custom normals in shading. Now when autosmooth is on it doesn't seem like the workbench display uses custom normals at all (e.g., trying to modify them with the mesh -> normals -> point normals to target command, using m for mouse -- nothing happens now).

Can you have a look please?

Campbell, your recent commit ff3601b9 seems to have broken some of the code that was written to fix this, or maybe just broke the code that fetches and uses custom normals in shading. Now when autosmooth is on it doesn't seem like the workbench display uses custom normals at all (e.g., trying to modify them with the mesh -> normals -> point normals to target command, using m for mouse -- nothing happens now). Can you have a look please?

Clément Foucault was unassigned by Howard Trickey

2018-12-03 15:03:25 +01:00

Campbell Barton was assigned by Howard Trickey

2018-12-03 15:03:25 +01:00

Howard Trickey commented

2018-12-03 15:03:25 +01:00

Added subscriber: @fclem

Howard Trickey commented

2018-12-04 14:50:49 +01:00

I put this in my draw_cache_impl_mesh.c so that I could turn on #define of USE_BM_MAPPED_LOOPNORMAL and get it to use custom loop normals properly in display.

		const int l_orig = rdata->mapped.l_origindex ? rdata->mapped.l_origindex[mlt->tri- [x]] : mlt->tri[i];

but I'm pretty sure this is not the right fix, else you likely would have done this in the first place.
Is the issue that mlt->tri- [ ] is just wrong if there's a modifier that sets things on the CD_ORIGINDEX layer?

People will likely start filing bugs about "custom split normals don't work at all" if we don't do something to use the CD_CUSTOMLOOPNORMAL layer in shading.

I put this in my draw_cache_impl_mesh.c so that I could turn on #define of USE_BM_MAPPED_LOOPNORMAL and get it to use custom loop normals properly in display. const int l_orig = rdata->mapped.l_origindex ? rdata->mapped.l_origindex[mlt->tri- [x]] : mlt->tri[i]; but I'm pretty sure this is not the right fix, else you likely would have done this in the first place. Is the issue that mlt->tri- [ ] is just wrong if there's a modifier that sets things on the CD_ORIGINDEX layer? People will likely start filing bugs about "custom split normals don't work at all" if we don't do something to use the CD_CUSTOMLOOPNORMAL layer in shading.

Alexander Gavrilov commented

2018-12-04 14:58:24 +01:00

Added subscriber: @angavrilov

Alexander Gavrilov commented

2018-12-04 14:58:24 +01:00

No idea about bmesh stuff, but with regular meshes the ORIGINDEX layer doesn't exist if the object only has deform modifiers and thus the topology is unchanged from base, and you have to account for that.

blender-admin commented

2018-12-04 17:52:30 +01:00

This issue was referenced by 34b73cb11c

This issue was referenced by 34b73cb11ce50f2afefabec32aadb9a853eec177

Campbell Barton was unassigned by Alexander Gavrilov

2018-12-04 18:23:01 +01:00

Alexander Gavrilov self-assigned this 2018-12-04 18:23:01 +01:00

Alexander Gavrilov commented

2018-12-04 18:23:18 +01:00

Changed status from 'Open' to: 'Resolved'

Alexander Gavrilov closed this issue

2018-12-04 18:23:18 +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

Loop normals display not working if have custom split normals #57620