constant crashes when assigning evaluated mesh to obj after recent depsgraph changes #64735

New Issue

MACHIN3 · 2019-05-16T23:58:42+02:00

MACHIN3 commented

2019-05-16 23:58:42 +02:00

System Information
Operating system: Linux-4.13.10-041310-generic-x86_64-with-debian-stretch-sid 64 Bits
Graphics card: GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.67

Blender Version
Broken: version: 2.80 (sub 68), branch: master, commit date: 2019-05-16 18:01, hash: d726d7e462

Short description of error
I'm trying to apply modifiers of an object, but am getting crashes constantly, when assigning the evaluated mesh to the object's data block.

Exact steps for others to reproduce the error

load applying_modifiers_after_the_recent_despgaph_changes.blend
uncommend line 9 and run the script, which assignes the data block of the evaluated object, it should crash
reload and uncomment line 10 this time, which assinged the result of to_mesh(), it should also crash

video demo

**System Information** Operating system: Linux-4.13.10-041310-generic-x86_64-with-debian-stretch-sid 64 Bits Graphics card: GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.67 **Blender Version** Broken: version: 2.80 (sub 68), branch: master, commit date: 2019-05-16 18:01, hash: `d726d7e462` **Short description of error** I'm trying to apply modifiers of an object, but am getting crashes constantly, when assigning the evaluated mesh to the object's data block. **Exact steps for others to reproduce the error** * load [applying_modifiers_after_the_recent_despgaph_changes.blend](https://archive.blender.org/developer/F7041899/applying_modifiers_after_the_recent_despgaph_changes.blend) * uncommend line 9 and run the script, which assignes the data block of the evaluated object, it should crash * reload and uncomment line 10 this time, which assinged the result of to_mesh(), it should also crash [video demo ](https://www.youtube.com/watch?v=ilxd11_TyuU)

MACHIN3 commented

2019-05-16 23:58:42 +02:00

Added subscriber: @MACHIN3

Ryan Guy commented

2019-05-17 04:41:30 +02:00

Added subscriber: @rlguy

Ryan Guy commented

2019-05-17 04:41:30 +02:00

I am also experiencing this issue and am able to reproduce both crashes using the .blend file (Window 10 Home).

MACHIN3 commented

2019-05-17 10:15:53 +02:00

Using active.data = bpy.data.meshes.new_from_object(active_eval)
as mentioend here , seems to work.

Using `active.data = bpy.data.meshes.new_from_object(active_eval)` [as mentioend here ](https://developer.blender.org/rB32d5d127cb49743578e8e1e9882d8a707a4e848e), seems to work.

Brecht Van Lommel commented

2019-05-17 10:19:34 +02:00

Added subscribers: @Sergey, @brecht

Brecht Van Lommel commented

2019-05-17 10:19:34 +02:00

@Sergey, we should have a warning similar to #64731 here I think, when assigning an ID to an ID with LIB_TAG_NO_MAIN not matching.

@Sergey, we should have a warning similar to #64731 here I think, when assigning an ID to an ID with `LIB_TAG_NO_MAIN` not matching.

Sergey Sharybin commented

2019-05-17 10:28:09 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2019-05-17 10:28:09 +02:00

Sergey Sharybin self-assigned this 2019-05-17 10:28:09 +02:00

Sergey Sharybin commented

2019-05-17 10:28:09 +02:00

As the updated documentation of to_mesh() states: the object is the owner of the result of to_mesh(). It is short-living, and can not be referenced by other objects from your file (it can be referenced by a temporary object though).

The proper way of achieving your goal is to put mesh to the main database in the following way: bpy.data.meshes.new_from_object(active_eval). Note, that this will also ensure all other pointers in the mesh are valid form within main database (for example, mesh will not reference materials from dependency graph).

The entire script becomes this:

import bpy

active = bpy.context.active_object

dg = bpy.context.evaluated_depsgraph_get()

active_eval = active.evaluated_get(dg)

active.data = bpy.data.meshes.new_from_object(active_eval)

I've made this more explicit in the RNA documentation and Python examples in 5186cfbea4.

Would be cool to automatically detect unsupported pointers assignment, but that is a bit tricky. Mainly because a lot of scripts are relying on the possibility to temporarily modify objects in weird and wonderful ways. Maybe @brecht can think of some way improving error reporting for such cases without being too intrusive for the existing scripts?

This exact report i wouldn't consider a bug. Just script code requires a bit tweaking, and after that it is guaranteed to be non-crashing (before the dependency graph changes this script wouldn't immediately, but will create a wrong and corrupted .blend file, due to materials and animation pointing to the IDs from the dependency graph).

Thanks for the report, closing!

As the updated documentation of to_mesh() states: the object is the owner of the result of `to_mesh()`. It is short-living, and can not be referenced by other objects from your file (it can be referenced by a temporary object though). The proper way of achieving your goal is to put mesh to the main database in the following way: ` bpy.data.meshes.new_from_object(active_eval)`. Note, that this will also ensure all other pointers in the mesh are valid form within main database (for example, mesh will not reference materials from dependency graph). The entire script becomes this: ``` import bpy active = bpy.context.active_object dg = bpy.context.evaluated_depsgraph_get() active_eval = active.evaluated_get(dg) active.data = bpy.data.meshes.new_from_object(active_eval) ``` I've made this more explicit in the RNA documentation and Python examples in 5186cfbea4. Would be cool to automatically detect unsupported pointers assignment, but that is a bit tricky. Mainly because a lot of scripts are relying on the possibility to temporarily modify objects in weird and wonderful ways. Maybe @brecht can think of some way improving error reporting for such cases without being too intrusive for the existing scripts? This exact report i wouldn't consider a bug. Just script code requires a bit tweaking, and after that it is guaranteed to be non-crashing (before the dependency graph changes this script wouldn't immediately, but will create a wrong and corrupted .blend file, due to materials and animation pointing to the IDs from the dependency graph). Thanks for the report, closing!

Sergey Sharybin commented

2019-05-17 10:30:27 +02:00

In #64735#681254, @brecht wrote:
@Sergey, we should have a warning similar to #64731 here I think, when assigning an ID to an ID with LIB_TAG_NO_MAIN not matching.

Unfortunately, we can not do this easily. There are scripts which are creating temporary objects with mesh pointing to a result of evaluated to_mesh(). This is all fine if the object is removed afterwards.

If the assignment is based on LIB_TAG_NO_MAIN then we would need some way to create out-of-main objects as well.

> In #64735#681254, @brecht wrote: > @Sergey, we should have a warning similar to #64731 here I think, when assigning an ID to an ID with `LIB_TAG_NO_MAIN` not matching. Unfortunately, we can not do this easily. There are scripts which are creating temporary objects with mesh pointing to a result of evaluated `to_mesh()`. This is all fine if the object is removed afterwards. If the assignment is based on `LIB_TAG_NO_MAIN` then we would need some way to create out-of-main objects as well.

Brecht Van Lommel commented

2019-05-17 10:47:55 +02:00

If scripts need to do that, I think they should be using bpy.data.meshes.new_from_object() instead?

If scripts need to do that, I think they should be using `bpy.data.meshes.new_from_object()` instead?

Sergey Sharybin commented

2019-05-17 11:10:42 +02:00

That isn't strictly speaking the same due to material, animation, shape keys pointers. Not sure how much problematic it is in the reality though.

Sergey Sharybin commented

2019-05-17 14:07:04 +02:00

Note: started the patch which is aimed to help preventing unsupported configurations: D4884.

Note: started the patch which is aimed to help preventing unsupported configurations: [D4884](https://archive.blender.org/developer/D4884).

MACHIN3 commented

2019-05-17 18:20:41 +02:00

@Sergey Thanks, you've been very helpful. How would you apply mods now, while keeping the materials assigned as they are by mods like bevel for instance. See apply_mods_keep_materials.blend

Is the only solution to first use to_mesh() to check the material indices for each face, and then reapply them accordingly on the mesh created from new_from_object()? Is this what the Apply button in the mod panel does?

@Sergey Thanks, you've been very helpful. How would you apply mods now, while keeping the materials assigned as they are by mods like bevel for instance. See [apply_mods_keep_materials.blend](https://archive.blender.org/developer/F7043683/apply_mods_keep_materials.blend) Is the only solution to first use to_mesh() to check the material indices for each face, and then reapply them accordingly on the mesh created from new_from_object()? Is this what the Apply button in the mod panel does?

Sergey Sharybin commented

2019-05-17 18:30:35 +02:00

@MACHIN3, thanks for the file, saved some time verifying the fix. Committed at 848967c21d.

P.S. Maybe next time open a new report. Much easier to keep a history of changes and references to reports.

@MACHIN3, thanks for the file, saved some time verifying the fix. Committed at 848967c21d. P.S. Maybe next time open a new report. Much easier to keep a history of changes and references to reports.

MACHIN3 commented

2019-05-17 18:44:37 +02:00

Awesome, wasn't sure if it's a bug or intended behavior. And while at it. It also doesn't/didn't preserve use_auto_smooth and I assume auto_smooth_angle

Awesome, wasn't sure if it's a bug or intended behavior. And while at it. It also doesn't/didn't preserve `use_auto_smooth` and I assume `auto_smooth_angle`

Sergey Sharybin commented

2019-05-17 18:48:44 +02:00

Autosmooth should also be preserved now. Is it still broken for you?

MACHIN3 commented

2019-05-17 18:50:38 +02:00

I'm still on the old build. I assume not, if this is the fix: mesh_in_bmain->smoothresh = mesh->smoothresh;

I'm still on the old build. I assume not, if this is the fix: `mesh_in_bmain->smoothresh = mesh->smoothresh;`

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

constant crashes when assigning evaluated mesh to obj after recent depsgraph changes #64735