← All ideas
  • Published 11 Jul 2019

Proper Alembic Support

This is re-post from devtalk, unsure about re-posting rules but wanted to start a discussion.

Hia,

We’re a small VFX house (feature films), using alembic (and slowly toying with USD) for most of our work. We’re primarily a Houdini place but have introduced Blender for modeling and the VSE for contextual review of shots (thanks to the cache updates!) and now we’ve been rendering with Cycles on a few shots.

We’ve hit some roadblocks/showstoppers (in both 2.79b and latest 2.8 builds) in regards to Blenders Alembic implementation.

I hope to provide some meaningful feedback from production land and propose some suggestions for how to elevate some of our current issues. I welcome any pointers on how to circumvent the problems or discussions about best practice in terms of Blender and Alembic in its current form.

Alembic is a fantastic interchange format, with support for some crucial production features, like streaming data, data-deduplication ,instancing, hierarchy, custom attributes to name a few. I want to highlight two things in particular that we’re having issues with:

Poor streaming data support

Currently Blender only streams geometry if its deforming, but not if its a packed/instanced set of geometry, then Blender unpacks and loads all of the geometry data and stores it in the Blend file.

I can have a single ABC file with a fairly hefty point cloud that I instance an object on and it will only save the instance and the point cloud in a small .ABC file. Blender will unpack and copy all of the objects around into memory, and break the file link to the .ABC file (as in I would have to re-import the entire data-set for a new version of the cache). Which makes working with cache versioning a proper PITA. The point is to stream and load the data of disk OR import and unpack.

Our issues are, file size ballooning and duplication of data. Poor version/file control.

Suggestions:Alembic render primitive, fuzzy filtering of ABC file in Alembic modifier. Let the user chose if you want to unpack the alembic into blender for editing. Or just reference the file if it’s for static reference, render or sim work.

Poor attribute support

Alembic supports arbitrary data stored on points, vertices, primitives etc as Floats, Vectors and Strings. A lot of additional data concerning caches are stored here, including things like rest positions, velocities, age and other useful data that can be used in contexts like shading and simulation work.

Blender’s ABC support is limited to a single Color channel (which is actually clipped to 0-1!) and a single UV float2 stored on vertices. Inside of Blender I can have multiple layers of vertex colors but it only reads the first one inside an alembic file. Blender supports multiple layers internally but when I export a Blender native object with multiple UV and Col maps no other application reads them. Neither Houdini nor Gaffer can read/see that data. However blender will see it once you re-import the file into Blender. I suspect Blender isn’t following the specification of the format here.

Issue: Can’t do any production rendering of complex nature since we’re severely limited by the number of data channels we can import. No motion blur on deforming meshes based on velocity attributes! (showstopper, but it CAN render motion blur if there are only hierarchal transformation from the ABC file, just not mesh deforms)

Suggestion: please remove the clipping of data in the Col/Cd attribute on import, copy the other vertex data from the ABC file into other Col vertex maps since blender already supports multiple data types on points. The latter is a hack, but could be easier to implement.

TLDR, these are stopping us from using Blender/Cycles;

Can’t stream alembic archives to the full specification (no instancing without unpacking, no file-read only)

Can’t import attributes beyond Cd and UV (which are also crippled)

With USD looming around the corner these are issues that would need to be tackled before even thinking about USD in Blender.

We’re loving using blender for VFX and are well impressed with 2.8 and the talented developers pushing the envelope and appreciate everyones efforts. I hope this post comes across as informative and not to off-putting, but ABC is an industry standard and full support would not only benefit VFX artists working in other applications but also Blender artists directly.

It’s a good format.

96.8%

Development Status: Open

Upvote 30 Downvote 1
theotheo
11 Jul 2019

6 Comments

sybren

Poor streaming data support

Yes, that's known, and I would love to improve that. With 2.80 on the horizon, this will become doable (wasn't readily possible in 2.79).

Poor attribute support

Yes, that's also known and discussed in T50725

The other things are also pretty much known limitations. This blog post describes some of my broader ideas on how we can move Alembic forward. There are plenty of ideas, but we're lacking both time and information about how exactly to write the desired information to ABC while maintaining compatibility with other software.

3
luciano

Great to see other people using alembic, two questions: have you got in touch with Sybren Stuvel? (developer that has implemented alembic in bender), Can you provide some files and examples for him to test? one of the issues with interchange files is that basically they only have blender, so unless files are provided with "expected results" its really hard for them to test all the important use cases for us, Sybren is super responsive when it comes down to alembic and if you give him the files and what you need i'm sure in no time you'll be able to get some improvements.

Probably the best idea is to talk to him in blender.chat/channel/blender-coders

an other question, can i ask what studio you work at? cheers!

2
sybren

* @Luciano A. Muñoz Sessarego * I wasn't the only one working on it; the original Alembic support was given as a patch ( D1783 ) by DwarfLab, and whipped into shape by Kévin Dietrich. I improved their work & extended it.

2
luciano

* @Sybren Stüvel * ah sorry!, didnt want to miscredit, but seems though as you're the most active maintainer of it

sybren

* @Luciano A. Muñoz Sessarego * That I am for sure :)

paoloc3d

Thanks theotheo for providing with very usefull feedback from production as well as for the suggestions you gave.

Suggestions:Alembic render primitive, fuzzy filtering of ABC file in Alembic modifier. Let the user chose if you want to unpack the alembic into blender for editing. Or just reference the file if it’s for static reference, render or sim work.

Suggestion: please remove the clipping of data in the Col/Cd attribute on import, copy the other vertex data from the ABC file into other Col vertex maps since blender already supports multiple data types on points. The latter is a hack, but could be easier to implement.

Totally agreed with everything.

Issue: Can’t do any production rendering of complex nature since we’re severely limited by the number of data channels we can import. No motion blur on deforming meshes based on velocity attributes! (showstopper, but it CAN render motion blur if there are only hierarchal transformation from the ABC file, just not mesh deforms)

In production generally we use for sure these attributes between production software like Houdini:

  • color (Cd)
  • velocity (v)
  • opacty
  • point scale (pscale)

And the ability to import not just geometry data but also just point data.

Ive tried several time to use Blender in VFX pipeline (since 10 years) but I've had always same obstacles.

I love Blender, fingers crossed.

Pa