Alembic Import is really Flaky in 2.78a
Open, ConfirmedPublic


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


Kévin Dietrich (kevindietrich) triaged this task as "Confirmed" priority.Dec 7 2016, 10:32 PM

We'll check on it later.

@Ajlan Altug (jacobo) 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.

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

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

Hey there Kevin;

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

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

This comment was removed by Kévin Dietrich (kevindietrich).

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

LazyDodo (LazyDodo) added a comment.EditedDec 12 2016, 4:22 PM

@Kévin Dietrich (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 .


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



Add Comment