Accessing MeshVertex.normal values is slow after setting MeshVertex.co #105909

New Issue

Thomas Barlow · 2023-03-20T03:41:28+01:00

Thomas Barlow commented

2023-03-20 03:41:28 +01:00

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

Blender Version
Broken: version: 3.3.0, branch: master, commit date: 2022-09-06 15:39, hash: rB0759f671ce1f (also tested and broken in 3.3.4, 3.4, 3.5 and 3.6)
Worked: 3.2.2

Short description of error
Accessing MeshVertex.normal (specifically the values of the normal attribute must be accessed, there's no issue with assigning .normal to a variable) after setting MeshVertex.co is very slow.

It seems to get slower as the number of vertices in the mesh increases.

Note that this slowdown does not occur when accessing the normals through Mesh.vertex_normals or setting vertex position through the "position" attribute.

Exact steps for others to reproduce the error
Run the scripts and look in the system console to observe the drop in performance in 3.3.0 and after.

Attached is a .blend (authored in 3.2.2) that contains a cube subdivided to 24578 vertices along with the scripts plus a more in-depth script that also tests Mesh.vertex_normals and the "position" attribute in newer Blender versions.

Example use case script:

import bpy
offset = 0.01
for v in bpy.context.object.data.vertices:
    v.co += v.normal * offset

Timing test script:
(I get around 1.7μs in 3.2.2 and 300μs in 3.3.0 and newer)

import bpy
import timeit

obj = bpy.context.object
me = obj.data

print()
print()
print(f"{len(me.vertices)} vertices:")

vertex0 = me.vertices[0]

trials = 1000

# Expected to be around 1.7μs with 24578 vertices
t_slow = timeit.timeit("vertex0.co = vertex0.co;vertex0.normal[:]", globals=globals(), number=trials)/trials * 1e6
print(f"Set MeshVertex.co then get MeshVertex.normal values:\n\t{t_slow:f}μs")

# Expected to be around 7e-05μs per vertex with 24578 vertices
print(f"slow/number of vertices: {t_slow/len(me.vertices):.2e}μs")

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 516.94 **Blender Version** Broken: version: 3.3.0, branch: master, commit date: 2022-09-06 15:39, hash: `rB0759f671ce1f` (also tested and broken in 3.3.4, 3.4, 3.5 and 3.6) Worked: 3.2.2 **Short description of error** Accessing `MeshVertex.normal` (specifically the values of the `normal` attribute must be accessed, there's no issue with assigning `.normal` to a variable) after setting `MeshVertex.co` is very slow. It seems to get slower as the number of vertices in the mesh increases. Note that this slowdown does not occur when accessing the normals through `Mesh.vertex_normals` or setting vertex position through the "position" attribute. **Exact steps for others to reproduce the error** Run the scripts and look in the system console to observe the drop in performance in 3.3.0 and after. Attached is a .blend (authored in 3.2.2) that contains a cube subdivided to 24578 vertices along with the scripts plus a more in-depth script that also tests `Mesh.vertex_normals` and the "position" attribute in newer Blender versions. Example use case script: ```py import bpy offset = 0.01 for v in bpy.context.object.data.vertices: v.co += v.normal * offset ``` Timing test script: (I get around 1.7μs in 3.2.2 and 300μs in 3.3.0 and newer) ```py import bpy import timeit obj = bpy.context.object me = obj.data print() print() print(f"{len(me.vertices)} vertices:") vertex0 = me.vertices[0] trials = 1000 # Expected to be around 1.7μs with 24578 vertices t_slow = timeit.timeit("vertex0.co = vertex0.co;vertex0.normal[:]", globals=globals(), number=trials)/trials * 1e6 print(f"Set MeshVertex.co then get MeshVertex.normal values:\n\t{t_slow:f}μs") # Expected to be around 7e-05μs per vertex with 24578 vertices print(f"slow/number of vertices: {t_slow/len(me.vertices):.2e}μs") ```

MeshVertexNormalAccessTest.blend

888 KiB

👀 1

Thomas Barlow added the

labels 2023-03-20 03:41:28 +01:00

Thomas Barlow referenced this issue from a commit

2023-03-20 04:03:34 +01:00

FBX Import: Speed up cycles decal workaround with numpy

Thomas Barlow referenced this issue from blender/blender-addons

2023-03-20 04:09:04 +01:00

FBX Import: Speed up cycles decal workaround with numpy #104497

Germano Cavalcante commented

2023-03-20 15:31:37 +01:00

Note that the Normal of all vertices needs to be recalculated every time you change the position of the vertices.

If it were not recalculated, the values would be outdated and wrong.

That is why it is slow in this case.

If the intention is to reuse the non-recalculated normals, maybe you should copy the array of normals or change the position of the vertices in a way to skip the tag that indicates that the normals need to be recalculated.

So this slowdown is expected and not considered a bug.

Note that the `Normal` of all vertices needs to be recalculated every time you change the position of the vertices. If it were not recalculated, the values would be outdated and wrong. That is why it is slow in this case. If the intention is to reuse the non-recalculated normals, maybe you should copy the array of normals or change the position of the vertices in a way to skip the tag that indicates that the normals need to be recalculated. So this slowdown is expected and not considered a bug.

Germano Cavalcante closed this issue

2023-03-20 15:31:38 +01:00

Blender Bot added

and removed

labels 2023-03-20 15:31:40 +01:00

Thomas Barlow commented

2023-03-20 15:52:25 +01:00

Note that the Normal of all vertices needs to be recalculated every time you change the position of the vertices.

If it were not recalculated, the values would be outdated and wrong.

That is why it is slow in this case.

Then shouldn't these cases also be slow? They all run without significant slowdown.

import bpy
offset = 0.01
me = bpy.context.object.data
for v, n in zip(me.vertices, me.vertex_normals):
    v.co += n.vector * offset

import bpy
offset = 0.01
me = bpy.context.object.data
for p, v in zip(me.attributes["position"].data, me.vertices):
    p.vector += v.normal * offset

import bpy
offset = 0.01
me = bpy.context.object.data
for p, n in zip(me.attributes["position"].data, me.vertex_normals):
    p.vector += n.vector * offset

> Note that the `Normal` of all vertices needs to be recalculated every time you change the position of the vertices. > > If it were not recalculated, the values would be outdated and wrong. > > That is why it is slow in this case. Then shouldn't these cases also be slow? They all run without significant slowdown. ``` import bpy offset = 0.01 me = bpy.context.object.data for v, n in zip(me.vertices, me.vertex_normals): v.co += n.vector * offset ``` ``` import bpy offset = 0.01 me = bpy.context.object.data for p, v in zip(me.attributes["position"].data, me.vertices): p.vector += v.normal * offset ``` ``` import bpy offset = 0.01 me = bpy.context.object.data for p, n in zip(me.attributes["position"].data, me.vertex_normals): p.vector += n.vector * offset ```

Germano Cavalcante commented

2023-03-20 15:59:39 +01:00

If you prefer, you can check when the functions BKE_mesh_tag_positions_changedand BKE_mesh_vert_normals_ensure are called. (I'm not sure off the top of my head if these cases can create some kind of copy)

If you prefer, you can check when the functions `BKE_mesh_tag_positions_changed`and `BKE_mesh_vert_normals_ensure` are called. (I'm not sure off the top of my head if these cases can create some kind of copy)

Thomas Barlow commented

2023-03-20 16:27:07 +01:00

Ok, yes, only the example in the issue description is recalculating normals while iterating.

In 3.2, the normals were not recalculated while iterating with the example in the issue description and I couldn't see anything relating to this change in the 3.3 release notes.

Ok, yes, only the example in the issue description is recalculating normals while iterating. ![image](/attachments/5440c31a-8722-4579-a311-f6e6393679ae) ![image](/attachments/3757c59b-a71c-4c33-9942-c0e0cdd9fdd0) In 3.2, the normals were not recalculated while iterating with the example in the issue description and I couldn't see anything relating to this change in the 3.3 release notes. ![image](/attachments/ad1b9adf-f0a5-4ff6-bad7-8d9588056926)

image.png

40 KiB

image.png

72 KiB

image.png

11 KiB

Germano Cavalcante commented

2023-03-20 16:43:32 +01:00

The way vertex normals are stored changed a while ago. See d9c6ceb3b88b6db87490b08e0089f9a18e6c52d6

Perhaps some related things had to change as well.

Or this could have been a bug fix.

The way vertex normals are stored changed a while ago. See d9c6ceb3b88b6db87490b08e0089f9a18e6c52d6 Perhaps some related things had to change as well. Or this could have been a bug fix.

Thomas Barlow referenced this issue from a commit

2023-03-22 05:37:08 +01:00

FBX Import: Speed up cycles decal workaround with numpy

Bastien Montagne referenced this issue from a commit

2023-04-03 14:41:48 +02:00

FBX Import: Speed up cycles decal workaround with numpy

Sign in to join this conversation.