Alembic Import is really Flaky in 2.78a #50194

New Issue

Ajlan Altug · 2016-12-07T17:53:46+01:00

Ajlan Altug commented

2016-12-07 17:53:46 +01:00

System Information
Win7 SP1 Asus ROG II

Short description of error
It was noted in the release notes that this is the initial implementation of Alembic I/O; nevertheless, I'm getting considerable crashes and flaky behavior with it, especially in the project that I'm working on right now where I need to deal with trees from Speedtree in .abc format that have growth animation on them. I found out that Speedtree exports Alembic files in HDF5 format whereas at this stage Blender is only able to deal with the Ogawa format. I can import these cache files into Blender, yet I'm having serious issues with them once after I did so. First off, Blender consistently crashes after these operations:

1- Adjusting Object Data Attributes such as "Double Sided" and/or "Auto Smoothing"
2- Adding a modifier after the Alembic Modifier.
3- Even if it doesn't crash right away, Blender is sure to crash after you hit Undo.
4- Linking Alembic applied objects into other scenes causes problems such as cache files not being read and/or animated (on the original file itself) cache Sequence not being recognized. As mentioned above, Blender crashes in this case just as soon as you do something with the linked file or hit CTRL+Z.
5- The crashes occur in the form Blender popping out of existance rather than a classical appcrash.

Exact steps for others to reproduce the error
1- Import the attached alembic file (BUSH_01_BL.abc)
2- Add a modifier after the Mesh Sequence cacher modifier, and scrub the timeline and see Blender go pop.
3- Or, play with the Object Data parameters such as Auto Smoothing and etc.
4- Lastly save the file that has the alembic cache in it and try linking it to an empty scene and say, adding another copy of the linked object from add>group instance>...

