New Alembic features and attribute rendering

Hi everyone,

I have been working on some new features and improvements to the Alembic importer, and it would be nice to get some user feedback to refine those features, so that everything is as nice and rock solid as can be.

For one, I added support for file layers which allow to override properties of an Alembic file in a non destructive/procedural way. Use cases include:

  • updating a UV map (or any other attribute)
  • substituting high-res / low-res version
  • replacing the animation
  • you name it

Here is an example where I add some animation to a character using a layer:

For this to work, the hierarchies in the layers have to match that of the base file. In the UI, layers are “reversed” (as usual with Blender): layers at the bottom of the list override data from layers at the top of the list.

Secondly, I added support for geometry sets in the modifier. This means a better support for curves (although the current limitations still exist), but also proper support for point clouds. The main benefit is it allows to use the point clouds, meshes, and curves directly from geometry nodes (by adding a geometry nodes modifier after the mesh sequence cache one).

Lastly, there is support for custom attribute import. For now this only works for meshes and point clouds as I lack examples for curves.

As some software may export data with no type information, an attribute remapping system is introduced which allows to define how data is supposed to be interpreted (UV map, vertex colors, etc.). It is also possible to read as vertex groups, although I feel like this is redundant given that all attributes are read, and geometry nodes may process data as they wish. Unfortunately for remapping to UV maps or vertex colors, the data is not on the original mesh datablock so you may not see them in the mesh data UI, but you may see them in the spreadsheet.

Here is a screenshot showing the remapping of the Cd (color) attribute from Houdini (which was written as floats instead of colors) for a point cloud object (point cloud rendering is not really supported by Workbench/Eevee, so the colors are not shown in the viewport):

Without remapping, the attribute cannot be loaded as type info is missing:

As an added bonus, it is also possible to render mesh attributes (defined with geometry nodes) in Workbench and Eevee:

Some builds (20th October) are available if you want to try those features, let me know if you have any issues:

The branch is called temp-abc-features for those who want to build directly.


Thank you @KWD for your efforts in alembic… very useful enhancements.

What’s the procedural alembic status? (Loading data right from disk to cycles memory in rendertime.)

Hi Kevin !

First of all, thank you for all of this. I’ve been testing this feature with my houdini artist friend, and this has just opened the gate to infinite interoperability, for both single users and studio pipeline.

I wanted to make a design proposal about it, since you asked on, so here it is :


About Reading Attributes

It think that it should read every available attributes, without user input. All of my tests were using no more than 4 attributes, and it was already unhandy to write every one of them down, imagine a use case with 20+ attributes, it could be a nightmare.


  1. Use Render Engine Procedural > Load In Render Engine

I find the current name a bit confusing, even if technically accurate. I think that something more readable would be welcome, more user friendly.

  1. Regroup Velocity Parameters to a sub-menu

The fact that “Vertex Interpolation” and “Velocity Scale” are separated from the “Velocity Attribute” and “Velocity Unit” makes it a bit harder to read imo. Since those remains (in my use cases, at least) mostly untouched, i suggest that they can be put in a secondary sub-menu.

  1. Move Override Layers and Attribute Remapping to a sub-menu :

I think that they could be moved to a secondary sub-menu, for cleanup and readabilty.

  1. Move Object path under File path

I feel like those informations should be read together, it feels more natural to me

  1. Remove the “Read Data” line

If you agree on reading every single attribute from the cache, then i think that those buttons are useless now

That’s only my take, i’d love to hear everyone opinions about it !


That said, i have some questions regarding the custom attribute import :

Some attributes have inconsistent behaviors when importing, especially some that i think intersects with blender attribute naming, like “id” “Cd” “uv”, or “v”

In the case of “v” and “id”, they simply don’t seem to import. They’re not present in the spreadsheet at least.

For “Cd” and “uv”, it seems to create a duplicated attribute ( uv, uv.001 ; Cd, Cd.001 ), with one being completely empty. is this something i’m missing ?

Lastly, there is support for custom attribute import. For now this only works for meshes and point clouds as I lack examples for curves.

^ Can i send you example files ?

1 Like

The UI is divided into two parts:

  • settings that are global for the cache file
  • settings that are on a per modifier basis

It used to be that this difference was clearly communicated, but someone removed it (or it got removed during the 2.8 design redesign). There is also a difference in UI code between the constraints and the modifiers.

Given this, we cannot really move buttons freely, although there is some lee-way. The global settings will have to appear before the modifier settings.

