Page MenuHome

constant crashes when assigning evaluated mesh to obj after recent depsgraph changes
Closed, ArchivedPublic


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: rBd726d7e462d9

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



Event Timeline

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

MACHIN3 (MACHIN3) added a comment.EditedMay 17 2019, 10:15 AM

Using =
as mentioend here, seems to work.

@Sergey Sharybin (sergey), we should have a warning similar to T64731 here I think, when assigning an ID to an ID with LIB_TAG_NO_MAIN not matching.

Sergey Sharybin (sergey) closed this task as Archived.May 17 2019, 10:28 AM
Sergey Sharybin (sergey) claimed this task.

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: 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) =

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

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 Van Lommel (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 (sergey), we should have a warning similar to T64731 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.

If scripts need to do that, I think they should be using instead?

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.

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

MACHIN3 (MACHIN3) added a comment.EditedMay 17 2019, 6:20 PM

@Sergey Sharybin (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

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?

@MACHIN3 (MACHIN3), thanks for the file, saved some time verifying the fix. Committed at rB848967c21d0.

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

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

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

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