**System Information** Win7 SP1 Asus ROG II **Short description of error** It was noted in the release notes that this is the initial implementation of Alembic I/O; nevertheless, I'm getting considerable crashes and flaky behavior with it, especially in the project that I'm working on right now where I need to deal with trees from Speedtree in .abc format that have growth animation on them. I found out that Speedtree exports Alembic files in HDF5 format whereas at this stage Blender is only able to deal with the Ogawa format. I can import these cache files into Blender, yet I'm having serious issues with them once after I did so. First off, Blender consistently crashes after these operations: 1- Adjusting Object Data Attributes such as "Double Sided" and/or "Auto Smoothing" 2- Adding a modifier after the Alembic Modifier. 3- Even if it doesn't crash right away, Blender is sure to crash after you hit Undo. 4- Linking Alembic applied objects into other scenes causes problems such as cache files not being read and/or animated (on the original file itself) cache Sequence not being recognized. As mentioned above, Blender crashes in this case just as soon as you do something with the linked file or hit CTRL+Z. 5- The crashes occur in the form Blender popping out of existance rather than a classical appcrash. **Exact steps for others to reproduce the error** 1- Import the attached alembic file ([BUSH_01_BL.abc](https://archive.blender.org/developer/F415379/BUSH_01_BL.abc)) 2- Add a modifier after the Mesh Sequence cacher modifier, and scrub the timeline and see Blender go pop. 3- Or, play with the Object Data parameters such as Auto Smoothing and etc. 4- Lastly save the file that has the alembic cache in it and try linking it to an empty scene and say, adding another copy of the linked object from add>group instance>...

Ajlan Altug commented

2016-12-07 17:53:46 +01:00

Changed status to: 'Open'

Ajlan Altug commented

2016-12-07 17:53:46 +01:00

Added subscriber: @ajlanaltug

Kévin Dietrich commented

2016-12-07 22:32:20 +01:00

Added subscriber: @kevindietrich

Kévin Dietrich self-assigned this 2016-12-07 22:32:20 +01:00

Kévin Dietrich commented

2016-12-07 22:32:20 +01:00

We'll check on it later.

Kévin Dietrich commented

2016-12-07 23:20:12 +01:00

@ajlanaltug in the future it will be preferable to open one bug report per bug, it makes it easier to track what is still buggy versus what needs fixing.

Some notes:

I cannot reproduce any crash when adjusting "Auto Smooth" and "Double Sided" properties.
I cannot reproduce any crash when undoing adding modifier (is there some specific modifiers that crash here?)
I can only reproduce a crash when adding a skin modifier, are there others that crash here? (I'll try to fix it later)
I don't see any particular issues with linking, objects are linked and animated just fine. TBH, I don't know that part of Blender very well, so I might need more specific directions.

I just fixed a crash happening when opening a file containing Alembic data or linking some Alembic objects from another file, perhaps it is related to some of your issues. Also would you mind trying a nightly build (you might want to wait a day or so to get a build with the aforementioned crash fix)? I made quite a few fixes and optimizations since 2.78a was released, so perhaps some of your issues are already fixed.

@ajlanaltug in the future it will be preferable to open one bug report per bug, it makes it easier to track what is still buggy versus what needs fixing. Some notes: - I cannot reproduce any crash when adjusting "Auto Smooth" and "Double Sided" properties. - I cannot reproduce any crash when undoing adding modifier (is there some specific modifiers that crash here?) - I can only reproduce a crash when adding a skin modifier, are there others that crash here? (I'll try to fix it later) - I don't see any particular issues with linking, objects are linked and animated just fine. TBH, I don't know that part of Blender very well, so I might need more specific directions. I just fixed a crash happening when opening a file containing Alembic data or linking some Alembic objects from another file, perhaps it is related to some of your issues. Also would you mind trying a [nightly build ](https://builder.blender.org/download/) (you might want to wait a day or so to get a build with the aforementioned crash fix)? I made quite a few fixes and optimizations since 2.78a was released, so perhaps some of your issues are already fixed.

Ajlan Altug commented

2016-12-07 23:52:22 +01:00

How would you like me to proceed? I can record a video grab of the crashes if you like...

Kévin Dietrich commented

2016-12-08 16:10:06 +01:00

Video captures of the crashes are not going to help if I still can't reproduce the crashes. For now the first to do would be test a nightly build to see if some of your issues were not fixed already. Blender 2.78a is almost 3 months old, and quite a few things have changed in the Alembic implementation (bug fixes, new features, optimizations...).

Video captures of the crashes are not going to help if I still can't reproduce the crashes. For now the first to do would be test a [nightly build ](https://builder.blender.org/download/) to see if some of your issues were not fixed already. Blender 2.78a is almost 3 months old, and quite a few things have changed in the Alembic implementation (bug fixes, new features, optimizations...).

Ajlan Altug commented

2016-12-08 17:15:48 +01:00

Hey there Kevin;

I recorded a video using the nightly build. Hope it'll come in handy.

Blender_abc_bug.mp4

Hey there Kevin; I recorded a video using the nightly build. Hope it'll come in handy. [Blender_abc_bug.mp4](https://archive.blender.org/developer/F415728/Blender_abc_bug.mp4)

Ajlan Altug commented

2016-12-10 21:39:43 +01:00

Hey Kev, got a chance to take a look at my latest video post?

Kévin Dietrich commented

2016-12-11 22:16:25 +01:00

This comment was removed by @kevindietrich

*This comment was removed by @kevindietrich*

Kévin Dietrich commented

2016-12-11 22:18:22 +01:00

Added subscriber: @LazyDodo

Kévin Dietrich commented

2016-12-11 22:18:22 +01:00

I still cannot reproduce the crash with the auto-smooth normals here on Linux. @LazyDodo, could you try if you can get a crash/backtrace on Windows?

Ray molenkamp commented

2016-12-12 16:22:12 +01:00

@kevindietrich Tricky one to reproduce, there's some subtlety to it. I can repro the bug but only if import the .abc file with 2.78a .

Crashing:

Import with 2.78a, save to bug_278a.blend
Turn on smooth normals , skip around for a little bit crash
Load bug_278a.blend into a build from master, skip around for a little bit crash

Not Crashing:

Import with a build from master, save to bug_master.blend
Turn on smooth normals , skip around for a little bit , no crashing
Load bug_master.blend into 2.78a, skip around for a little bit, no crashing

It kinda feels like a bug you have already fixed, but the bad data it generated in the past still lives on

stack trace from master

# Blender 2.78 (sub 4), Commit date: 2016-12-11 22:33, Hash e3510dd
bpy.context.object.data.use_auto_smooth = True  # Property

# backtrace
39: BLI_system_backtrace - 0x40E7AB80
38: sig_handle_crash_backtrace - 0x3FB1A620
37: sig_handle_crash - 0x3FB1A670
36: windows_exception_handler - 0x3FB1A8F0
35: UnhandledExceptionFilter - 0x76E6B870
34: EtwEventSetInformation - 0x77078344
33: _C_specific_handler - 0x77007F6C
32: RtlDecodePointer - 0x77018FB0
31: RtlUnwindEx - 0x77008050
30: KiUserExceptionDispatcher - 0x7703D91A
29: VerifierStopMessage - 0xF6FCA478
28: VerifierDisableFaultInjectionExclusionRange - 0xF6FC63D8
27: VerifierDisableFaultInjectionExclusionRange - 0xF6FC63D8
26: VerifierDisableFaultInjectionExclusionRange - 0xF6FC63D8
25: VerifierDisableFaultInjectionExclusionRange - 0xF6FC63D8
24: VerifierDisableFaultInjectionExclusionRange - 0xF6FC63D8
23: LdrGetFileNameFromLoadAsDataTable - 0x770B4010
22: EtwEventSetInformation - 0x77078344
21: HeapFree - 0x76DF1BB0
20: _free_base - 0x4487D650
19: _free_dbg_nolock - 0x4482B700
18: _free_dbg - 0x4482B6C0
17: free - 0x4480BEE0
16: MEM_lockfree_freeN - 0x4136F710
15: BKE_mesh_normals_loop_split - 0x409F1880
14: CDDM_calc_loop_normals_spacearr - 0x409E28A0
13: CDDM_calc_loop_normals - 0x409E2850
12: DM_calc_loop_normals - 0x4096DCF0
11: mesh_calc_modifiers - 0x4096ECF0
10: mesh_build_data - 0x40971380
9: makeDerivedMesh - 0x40966BE0
8: BKE_object_handle_data_update - 0x40AAD9A0
7: BKE_object_handle_update_ex - 0x40901680
6: scene_update_object_func - 0x40836530
5: task_scheduler_thread_run - 0x40EC7070
4: sched_get_priority_max - 0xF54812FD
3: sched_get_priority_max - 0xF54812FD
2: sched_get_priority_max - 0xF54812FD
1: BaseThreadInitThunk - 0x76DE59E0
0: RtlUserThreadStart - 0x7701B810

bug_278a.blend

bug_master.blend

@kevindietrich Tricky one to reproduce, there's some subtlety to it. I can repro the bug but only if import the .abc file with 2.78a . Crashing: 1) Import with 2.78a, save to bug_278a.blend 2) Turn on smooth normals , skip around for a little bit *crash* 3) Load bug_278a.blend into a build from master, skip around for a little bit *crash* Not Crashing: 1) Import with a build from master, save to bug_master.blend 2) Turn on smooth normals , skip around for a little bit , no crashing 3) Load bug_master.blend into 2.78a, skip around for a little bit, no crashing It kinda feels like a bug you have already fixed, but the bad data it generated in the past still lives on stack trace from master ``` # Blender 2.78 (sub 4), Commit date: 2016-12-11 22:33, Hash e3510dd bpy.context.object.data.use_auto_smooth = True # Property # backtrace 39: BLI_system_backtrace - 0x40E7AB80 38: sig_handle_crash_backtrace - 0x3FB1A620 37: sig_handle_crash - 0x3FB1A670 36: windows_exception_handler - 0x3FB1A8F0 35: UnhandledExceptionFilter - 0x76E6B870 34: EtwEventSetInformation - 0x77078344 33: _C_specific_handler - 0x77007F6C 32: RtlDecodePointer - 0x77018FB0 31: RtlUnwindEx - 0x77008050 30: KiUserExceptionDispatcher - 0x7703D91A 29: VerifierStopMessage - 0xF6FCA478 28: VerifierDisableFaultInjectionExclusionRange - 0xF6FC63D8 27: VerifierDisableFaultInjectionExclusionRange - 0xF6FC63D8 26: VerifierDisableFaultInjectionExclusionRange - 0xF6FC63D8 25: VerifierDisableFaultInjectionExclusionRange - 0xF6FC63D8 24: VerifierDisableFaultInjectionExclusionRange - 0xF6FC63D8 23: LdrGetFileNameFromLoadAsDataTable - 0x770B4010 22: EtwEventSetInformation - 0x77078344 21: HeapFree - 0x76DF1BB0 20: _free_base - 0x4487D650 19: _free_dbg_nolock - 0x4482B700 18: _free_dbg - 0x4482B6C0 17: free - 0x4480BEE0 16: MEM_lockfree_freeN - 0x4136F710 15: BKE_mesh_normals_loop_split - 0x409F1880 14: CDDM_calc_loop_normals_spacearr - 0x409E28A0 13: CDDM_calc_loop_normals - 0x409E2850 12: DM_calc_loop_normals - 0x4096DCF0 11: mesh_calc_modifiers - 0x4096ECF0 10: mesh_build_data - 0x40971380 9: makeDerivedMesh - 0x40966BE0 8: BKE_object_handle_data_update - 0x40AAD9A0 7: BKE_object_handle_update_ex - 0x40901680 6: scene_update_object_func - 0x40836530 5: task_scheduler_thread_run - 0x40EC7070 4: sched_get_priority_max - 0xF54812FD 3: sched_get_priority_max - 0xF54812FD 2: sched_get_priority_max - 0xF54812FD 1: BaseThreadInitThunk - 0x76DE59E0 0: RtlUserThreadStart - 0x7701B810 ``` [bug_278a.blend](https://archive.blender.org/developer/F417076/bug_278a.blend) [bug_master.blend](https://archive.blender.org/developer/F417077/bug_master.blend)

Sybren A. Stüvel commented

2017-04-13 16:49:26 +02:00

Added subscriber: @dr.sybren