“Velocity Scale” and “Vertex Interpolation” are for each modifiers.

“File Path” is for the cache, “Object path” is for each modifier.

Basically, in the current design, everything below the “Attribute Remapping” list is per modifier.

Having panels is good, but mixing cache and modifier settings might be controversial. I’ll see what I can do.

“Vertex Interpolation” has nothing to do with velocity though. This is to interpolate data between the nearest two full frames in an animation (so you can slow down time somewhat and still have a smooth animation).

The “Read Data” was originally for speeding up imports, as people complained that it was slow. I am not sure what to do with that.

If some attributes are missing, it could be that they lack type information, so a remapping should be used for that.

Yes you can, that would be nice. I also take files that show bugs :slight_smile:.

It is an experimental feature for now, and only available for viewport renders. I cannot really tell when it will be a supported feature.


v, even remapped, doesn’t show, unless you rename it @vel, or something else, in houdini before exporting. And then you have to remap it indeed

Not sure why, but it seems to work for me on render :thinking:

Thanks a lot, Kevin! This is one of the most important aspects when it comes to working in production pipelines! Im- and export of attributes, no matter what they might be and how they’re named. I’ll thoroughly test it as soon as I find time, because this will boost Blender to another level. :slight_smile:

P.S.: I hope GN and named attributes become friends in the future, because there will be attributes incoming from all possible places / software soon.

It is deactivated in final renders so the object is read from Blender’s cache modifier. The bounding box rendering is just for the viewport.

1 Like

I see, thank you

so bad… :frowning: final render full frame size and full scene need so much more memory than viewport.

So I think I know what’s up with missing attributes. When type information is missing, we try to resolve it by using the size of the attribute and see if it matches a domain (vertex, faces, etc.). But if an attribute has size N, and that the mesh has multiple domains with size N (e.g. a torus has the same number of faces and vertices), then we don’t know where the data should be, so we do not read it.

I guess there needs a way to say were the data is supposed to go. Maybe there could be a third option for the remapping (remap to point or face domain)?

New builds:


  • Removed the attribute selection boxes, all the attributes are read
  • Added panels to organize the UI:

Those improvements of the alembic are realy nice.I noticed that is not reading uint32 or int8 attributes.Is there will be a possibility to export point clouds with attributes in the future?It will be nice also if the modifier dosnt refresh every frame when the geometry is static or the override frame is checked.With heavy meshes changing the timeline is realy slow.

As Blender only support bool, int32, float, float2, float3, and RGBA colors, I can add support for more data types, but they’ll have to be converted to a supported type. So uint32 or int8 will become int32 in Blender.

I guess in the future it will be possible to export point clouds with attributes. But this not part of this little side project.

I can try to look into optimizing updates a bit. For static geometry, we still have to execute the modifier to check that it is indeed static.


Thanks for your work KWD.Its a nice improvement and it will have a huge impact on the workflow in the future.

hey @KWD thank you so much for this, we have finally the possibility to import custom attribute !

i just tested it on something i’m working on, i have a visualization of a hand that is moving through a point cloud (PC), I’m transferring the velocity of that hand to the PC in houdini, calculating the length of ‘v’ and outputting that as ‘speed’ attribute.

Exporting that to blender was pretty straightforward, i didnt even have to remap the attributes, i found the Cd, speed, pscale, v is not in the spreadsheet even if i remap it.

Now i have a PC on blender and a geonode modifier on it, using ‘speed’ attr to control the scale of the instances works ! as the hand is moving the instances gets bigger, now i want to visualize that with colors, but couldn’t transfer the speed to vertex, here’s some screenshots

In this setup I’m controlling the scale of instances with the distance of the second cube, to be able to visualize that with color I need to transfer that information to vertices, so i realized instances and did a transfer attribute, the same workflow with important point cloud didn’t work, it works for scale but transferring ‘speed’ to vertices is not working

Do you any idea why is that ? and do you want the files so you can test ?

I don’t know why that is. It could be a bug in my code, or maybe some secret inner workings of geometry nodes that I don’t know about. Having the files could indeed help me to see what’s wrong.

@KWD here’s the file, it’s 50mb because of the Alembic

Also @HooglyBoogly check the last posts, you might want to check this problem

You can’t use “Nearest Face Interpolated” mode in the transfer attribute node to get attributes from a point cloud. Try “Nearest”.

still nothing heppen