Umm… Don’t know even how to categorize that. Can somebody explain to me how it can be that this 3 MB fbx file after saving in 3dm is 122 MB? That’s complete nonsense - Sidenote: Save small doesn’t change that fact. I’m in the state of WTFs per second looking at the size of those files. Is there any special trick to avoid so big file.
Attaching the fbx - exptest.zip (1.1 MB)
I’d love to hear an explanation of this behavior.
Hello - there are over 1 million faces in the meshes, probably fbx is using some kind of instancing for the identical parts, Rhino just sees meshes.
Hi Pascal. Sure but 3MB to 122MB difference? Even after saving only geometry and merging this down to three objects I get 106MB. As I understand there’s nothing that can be done about it?
Hello - probably not, but I’ll check with the developer. My guess is there are a half dozen unique items with transformed copies in the fbx and this becomes thousands of individual meshes in Rhino.
@tim, am I making stuff up here?
I think what Pascal said is exactly right. We don’t read or write instances or components or whatever they’re called from FBX files at this point. Plus FBX can have a polygon as a face and Rhino still uses triangles and quads under the hood even if it looks like a polygon.
If you can get the same model as a SketchUp file then it will preserve the component structure.
Also, if you can get an ASCII version of your example FBX file it would handy to study how they do their instancing and maybe I can figure it out for the future.
Try this one - exptest_ascii.zip (1.5 MB)
If not maybe @nathanletwory (i remember you have origins there) can help to get fbx ascii format from this - size_tests.zip (3.1 MB)
It looks like Rhino doesn’t use block instances during import for duplis. Blender does.
Additionally imported in Rhino _SelAll gives 8009 objects. In Blender I get only 4006.
So 1) lots of unnecessary duplicated geometry, and 2) more objects than necessary. I used the binary FBX version to test, since that is what Blender accepts.