Hi.
I have to get to the bottom of what (tf) Rhino is doing with texture files.
I’ve got this OBJ file that’s 110 mb.
If I open it with Rhino and save it, it will become a 48mb file… nice !
Then I work on the file, deleting some of the mesh’s faces, yada, yada, yada, and at some point, I realize I have separate texture files for over 200 mb in my folder, sometimes directly in the folder, sometimes in a separate “****_Embeded_Files” sub-folder, and the Rhino file size has gone bezerk to over 400 mb.
I can’t make sense of this texture file mess.
Aren’t embeded files supposed to be …embeded, and not separate ?
And what’s with the huge bloating ?
I suppose the embedded files are converted to some uncompressed fileformat before being stored in the rhino document. But I agree, it doesn’t feel like this is handled in the best way.
I have “SaveTextures” on at 99% of the time, and I avoid turning it off since that can cause me to loose textures from pasted picture objects. It would be great if this could have been solved in a better manner.
I tried the following : Copied my 48 mb file in my huge file, deleted the old mesh and saved.
Now the file is even LARGER !!!
How can there not be an automatic purging of unused texture maps ???
That means the materials and textures are still in use, which is what the output also says. 0 unused materials and 0 unused textures purged.
The embedded files are extracted to a new folder only if the original files can’t be found at the location they were at when they were added to the 3dm file. Rhino writes out embedded files to disk because Rhino needs the files to exist on disk to be able to use them. You can embed files (Save Textures option checked) to make it easier to distribute files. If you don’t need to distribute files with other people you could uncheck the option, but then you’ll have to remember to separately provide any support files when you do have to share with other people. You can think of it as extracting from a ZIP before being able to use it.
Addendum: when I open your Bloated.3dm, select the meshes, change their material to the default material I can purge the materials:
OK, then how do you explain that I have the exact same file except it weighs 1/10th the bloated one ?
Sorry, but I don’t understand the whole explanation about embeded files.
I ALWAYS save with Save Textures option checked, so in my mind, these files are in the Rhino files, and it shows in the weight of the files !
So why should Rhino need access to the damn data as separate image files since it is already there in the Rhino file ?
One thing is for sure : this whole texture thing is super badly managed.
First, this is kind of lame : Rhino can truly embed points, point clouds, curves, meshes, nurbs, sub-Ds and a boatload of other object types without having to regurgitate them as separate files in order to make use of them.
Why would bitmaps be treated differently ?
Secondly, I think it is quite confusing and misleading : I wonder how many people understand that, despite being able to embed textures, Rhino is unable to use these textures if they are not copied as separate files.
Finally, the process to purge textures that are no longer relevant seems quite tedious (similar to getting rid of layers when blocks are involved) and it can very simply account for all those obese files in scanning / photogrammetry workflows.
Anyways, thanks for your explanations.
It popped my bubble about Rhino’s abilities, but at least I can deflate all these files and start enforcing folder management rules for those damned textures.
One more thing :
If the texture files are stored outside the Rhino file, what happens when you delete or add textured objects in the Rhino file ?
How is the “Embeded textures folder ?” updated if at all ?
Once embedded you do not have to copy them yourself as separate files. Embedding is intended for sharing with other users that do not have your folder structure nor your texture files.
Do you mean to ask this when you do not embed textures in the 3dm file?
I don’t think Rhino deletes files from this folder. Rhino does not delete asset files pretty much ever, because that would be destructive and could not be undone.
Addendum: also note that the embedded files folder will not be created when all asset files are found in the locations they were referenced from when initially brought into Rhino. Files are written to the embedded files folder, extracted from the 3dm file only when they are not found. So if 9 out of 10 files are already in the expected locations only the one will be written to disk into the embedded files folder.
I know Rhino does this automatically. I didn’t imply it was done by the user.
Well, no, I imply in all cases since Rhino always needs these files to be OUTSIDE the Rhino file (even if they are INSIDE as well).
What a mess !!! Wouldn’t it be much much simpler if “Embedded” really meant “Embedded” , like in “no creating sub-folders and copying files around if this ot that happens” ?
Sorry to insist, but what is so special about bitmaps that Rhino can’t read the data if it’s contained in the Rhino file ?
