Page MenuHome

Stateful behavior with ID.evaluated_get(..) and Object.to_mesh(preserve_all_data_layers=True, ..)
Closed, ResolvedPublicBUG

Description

Note
This issue has already been reported (https://developer.blender.org/T72581), but the task was closed due to missing information.
My attempt to provide the missing data didn't receive any attention, hence I am opening a new task now.

System Information
Operating system: Linux-5.8.0-sparky-amd64-x86_64-with-glibc2.29 64 Bits
Graphics card: Mesa DRI Intel(R) HD Graphics 3000 (SNB GT2) Intel Open Source Technology Center 3.3 (Core Profile) Mesa 20.1.5

Blender Version
Tested by original reporter: 2.80-2.82a2
Broken: version: 2.83.2, 2.83.3, 2.83.4, 2.90.0 Beta, branch: master, commit date: 2020-08-19 10:14, hash: rB83c78529b9ef, 2.91.0 Alpha, branch: master, commit date: 2020-08-19 22:55, hash: rB940b239ad473
Worked: -

Short description of error
We can use the following snippet to retrieve an evaluated mesh from an object while preserving all data layers.
This is useful e.g. in exporter scripts.

obj = context.object.evaluated_get(depsgraph)
me = obj.to_mesh(preserve_all_data_layers=True, depsgraph=depsgraph)
me.transform(obj.matrix_world)

foo(me) # do something useful with 'me'

obj.to_mesh_clear()

The problem arises when executing this code several times in a row. In that case the transformation of the mesh will 'stick' and then be applied multiple times.
It feels as if to_mesh_clear() didn't do anything and executing to_mesh(..) a second time would return the same, already transformed, mesh again.
This is contrary to the documentation of to_mesh:

The result is temporary [...]

Exact steps for others to reproduce the error
Open the attached .blend file and follow the instruction on screen (Readme file is included).

The attached file contains a cube that is scaled by factor 2.
A custom Operator uses above code to retrieve the cube's mesh and then transform it by the cubes world matrix.
Next the coordinate of one Vertex is reported to Info.
Expected Result: (2, 2, 2) (modulo sign)
Actual Result: Coordinates double every time the Operator is executed

Event Timeline

I am currently writing an exporter and running into the exact same problem. I have to transform the meshes into a different coordinate system upon export, but the transform gets applied every time you run the exporter, even though I use to_mesh_clear() to clean up as per the documentation.

Currently I have to set preserve_all_data_layers=False for it to work properly, but the problem is now that materials aren't updated properly, if I access them directly through the mesh they still contain deleted nodes from the node tree etc. so I have to use the material.original to get the proper updated material. Which is temporary fix in my case as I only read from the material.

I can provide more documentation/examples if needed. But what is currently uploaded seems sufficient to reproduce the bug.

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Tue, Sep 15, 10:08 AM

Can confirm, will have a quick look.

Temporarily refers to the fact that the Mesh will not be preserved if the "source" (object on which to_mesh was used) is deleted or re-evaluated. Additionally, this mesh can not be assigned to an object which is in the main database, as its lifetime is shorter than the lifetime of the main database.

The result mesh will reference data from the source object to keep memory under control. For example, if there are no modifiers the mesh will reference original vertices array and modifying them will modify the source as well.

@Brecht Van Lommel (brecht), do you think it will be good idea to add an option to the to_mesh() to "de-reference" the result mesh so that it can be modified?

If this was a C++ API, I would mark the return value of to_mesh as const and require the API user to make a copy. So maybe mesh.copy() can be made to work.

Either way, what's unclear to me who would own the memory of such a copied or de-referenced mesh.

Am I missing something or we don't currently have mesh.copy()?

The memory ownership is indeed an interesting topic. With mesh.copy() the ownership becomes more tricky.
My initial idea was to make it so Mesh calculated by to_mesh() will not use CD_REFERENCE (optionally, for the cases when user intend to edit the mesh). The owner of the CD layers then the mesh itself, which will be freed by to_mesh_clear().

.copy() is a available for all datablocks as far as I know.

But I did not realize CD_REFERENCE was the issue.

Referenced data layers are not supposed to ever be edited. mesh.transform() should call CustomData_duplicate_referenced_layer before modifying the data layer.