Tweet
Hello, I'm having some troubles with the Alembic exporter in Max 2019.2 I cannot understand the behavior and would like you to have a look at whats happening.
My goal is to use the Alembic exporter to cache out / Export This tree over 250 Frames:
https://dl.dropboxusercontent.com/s/...00-0250%5D.mp4
The mesh has NO changing topology and is created using GrowFX. Now what boggles me is the file sizes should be much smaller, here is why:
Here is the result of multiple tests that I'm describing further below:
http://fridayvfx.com/clipupload/Phot...2p1OjjKBt9.png
1.) When I use the point cache modifier on the GrowFX object and cache the entire 250 Frames range,
the pc2 file gets 5183MB large, granted the mesh is not stored there, just transformation data. When I just export the Mesh (one frame) as an alembic its roughly 170mb - fine.
So the overall amount of data should be in theory no larger than 6GB.
2.) When I export the tree over 250 frames as an alembic (Ogawa) using the DEFAULT set of export channels, including velocity and vertex colors. The abc file gets ~25GB big.
Again, no changing topology, should be just the mesh and vertex transform data.
3.) When I export the tree over 250 frames using V-Rays vrmesh export, the resulting vrmesh file gets ~19GB, smaller, still not nearly around the desired 6GB.
4.) When I export the tree over 250 frames using Alembic (Ogawa) export using ONLY uv's, Normals and Material IDs. The ABC file gets onyl
a few Kilobytes smaller then the one with the default channel set still ~25GB.
4.) When I export the tree over 250 frames using Alembic, this time HDF5 using ONLY uv's, Normals and Material IDs. The ABC file gets
a few Kilobytes bigger then the one with the default channel set still ~25GB.
Last test:
5.) So I thought it might have something to do with GrowFX. So I took the Growfx object, collapsed it to an editable mesh, then copied the point cache modifier (from case 1) to it (yes that worked).
And cached this out as an Alembic file and a vrscene file resulting in no difference in file sizes (again a few kilobytes), abc is still ~25GB, the vrmesh is still ~19GB.
Now I know that I'm comparing apples with oranges. But as far as I am informed, the Alembic format does support decent data compression like Xmesh does (my license for Xmesh just ran out a
few days ago, so I could not test that unfortunately). Now the pc2 format is written binary but as far as I know without any compression at all.
So my expectation is that the resulting alembic file, if the implementation is done correctly, should be around the ~6GB mark or less because it JUST needs to save the mesh and vertex transform data.
It certainly should NOT be larger than vrmesh and certainly should NOT re-save the mesh every frame when there is no topology change.
Here is one more thing btw. which boggles me the most and I cannot explain why it happens:
6.) When I take the vrmesh file that had a size of ~19GB, load it in a vray proxy, then use "show whole mesh" and then export THAT object as an alembic over the same framerange using ogawa and the
deafault channel set: the resulting abc file gets ~43GB large. I have not even investigated why that is because thats not at all a valid workflow anyways, but I just wanted to throw it out there as more info.
Again, here is a description of the resulting files and file sizes:
http://fridayvfx.com/clipupload/Phot...2p1OjjKBt9.png
Am I doing something obviously wrong?
If you want to have a look at it yourself, here is the file with the GrowFX Tree:
https://www.dropbox.com/s/kzahxu7pes...blic..max?dl=1
Max2019.02
GrowFX 1.9.9 Sp6
btw. I know that this is not at all a V-Ray related problem. I just wanted to get your opinion on this.
My goal is to use the Alembic exporter to cache out / Export This tree over 250 Frames:
https://dl.dropboxusercontent.com/s/...00-0250%5D.mp4
The mesh has NO changing topology and is created using GrowFX. Now what boggles me is the file sizes should be much smaller, here is why:
Here is the result of multiple tests that I'm describing further below:
http://fridayvfx.com/clipupload/Phot...2p1OjjKBt9.png
1.) When I use the point cache modifier on the GrowFX object and cache the entire 250 Frames range,
the pc2 file gets 5183MB large, granted the mesh is not stored there, just transformation data. When I just export the Mesh (one frame) as an alembic its roughly 170mb - fine.
So the overall amount of data should be in theory no larger than 6GB.
2.) When I export the tree over 250 frames as an alembic (Ogawa) using the DEFAULT set of export channels, including velocity and vertex colors. The abc file gets ~25GB big.
Again, no changing topology, should be just the mesh and vertex transform data.
3.) When I export the tree over 250 frames using V-Rays vrmesh export, the resulting vrmesh file gets ~19GB, smaller, still not nearly around the desired 6GB.
4.) When I export the tree over 250 frames using Alembic (Ogawa) export using ONLY uv's, Normals and Material IDs. The ABC file gets onyl
a few Kilobytes smaller then the one with the default channel set still ~25GB.
4.) When I export the tree over 250 frames using Alembic, this time HDF5 using ONLY uv's, Normals and Material IDs. The ABC file gets
a few Kilobytes bigger then the one with the default channel set still ~25GB.
Last test:
5.) So I thought it might have something to do with GrowFX. So I took the Growfx object, collapsed it to an editable mesh, then copied the point cache modifier (from case 1) to it (yes that worked).
And cached this out as an Alembic file and a vrscene file resulting in no difference in file sizes (again a few kilobytes), abc is still ~25GB, the vrmesh is still ~19GB.
Now I know that I'm comparing apples with oranges. But as far as I am informed, the Alembic format does support decent data compression like Xmesh does (my license for Xmesh just ran out a
few days ago, so I could not test that unfortunately). Now the pc2 format is written binary but as far as I know without any compression at all.
So my expectation is that the resulting alembic file, if the implementation is done correctly, should be around the ~6GB mark or less because it JUST needs to save the mesh and vertex transform data.
It certainly should NOT be larger than vrmesh and certainly should NOT re-save the mesh every frame when there is no topology change.
Here is one more thing btw. which boggles me the most and I cannot explain why it happens:
6.) When I take the vrmesh file that had a size of ~19GB, load it in a vray proxy, then use "show whole mesh" and then export THAT object as an alembic over the same framerange using ogawa and the
deafault channel set: the resulting abc file gets ~43GB large. I have not even investigated why that is because thats not at all a valid workflow anyways, but I just wanted to throw it out there as more info.
Again, here is a description of the resulting files and file sizes:
http://fridayvfx.com/clipupload/Phot...2p1OjjKBt9.png
Am I doing something obviously wrong?
If you want to have a look at it yourself, here is the file with the GrowFX Tree:
https://www.dropbox.com/s/kzahxu7pes...blic..max?dl=1
Max2019.02
GrowFX 1.9.9 Sp6
btw. I know that this is not at all a V-Ray related problem. I just wanted to get your opinion on this.
Comment