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