Blender 3.0 splash screen render crash with data transfer modifier and geometry nodes #93090

New Issue

Raimund Klink · 2021-11-15T09:57:19+01:00

Raimund Klink commented

2021-11-15 09:57:19 +01:00

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.49

Blender Version
Broken: version: 3.0.0 Beta, branch: master, commit date: 2021-11-11 18:49, hash: bd734cc441
Worked: I can not answer that.

Short description of error
For some reason Blender crashes if I want to render a second time the same frame.
I am really sorry for the bad bug report but maybe you can give me a hint to pin down the exact issue.

EDIT: It also happens on the CPU. Maybe it is because I try to move the image around while it is building/rendering?
EDIT2: It happens so random. Sometimes on the first frame, sometimes on the 7th frame...
EDIT3: With Blender 3.1 it crashed while opening it for the first time :(

Exact steps for others to reproduce the error

Open the Blender 3.0 splash.
Set to OPTIX
Save

bpy.context.scene.cycles.use_denoising = False
bpy.context.scene.cycles.samples = 1
bpy.context.scene.cycles.use_adaptive_sampling = False 
bpy.context.space_data.show_backdrop = False
bpy.context.scene.render.threads_mode = 'FIXED'
bpy.context.scene.render.threads = 6
bpy.context.scene.cycles.tile_size = 1024

Hit F12
After the Frame finishes render again

blender_system_info.txt

blender_debug_output.txt

Blender-3.0.crash.txt

**System Information** Operating system: Windows-10-10.0.19043-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.49 **Blender Version** Broken: version: 3.0.0 Beta, branch: master, commit date: 2021-11-11 18:49, hash: `bd734cc441` Worked: I can not answer that. **Short description of error** For some reason Blender crashes if I want to render a second time the same frame. I am really sorry for the bad bug report but maybe you can give me a hint to pin down the exact issue. EDIT: It also happens on the CPU. Maybe it is because I try to move the image around while it is building/rendering? EDIT2: It happens so random. Sometimes on the first frame, sometimes on the 7th frame... EDIT3: With Blender 3.1 it crashed while opening it for the first time :( **Exact steps for others to reproduce the error** 1. Open the Blender 3.0 splash. 2. Set to OPTIX 3. Save 4. ``` bpy.context.scene.cycles.use_denoising = False bpy.context.scene.cycles.samples = 1 bpy.context.scene.cycles.use_adaptive_sampling = False bpy.context.space_data.show_backdrop = False bpy.context.scene.render.threads_mode = 'FIXED' bpy.context.scene.render.threads = 6 bpy.context.scene.cycles.tile_size = 1024 ``` 5. Hit F12 6. After the Frame finishes render again [blender_system_info.txt](https://archive.blender.org/developer/F11807705/blender_system_info.txt) [blender_debug_output.txt](https://archive.blender.org/developer/F11807706/blender_debug_output.txt) [Blender-3.0.crash.txt](https://archive.blender.org/developer/F11807709/Blender-3.0.crash.txt)

Raimund Klink commented

2021-11-15 09:57:19 +01:00

Added subscriber: @Raimund58

Raimund Klink changed title from ~~Cycles: Crash if I render a socond frame of the Blender 3.0 splash with OPTIX~~ to Cycles: Crash if I render a second frame of the Blender 3.0 splash with OPTIX/CPU

2021-11-15 10:17:26 +01:00

Brecht Van Lommel commented

2021-11-17 20:14:08 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2021-11-17 20:14:08 +01:00

Cycles is nowhere in this crash backtrace, it seems to be crashing the depsgraph. I see a data transfer modifier and child particles being evaluated.

Unable to reproduce the crash myself so far.

Cycles is nowhere in this crash backtrace, it seems to be crashing the depsgraph. I see a data transfer modifier and child particles being evaluated. Unable to reproduce the crash myself so far.

Raimund Klink commented

2021-11-17 20:39:22 +01:00

@brecht Anything I can do to help pinning this down?

Raimund Klink changed title from ~~Cycles: Crash if I render a second frame of the Blender 3.0 splash with OPTIX/CPU~~ to Blender: Crash if I render a second frame of the Blender 3.0 splash with OPTIX/CPU

2021-11-17 20:40:02 +01:00

Brecht Van Lommel commented

2021-11-22 14:45:42 +01:00

What would help is to try to reproduce this with Eevee, and to simplify the scene as much as possible while still having it crash.

Brecht Van Lommel changed title from ~~Blender: Crash if I render a second frame of the Blender 3.0 splash with OPTIX/CPU~~ to Blender 3.0 splash screen render crash with data transfer modifier and geometry nodes

2021-11-22 17:21:51 +01:00

Brecht Van Lommel commented

2021-11-22 17:21:51 +01:00

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

Brecht Van Lommel commented

2021-11-22 17:26:23 +01:00

Added subscribers: @JacquesLucke, @mont29

Brecht Van Lommel commented

2021-11-22 17:26:23 +01:00

I can reproduce it now with this .blend file from the studio here. Not sure if it's a slightly different .blend or Blender build or other random change. But the stack trace is consistent with this report.

In a data transfer modifier from GEO-bird_body to GEO-bird_wings.feathers, a mesh is expected to have loop normals but does not.

BLI_assert failed: source/blender/blenkernel/intern/data_transfer.c:287, data_transfer_dtdata_type_preprocess(), at 'CustomData_get_layer(&me_src->ldata, CD_NORMAL) != ((void *)0)'

Thread 132 "blender" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff70d0f700 (LWP 735867)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
- 0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
- 1  0x00007ffff6e34859 in __GI_abort () at abort.c:79
- 2  0x0000000017849d62 in _BLI_assert_abort () at /home/brecht/dev/worktree/source/blender/blenlib/intern/BLI_assert.c:61
- 3  0x0000000003f1b9b4 in data_transfer_dtdata_type_preprocess (me_src=0x61c000e4c088, me_dst=0x61c000da1088, dtdata_type=131072, dirty_nors_dst=false) at /home/brecht/dev/worktree/source/blender/blenkernel/intern/data_transfer.c:287
#4  0x0000000003f2142a in BKE_object_data_transfer_ex
    (depsgraph=0x61a000b01c88, scene=0x62300074b508, ob_src=0x61a000bfc488, ob_dst=0x61a000bfe888, me_dst=0x61c000da1088, data_types=131072, use_create=false, map_vert_mode=16777488, map_edge_mode=33554720, map_loop_mode=67111312, map_poly_mode=134218112, space_transform=0x7fff70d0d9d0, auto_transform=false, max_distance=3.40282347e+38, ray_radius=0, islands_handling_precision=0, fromlayers_select=0x612000ca9d7c, tolayers_select=0x612000ca9d8c, mix_mode=0, mix_factor=1, vgroup_name=0x612000ca9da4 "body", invert_vgroup=false, reports=0x7fff70d0d980) at /home/brecht/dev/worktree/source/blender/blenkernel/intern/data_transfer.c:1483
#5  0x000000000566650c in modifyMesh (md=0x612000ca9cc8, ctx=0x7fff70d0dcf0, me_mod=0x61c000da1088) at /home/brecht/dev/worktree/source/blender/modifiers/intern/MOD_datatransfer.c:206
...

The mesh comes from a geometry set, so geometry nodes. For the non-geometry nodes case it relies on a custom data mask to generate the loop normals in mesh_calc_modifier_final_normals, but perhaps there is no such code for geometry nodes.

I can reproduce it now with this .blend file from the studio here. Not sure if it's a slightly different .blend or Blender build or other random change. But the stack trace is consistent with this report. In a data transfer modifier from `GEO-bird_body` to `GEO-bird_wings.feathers`, a mesh is expected to have loop normals but does not. ``` BLI_assert failed: source/blender/blenkernel/intern/data_transfer.c:287, data_transfer_dtdata_type_preprocess(), at 'CustomData_get_layer(&me_src->ldata, CD_NORMAL) != ((void *)0)' Thread 132 "blender" received signal SIGABRT, Aborted. [Switching to Thread 0x7fff70d0f700 (LWP 735867)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt - 0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 - 1 0x00007ffff6e34859 in __GI_abort () at abort.c:79 - 2 0x0000000017849d62 in _BLI_assert_abort () at /home/brecht/dev/worktree/source/blender/blenlib/intern/BLI_assert.c:61 - 3 0x0000000003f1b9b4 in data_transfer_dtdata_type_preprocess (me_src=0x61c000e4c088, me_dst=0x61c000da1088, dtdata_type=131072, dirty_nors_dst=false) at /home/brecht/dev/worktree/source/blender/blenkernel/intern/data_transfer.c:287 #4 0x0000000003f2142a in BKE_object_data_transfer_ex (depsgraph=0x61a000b01c88, scene=0x62300074b508, ob_src=0x61a000bfc488, ob_dst=0x61a000bfe888, me_dst=0x61c000da1088, data_types=131072, use_create=false, map_vert_mode=16777488, map_edge_mode=33554720, map_loop_mode=67111312, map_poly_mode=134218112, space_transform=0x7fff70d0d9d0, auto_transform=false, max_distance=3.40282347e+38, ray_radius=0, islands_handling_precision=0, fromlayers_select=0x612000ca9d7c, tolayers_select=0x612000ca9d8c, mix_mode=0, mix_factor=1, vgroup_name=0x612000ca9da4 "body", invert_vgroup=false, reports=0x7fff70d0d980) at /home/brecht/dev/worktree/source/blender/blenkernel/intern/data_transfer.c:1483 #5 0x000000000566650c in modifyMesh (md=0x612000ca9cc8, ctx=0x7fff70d0dcf0, me_mod=0x61c000da1088) at /home/brecht/dev/worktree/source/blender/modifiers/intern/MOD_datatransfer.c:206 ... ``` The mesh comes from a geometry set, so geometry nodes. For the non-geometry nodes case it relies on a custom data mask to generate the loop normals in `mesh_calc_modifier_final_normals`, but perhaps there is no such code for geometry nodes.

Brecht Van Lommel commented

2021-11-22 17:41:02 +01:00

To be clear, this is the .blend file:
https://cloud.blender.org/p/gallery/617933e9b7b35ce1e1c01066

To be clear, this is the .blend file: https://cloud.blender.org/p/gallery/617933e9b7b35ce1e1c01066

Brecht Van Lommel commented

2021-11-22 18:06:22 +01:00

Potential solutions:

Call mesh_calc_modifier_final_normals for meshes in the geometry set at the end of mesh_calc_modifiers. In principle this is the most performant solution since it allows multithreaded computation of normals on multiple objects. May also improve performance of drawing code, if that is currently computing normals in a single thread (for small enough meshes that parallellization over a single mesh does not help much).
Compute the normals on demand in the data transfer code if they don't exist. Would need some locking to avoid conflicts between threads.
Skip data transfer if no normals are available. Not a proper solution as you would want the normals to be transferred same as when not using geometry nodes.

Potential solutions: * Call `mesh_calc_modifier_final_normals` for meshes in the geometry set at the end of `mesh_calc_modifiers`. In principle this is the most performant solution since it allows multithreaded computation of normals on multiple objects. May also improve performance of drawing code, if that is currently computing normals in a single thread (for small enough meshes that parallellization over a single mesh does not help much). * Compute the normals on demand in the data transfer code if they don't exist. Would need some locking to avoid conflicts between threads. * Skip data transfer if no normals are available. Not a proper solution as you would want the normals to be transferred same as when not using geometry nodes.

Hans Goudey commented

2021-11-22 18:09:04 +01:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2021-11-22 18:09:04 +01:00

This doesn't apply to loop normals, but my patch D12770 deals with similar situations. I've moved face and vertex normal calculation behind locks. I know less about loop normals, but maybe something similar would be useful there.

This doesn't apply to loop normals, but my patch [D12770](https://archive.blender.org/developer/D12770) deals with similar situations. I've moved face and vertex normal calculation behind locks. I know less about loop normals, but maybe something similar would be useful there.

Brecht Van Lommel commented

2021-11-22 18:19:04 +01:00

Disabling the normal transfer modifier on GEO-bird_body.feathers and GEO-bird_wings.feathers stops the crash.

I'll leave this to the geometry nodes team to solve since it's not a rendering issue.

Disabling the normal transfer modifier on `GEO-bird_body.feathers` and `GEO-bird_wings.feathers` stops the crash. I'll leave this to the geometry nodes team to solve since it's not a rendering issue.

Jacques Lucke commented

2021-11-22 18:24:15 +01:00

I think the proper long term solution is a mix of option 1 and 2. We should be able to compute derived mesh data lazily when it is actually needed. This is the default case. However, for improved performance we should compute some derived mesh data eagerly when we know for sure that it will be needed (I see this just as an optimization because it is hard/impossible and brittle to figure out what derived mesh data will be needed later on).

Regarding this bug specifically, I still don't fully understand what is causing it. The geometry_set_final does not seem to contain a mesh or instances that we'd have to iterate over. Still checking...

I think the proper long term solution is a mix of option 1 and 2. We should be able to compute derived mesh data lazily when it is actually needed. This is the default case. However, for improved performance we should compute some derived mesh data eagerly when we know for sure that it will be needed (I see this just as an optimization because it is hard/impossible and brittle to figure out what derived mesh data will be needed later on). Regarding this bug specifically, I still don't fully understand what is causing it. The `geometry_set_final` does not seem to contain a mesh or instances that we'd have to iterate over. Still checking...

Jacques Lucke self-assigned this 2021-11-22 20:41:46 +01:00

blender-admin commented

2021-11-23 09:32:12 +01:00

This issue was referenced by 6987060f70

This issue was referenced by 6987060f7082e77cfc4ead7db3e7c9d6aaf349b1

Jacques Lucke commented

2021-11-23 09:33:16 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2021-11-23 09:33:16 +01: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

Blender 3.0 splash screen render crash with data transfer modifier and geometry nodes #93090