Alembic HDF5 support: completely remove?

Hey all,

A bit of background for this topic: Alembic is not a single file format, it can be stored in two different ways: Ogawa and HDF5. Ogawa replaced HDF5 and is smaller and much faster (4-25x) to read (source).

As long as Blender has had Alembic support, it has never supported the HDF5 format in any release. There is a build-time option WITH_ALEMBIC_HDF5 that can be used to enable HDF5 support in your own build, though. In the years that I have been maintainer of Blender’s Alembic code, I’ve seen very little requests to enable HDF5 support in an official release. As a matter of fact, I only remember getting such a request once, and that was to support very old software. After I suggested to check whether that software had an update I never heard back, so I guess they also upgraded to Ogawa.

Now that I’m working on improvements to the Alembic exporter, I’m once again seeing the #ifdef WITH_ALEMBIC_HDF5 conditionals in the source code, and I want to get rid of this. IMO we should either properly support HDF5 or remove it altogether and clean up the code. Seeing how Ogawa is superior in every way, and how little requests for HDF5 I’m aware of, I would say let’s remove it.

Are their people or studios who build Blender for themselves and enable HDF5 support? Who would feel any impact from complete removal of HDF5 from Blender?


Hey there.

I would call it safe to remove HDF5 support. In every other ABC importer/exporter this option is either:

  • not default (and warns you about possible loss of performance)
  • renamed to “legacy”
  • not even there

This flavor of alembic is deprecated for several years now, so I think it doesn’t matter in any recent production environment. If one really needs to load legacy alembic files, there’s still the “abcConvert” command line utility around.

Just my two cents, working in a studio with a very mixed pipeline.


Hi @saiBot, welcome to devtalk!

Well, that does it. Someone will have to come up with very strong arguments now to keep HDF5 in there.


I see it as:
Does it cost the developers meaningful time to keep it working?
Y: remove it
N: keep it as legacy


I agree with LapisSea

Houdini supports both formats if i remember. Some older assets are still HDF5. If that is not huge problem would be nice to support it…

That’s the thing, officially it isn’t even working. But it does get in my way now that I want to redo the Alembic exporter. Just saying your point is doubly-valid :wink:


I’m aware of the occasional ‘blender doesn’t read this file’ report, but i’ve honestly never heard of anyone building blender themselves with hdf5 support, could be worth checking with some of the big linux distro’s and see if they ship it or not.

I am probably biased towards keeping obscure legacy options as I’ve been dealing with that first hand but considering the nature of open source this is not nearly as big of a problem. If a company needs it they can always pay the developer for the needed time spent for merging it in to the up to date code base or do it themselves. :wink:

I rather see Sybren using his time on Alembic to get stuff working for Houdini Alembic data other than Cd, than supporting an old format in Alembic almost no-one is using anymore. :wink:

We just did a job in Houdini-Maya, just because Blender Alembic import cannot read custom data from the Alembic file besides Cd & UV. Too bad, as rendering was pretty fast in Blender. Especially quick tests in Eevee were wonderful. But alas, Maya it was…

And besides that, it would be nice to have a working solution for replacing a in-scene Alembic file with a new version. This doesn’t work for animation now. You have to re-import & delete the old file.
this makes versioning a pain in the behind.


Because blender cannot read ABC animations over 2G, I need to use hdf5 format to keep the animation imported into blender. If abc can fix this problem, I do n’t need hdf5. now I compile blender myself, and the lib file There are no hdf5 dependent libraries in the folder,Hope to fix the bug that the growth animation cannot be loaded properly when it is imported above 2G. Also, if my growth animation starts from zero vertices, it will cause blender to crash

What does that mean?

I assume he means 2Gb.
If so, that would be a Alembic limitation of the format, -or- an old Windows 32 bit issue.

I can recall this kind of behavior in the old Maya 6’ish period on 32bit Windows pc’s. If you’re (any) file got over 2Gb, you were screwed.

someone dropped by on chat with this issue, and i had a quick peek at it, it is seemingly a speedtree issue , when it writes >2GB files it generates a corrupt abc archive, not even the alembic command line tools can work with the file so there’s very little we can do on the blender side about it. 4GB file generated from blender had no such issues.


Update: HDF5 support has been removed from Blender (0c3843622726 and 0102b9d47edf).


My version of RealFlow uses HDF5, I guess I´ll have to upgrade my software, eh?

That, or don’t upgrade both RealFlow and Blender. Older versions of Blender will keep running for a while. And if they don’t, you could always use an emulator.

1 Like

After Jun 15 no, before was unsupported feature, as i already told you in #support chat

… as unsupported and never enable features

Hi @YoussefCreator. This is the forum for developers to discuss things (or to discuss things with developers), not a place to get support.

Having said that, I’m fairly sure that any modern software writing Alembic can use the Ogawa format.