Regression: Copy of eval mesh may keep shape keys #109327

New Issue

Thomas Barlow · 2023-06-24T18:25:10+02:00

Thomas Barlow commented

2023-06-24 18:25:10 +02: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 531.41

Blender Version
Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-06-19 17:26, hash: cedec09d0594
Worked: sort of 2.79 (the API was a bit different). And in 2.90.1, only the first buggy scenario (see below) is present

Short description of error
Calling Object.to_mesh() on an evaluated mesh keeps the shape keys in some circumstances, even though the shape keys and modifiers have been applied to the mesh.

There are two buggy scenarios this can create:

A mesh whereby the mesh vertex positions do not match its reference ('Basis') shape key positions. This is a fairly common unusual state (there are a number other ways to get into this state) which causes issues with creating new shape keys with from_mix=False and exporting with most exporters that support exporting shape keys (#98890).
A mesh whereby the number of mesh vertices does not match the number of shape key 'vertices'/data. This is a particularly buggy state that should never happen. Notably, this does not occur in 2.90.1 and earlier, and from 2.91.0 to 3.3.x it also happens to meshes created by Object.data.copy().

In both cases, simply removing all the shape keys will restore the meshes to their expected states because both the shape keys and modifiers have been applied to the mesh vertices as expected.

It's not clear which of Object.to_mesh() or Mesh.copy() is at fault for not removing the shape keys.

The API in 2.79 is a little different to 2.80+, since there is no depsgraph, you choose with the function arguments whether or not to apply modifiers:
When using apply_modifiers=True, the new mesh has no shape keys as expected.
When using apply_modifiers=False, the new mesh retains its shape keys as expected.
Additionally, in 2.79, Object.to_mesh() creates a new Mesh data-block in bpy.data.meshes rather than creating a temporary Mesh owned by the Object.

Exact steps for others to reproduce the error
Scenario 1 (mesh vertex positions do not match reference shape key positions)

Using the attached .blend:

Open the attached .blend
Run the script in the Text Editor
Select one of the magenta meshes
Set the value of the shape keys to 0.0
Observe that the state of the mesh with all shape keys set to 0.0 appears to be the original mesh with all shape keys set to 0.0
Remove all the shape keys
Observe that the state of the mesh changes to the appearance of the original mesh with its shape keys applied

Step-by-step:

Create a mesh Object
Add a shape key (other than the 'Basis')
Enter Edit Mode
Modify the shape key so that it noticeably moves the mesh
Exit Edit Mode
Change the Value of the shape key to 1.0
Run in the Python Console:
1. depsgraph = C.evaluated_depsgraph_get()
2. obj_eval = C.object.evaluated_get(depsgraph)
3. temp_mesh = obj_eval.to_mesh(preserve_all_data_layers=True, depsgraph=depsgraph)
4. new_mesh = temp_mesh.copy()
5. C.object.data = new_mesh
Observe that the new mesh has shape keys
Set the value of the shape keys to 0.0
Observe that the state of the mesh with all shape keys set to 0.0 appears to be the original mesh with all shape keys set to 0.0
Remove all the shape keys
Observe that the state of the mesh changes to the appearance of the original mesh with its shape keys applied

Scenario 2 (number of mesh vertices does not match number of shape key 'vertices'/data)
Using the attached .blend:

Open the attached .blend
Run the script in the Text Editor
Select one of the black meshes
Add a new shape key
Change the Value of the new shape key
Observe the mesh going crazy/exploding as the Value changes
Remove all the shape keys
Observe that the state of the mesh changes to the appearance of the original mesh with its shape keys and modifiers applied

Step-by-step:

Create a mesh Object
Add a shape key (other than the 'Basis')
Enter Edit Mode
Modify the shape key so that it noticeably moves the mesh
Exit Edit Mode
Change the Value of the shape key to 1.0
Add an Array modifier with default settings to the Object
Run in the Python Console:
1. depsgraph = C.evaluated_depsgraph_get()
2. obj_eval = C.object.evaluated_get(depsgraph)
3. temp_mesh = obj_eval.to_mesh(preserve_all_data_layers=False, depsgraph=depsgraph) # Note: False this time
4. new_mesh = temp_mesh.copy()
5. C.object.data = new_mesh
Remove the Array modifier from the Object to avoid confusion
Observe that the new mesh has shape keys
Add a new shape key
Change the Value of the new shape key
Observe the mesh going crazy/exploding as the Value changes
Remove all the shape keys
Observe that the state of the mesh changes to the appearance of the original mesh with its shape keys and modifiers applied

Attached is a .blend (authored in 2.80) that has a script and three Objects that go over different cases (has modifiers/no modifiers/has modifiers but they're disabled) or creating meshes from evaluated Objects with Object.to_mesh as well as comparing the behaviour of the similar BlendDataMeshes.new_from_object function and Mesh.copy()

These are the results of running the script in the attached .blend in 4.0.0a:

**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 531.41 **Blender Version** Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-06-19 17:26, hash: `cedec09d0594` Worked: sort of 2.79 (the API was a bit different). And in 2.90.1, only the first buggy scenario (see below) is present **Short description of error** Calling `Object.to_mesh()` on an evaluated mesh keeps the shape keys in some circumstances, even though the shape keys and modifiers have been applied to the mesh. There are two buggy scenarios this can create: 1. A mesh whereby the mesh vertex positions do not match its reference ('Basis') shape key positions. This is a fairly common unusual state (there are a number other ways to get into this state) which causes issues with creating new shape keys with `from_mix=False` and exporting with most exporters that support exporting shape keys (#98890). 2. A mesh whereby the number of mesh vertices does not match the number of shape key 'vertices'/data. This is a particularly buggy state that should never happen. Notably, this does not occur in 2.90.1 and earlier, and from 2.91.0 to 3.3.x it also happens to meshes created by `Object.data.copy()`. In both cases, simply removing all the shape keys will restore the meshes to their expected states because both the shape keys and modifiers have been applied to the mesh vertices as expected. It's not clear which of `Object.to_mesh()` or `Mesh.copy()` is at fault for not removing the shape keys. The API in 2.79 is a little different to 2.80+, since there is no depsgraph, you choose with the function arguments whether or not to apply modifiers: When using apply_modifiers=True, the new mesh has no shape keys as expected. When using apply_modifiers=False, the new mesh retains its shape keys as expected. Additionally, in 2.79, `Object.to_mesh()` creates a new Mesh data-block in bpy.data.meshes rather than creating a temporary Mesh owned by the Object. **Exact steps for others to reproduce the error** Scenario 1 (mesh vertex positions do not match reference shape key positions) Using the attached .blend: 1. Open the attached .blend 1. Run the script in the Text Editor 1. Select one of the magenta meshes 1. Set the value of the shape keys to 0.0 1. Observe that the state of the mesh with all shape keys set to 0.0 appears to be the original mesh with all shape keys set to 0.0 1. Remove all the shape keys 1. Observe that the state of the mesh changes to the appearance of the original mesh with its shape keys applied Step-by-step: 1. Create a mesh Object 1. Add a shape key (other than the 'Basis') 1. Enter Edit Mode 1. Modify the shape key so that it noticeably moves the mesh 1. Exit Edit Mode 1. Change the Value of the shape key to 1.0 1. Run in the Python Console: 1. `depsgraph = C.evaluated_depsgraph_get()` 1. `obj_eval = C.object.evaluated_get(depsgraph)` 1. `temp_mesh = obj_eval.to_mesh(preserve_all_data_layers=True, depsgraph=depsgraph)` 1. `new_mesh = temp_mesh.copy()` 1. `C.object.data = new_mesh` 1. Observe that the new mesh has shape keys 1. Set the value of the shape keys to 0.0 1. Observe that the state of the mesh with all shape keys set to 0.0 appears to be the original mesh with all shape keys set to 0.0 1. Remove all the shape keys 1. Observe that the state of the mesh changes to the appearance of the original mesh with its shape keys applied Scenario 2 (number of mesh vertices does not match number of shape key 'vertices'/data) Using the attached .blend: 1. Open the attached .blend 1. Run the script in the Text Editor 1. Select one of the black meshes 1. Add a new shape key 1. Change the Value of the new shape key 1. Observe the mesh going crazy/exploding as the Value changes 1. Remove all the shape keys 1. Observe that the state of the mesh changes to the appearance of the original mesh with its shape keys and modifiers applied Step-by-step: 1. Create a mesh Object 1. Add a shape key (other than the 'Basis') 1. Enter Edit Mode 1. Modify the shape key so that it noticeably moves the mesh 1. Exit Edit Mode 1. Change the Value of the shape key to 1.0 1. Add an Array modifier with default settings to the Object 1. Run in the Python Console: 1. `depsgraph = C.evaluated_depsgraph_get()` 1. `obj_eval = C.object.evaluated_get(depsgraph)` 1. `temp_mesh = obj_eval.to_mesh(preserve_all_data_layers=False, depsgraph=depsgraph)` # Note: False this time 1. `new_mesh = temp_mesh.copy()` 1. `C.object.data = new_mesh` 1. Remove the Array modifier from the Object to avoid confusion 1. Observe that the new mesh has shape keys 1. Add a new shape key 1. Change the Value of the new shape key 1. Observe the mesh going crazy/exploding as the Value changes 1. Remove all the shape keys 1. Observe that the state of the mesh changes to the appearance of the original mesh with its shape keys and modifiers applied Attached is a .blend (authored in 2.80) that has a script and three Objects that go over different cases (has modifiers/no modifiers/has modifiers but they're disabled) or creating meshes from evaluated Objects with `Object.to_mesh` as well as comparing the behaviour of the similar `BlendDataMeshes.new_from_object` function and `Mesh.copy()` These are the results of running the script in the attached .blend in 4.0.0a: ![image](/attachments/6af21126-1627-4248-bd35-d6e7685d86df)

image.png

612 KiB

(2.80)to_mesh_and_new_from_object_evaluated_tests.blend

123 KiB

👀 2

Thomas Barlow added the

labels 2023-06-24 18:25:11 +02:00

Thomas Barlow referenced this issue

2023-06-24 18:26:43 +02:00

Shape keys missing from `bpy.data.meshes.new_from_object()` even when the mesh Object is not evaluated #109313

Iliya Katushenock changed title from ~~`Object.to_mesh().copy()` may keep shape keys of meshes created from evaluated Objects~~ to Regression: Copy of eval mesh may keep shape keys

2023-06-25 01:34:05 +02:00

Iliya Katushenock added the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Regression: Copy of eval mesh may keep shape keys #109327