Alembic size from Houdini and Maya differs significantly

[makah21803]

Hi,

I recently decided to recreate an old Maya project in Houdini. For that I had to export animated mesh from M to H so I used alembic. The 960f was 119Mb I did some modifications and tried exporting it as bgeo but it exploded to 106Gb so I tried abc which turned out to be 35Gb. And yes i added some attributes, subdivided few things and stuff, but it still seemed too much for the changes I made so I decided to explore.

I exported animated abc from M (2019) of just 11f (step 0.25f) and that was 94Mb. I opened the abc in H with basic alembic node (default H18 settings) and export that with rop_alembic_output node straight from the alembic read node, with the same frame range & step. I've tried different formats (HDF5 and Ogawa (used by Maya) ) and settings here but all had pretty much the same size results of 1.5Gb. I didn't find any settings that would relay to compression or anything like that.

Is it the same for you guys too? Does anyone have an explanation of this and perhaps a solution/idea how to reduce the abc size from H?

Thanks
Martin

---------

Houdini 18.0.349
Maya 2019

[anim]

without example file it's hard to tell

you will just get the same answers as in the other thread which pretty much covered the possible causes, if you loaded the geo to SOPs and unpacked, you could have essentially converted translating geo to deforming, which for sure was if you added attributes or subdivided, so you would need to carefully do that on static rest geos , then pack and apply original transforms for example

also if it was instanced in .abc, it's probably loaded as unique geo references unless that changed

there is also an option to load as alembic archive hierarchy at object level and export that? that may keep the transforms by default even if you modify the underlying geo, not sure how it compares I rarely load that way

but we can be just guessing without knowing your workflow

[makah21803]

7 minutes ago, anim said:

without example file it's hard to tell

you will just get the same answers as in the other thread which pretty much covered the possible causes, if you loaded the geo to SOPs and unpacked, you could have essentially converted translating geo to deforming, which for sure was if you added attributes or subdivided, so you would need to carefully do that on static rest geos , then pack and apply original transforms for example

also if it was instanced in .abc, it's probably loaded as unique geo references unless that changed

there is also an option to load as alembic archive hierarchy at object level and export that? that may keep the transforms by default even if you modify the underlying geo, not sure how it compares I rarely load that way

but we can be just guessing without knowing your workflow

Ive attached the abc and hip (just read -> rop). Frame range is 500-510.

I also tested a different geometry (organic animation) that uses Deforming Geo rather than Transform and the result is much closer of 2.2Gb from M and 2.4Gb from H (960f/0.25).

So it seems there is just something about M settings under the hood for non-deforming geometry. Single frame (of the non-deforming robotic animation) from M is 93Mb and from H 116Mb, which is more that 10% difference but not really significant. It seems its the way H stores the transitions that differs, since from single f to 11f/0.25 H makes the file about 4* larger (116Mb -> 480Mb) and M just 1.005* larger (93.5Mb -> 93.9Mb).

abcTest.hiplc

testM.abc