USD Animation file too big #3058
-
|
Hello everybody! I'm trying to export an animation to USD to reference in another project, the problem is the file size, for 75 frames of animation it takes 4.5GB while if i"m exporting in Fbx the file size is 30MB. Can anybody explain me how to export the animation containing the file in few MB instead GB? I've tried everything I know, bake the animation before export, bake after, import the .ma file in the scene and cache in the layer, tried every setting in import/export/reference of USD, export the animation baked in Fbx and convert it in USD.. nothing it seams to work. I notice when I try to export the USD if I'm unchecking the History under Include Options, the file is 190MB but I've no animation in the file. If there is a way to have 190MB of file with the animation inside would be nice. Hope someone can help, |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 1 reply
-
|
4.5GB feels like a lot of unecessary data. one option to try here - have you tried deleting history, then baking the animation before export? on a second note, if the file you have is something that you could share with us, I would love to investigate further on why is your exported file so large, specially when you can get export a static file with less than 1% of that size |
Beta Was this translation helpful? Give feedback.
-
|
Hi! I can send you the .fbx I've exported from the scene, unfortunatelly I can't send you the original scene as there are multiple animation and it's 5GB. Can you please tell me how can I send you the .fbx privately? |
Beta Was this translation helpful? Give feedback.
-
|
you can message me at [email protected] :) |
Beta Was this translation helpful? Give feedback.
-
|
There doesn't seem anything too out-of-the-ordinary here. My guess is that you've just got a very dense mesh. Comparing the file size of an FBX and the USD file is like comparing apples and oranges. FBX is doesn't by default use point caching, so all it is exporting is the mesh (static), the animated skeleton and the skin weights. FBX also does seem to be very efficient at storing mesh data, which is why the fbx file is only 30 mb. The USD file is storing this (presumably) very dense mesh and its point positions for every single frame of the animation. Hence the much larger size. |
Beta Was this translation helpful? Give feedback.
-
|
Make absolute sense, the main problem is that I've another 22 animations to reference in the rendering scene and it's going to take ages to open the file. On top of that, Maya nor Houdini can open 4.5GB of USD file as give me errors. I notice though that exporting in Binary the file size decrease to 1.4GB, I guess because it has less to write as it's cannot be open in coding software, at least I can reference but it's still too big to me. I can't remember on top of my head how dense is the topology, I can give you more info tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
As noted above, you can't really compare FBX with USD. They service entirely different workflows (at this point in time). If your animations are skeletal and/or use blendshapes, then you may get much more optimized scenes by using USDSkel and blend shapes. That has limitations as USDSkel doesn't currently live up to the expectations of all use-cases. Also, because USD doesn't have animation curves, even with USDSkel you are still going to get a lot more data for animations in USD vs FBX to match the end result because USD is exporting states for all frames rather just at keyframes. |
Beta Was this translation helpful? Give feedback.
There doesn't seem anything too out-of-the-ordinary here. My guess is that you've just got a very dense mesh.
Comparing the file size of an FBX and the USD file is like comparing apples and oranges.
FBX is doesn't by default use point caching, so all it is exporting is the mesh (static), the animated skeleton and the skin weights. FBX also does seem to be very efficient at storing mesh data, which is why the fbx file is only 30 mb.
The USD file is storing this (presumably) very dense mesh and its point positions for every single frame of the animation. Hence the much larger size.