@ryan.odom
I added RH-56420 to make sure there is only one copy of each embedded image on the disk. And that’s the one that can be edited to get the texture updated in Rhino.
Based on my test a while ago. Rhino will not create the _embedded_files folder if the embedded images can be found in these locations:
- The folder where the 3dm is stored and its sub-folders.
- The folders set in Options > Files > Search Paths and their sub-folders.
Hello @KelvinC
Sorry to wake up this topic but I have some issues related to embedded images.
In my personal opinion, rhino should not create these embedded image folders, but I also understand why this has to happen.
In the plugin I am developing, I need these images to be embedded in the document and not create these folders, I need to move the .3dm by several PCs without propagating image folders.
In my case, my document will hardly have more than 1 or 2 images maximum, do I need to know if I can embed these images directly into the document data?
Thanks
Yes, when the embedded images can be found on the computer. See RH-56420.
So it is possible to edit the images externally when the 3dm is opened on another computer that does not have the original images.
You can move the 3dm files only and ignore the xxxx_embedded_files folders.
The xxxx_embedded_files folder appears because the images are embedded directly into the 3dm files.
It’s just that the xxxx_embedded_files folder appearing on the original computer causes confusion.
@KelvinC I would still like to petition for a checkbox in Rhino that says “never embed any files”.
(We effectively are forced to do that anyway now, since we put some Rhino files on our PDM system, and cannot risk Rhino attempting to create any folders.)
(And zero of the other 3D applications we work with ever create any folders for embedded files, unless the user explicitly asks to export/save them. This is really bad behavior on Rhino’s part.)
We clearly need a way to get Rhino to stop unpacking embedded files to solve this problem. However, that will mean, of course, that the file will load without the textures you need. Would it be OK, in your case, to unpack them into the TEMP folder instead?
- Andy
Hi @KelvinC
Perhaps you did not understand my question, or I did not express myself correctly.
whenever I save a .3dm file on my pc, and the images are on my pc, rhino does not create this folder “xxxx_embedded_files” , and this is ok , I have no problems here.
If the same file is opened on another pc, rhino creates the folder “xxxx_embedded_files”, I understand why it has to be created, and this folder is created in the same directory as the .3dm file.
The problem is that I don’t welcome the creation of additional folders, imagine, my plugin includes at least one image in all files, we are talking about a dozen files a day, these files will be used by other computers in the same way and also dozens of times a day, all users can delete these folders but I think it’s unnecessary work.
I think:
1º These folders can be created, but in a temporary directory.
2º This folder must be eliminated when the rhino closes.
Since I’m just going to use my plugin to open this file, can I force rhino to cahnge directory these temporary folders is created ?? not create on .3dm directory?
Thanks
This works for @MatrixRatrix.
Will this work for you, @eobet?
For me works, after on close rhino I can control file do delete on Temp folder, and same time the user will not see these folders (at least in the same directory)
edit:
In my option, this have to by aply to API like template file "Rhino.ApplicationSettings.FileSettings.TemplateFile ".
Sure, because that at least doesn’t interfere with the PDM system.
I would prefer Rhino asking the user to manually locate and re-link the missing files (like all other 3D apps do), but as a quick fix, it at least won’t cause any issues.
(And in the long run, I’d still like a “never embed files” option, to keep Rhino file sizes down, and since those files are checked in separately on the PDM/a different backup system anyway).
We actually used to do that, when this feature was first designed. It was absolutely hated! Users generally don’t want to have to make these kinds of choices - certainly not every time they open a file. They just want to get on with modelling.
- Andy
Interesting. Was this 20 years ago (similar to “blocks”) by any chance? Perhaps the industry has moved on since then? 
Either way, I merely suggested it as an option, not the default behavior this time (but one which can be permanently toggled in the settings).
No. It was originally introduced in Rhino 5, and I’m fairly sure the original opinions would still be valid.
Maybe I didn’t read this thread all the way through, but this is what I would like:
The image files are already embedded in the Rhino file, correct? The only purpose of having an external folder is to edit them possibly? So, if the folder was not created by default, and someone actually needs the folder with the images, it could be done with a simple command - like _CreateEmbeddedFilesFolder. If the images are edited, maybe a second command to manually update the stored images if desired, and of course an automatic update if the file is saved with “save textures” checked.
What did I miss?
Correct.
No, it is not just that. Rhino has to extract the embedded images to load them.
I did this test to confirm.
- Save a 3dm with an embedded image to an SD card.
- Move the SD card to another computer and make the SD card read-only.
- Open the 3dm.
The xxxx_embedded_files folder cannot be created.
The embedded image is exacted to a folder set in Options > File > Search Paths.
If no folders set in Search Paths, the embedded image is exacted to C:\Users\{username}\AppData\Local\Temp\Unpacked Files
And the Unpacked Files folder is added to the Search Paths list.
- Delete the image in the Unpacked Files folder. The texture on an object goes blank.
Well, that’s what’s wrong then. I know this is a simplistic way to look at it and there are probably some complexities to this I haven’t considered, but IMO Rhino should just be able to read and use the images it has stored internally without having to re-create the folder with discrete files.
RH-58320 is added for this. Thanks.
The reason we do it is because third party renderers generally need the path to the actual image file.