Stateful behavior with ID.evaluated_get(..) and Object.to_mesh(preserve_all_data_layers=True, ..) #79965

New Issue

Daniel Bauer · 2020-08-20T20:12:22+02:00

Daniel Bauer commented

2020-08-20 20:12:22 +02:00

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: 83c78529b9, 2.91.0 Alpha, branch: master, commit date: 2020-08-19 22:55, hash: 940b239ad4
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
statefulBehaviour.blend

**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: `83c78529b9`, 2.91.0 Alpha, branch: master, commit date: 2020-08-19 22:55, hash: `940b239ad4` 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](https://docs.blender.org/api/current/bpy.types.Object.html#bpy.types.Object.to_mesh) 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 [statefulBehaviour.blend](https://archive.blender.org/developer/F8797988/statefulBehaviour.blend)

Daniel Bauer commented

2020-08-20 20:12:22 +02:00

Added subscriber: @skatbude

Jonas A. L. Andersen commented

2020-08-24 01:40:10 +02:00

Added subscriber: @stjerneidioten

Jonas A. L. Andersen commented

2020-08-24 01:40:10 +02:00

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.

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 commented

2020-09-15 10:08:15 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-09-15 10:08:15 +02:00

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

Philipp Oeser commented

2020-09-15 10:08:15 +02:00

Can confirm, will have a quick look.

Philipp Oeser commented

2020-09-15 10:11:56 +02:00

Added subscriber: @Sergey

Philipp Oeser commented

2020-09-15 10:11:56 +02:00

@Sergey: this seems to be your playground:

Mind having a look (looks like a bug to me)?

@Sergey: this seems to be your playground: - 2f7711962a - 963917e1b9 - 72a563cdee Mind having a look (looks like a bug to me)?

Sergey Sharybin commented

2020-09-18 10:41:42 +02:00

Added subscriber: @brecht

Sergey Sharybin commented

2020-09-18 10:41:42 +02:00

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, 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?

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, 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?

Brecht Van Lommel commented

2020-09-18 12:03:51 +02:00

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.

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.

Sergey Sharybin commented

2020-09-18 12:15:25 +02:00

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().

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()`.

Brecht Van Lommel commented

2020-09-18 12:23:56 +02:00

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

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

blender-admin commented

2020-09-18 12:45:59 +02:00

This issue was referenced by 3791dbea1e

This issue was referenced by 3791dbea1e796f96440437333e4318066f26bde2

Sergey Sharybin commented

2020-09-21 12:28:25 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Sergey Sharybin closed this issue

2020-09-21 12:28:25 +02:00

Sergey Sharybin self-assigned this 2020-09-21 12:28:25 +02: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

Stateful behavior with ID.evaluated_get(..) and Object.to_mesh(preserve_all_data_layers=True, ..) #79965