When Rhino unpacks textures to a new folder it OVERWRITES textures with same filenames

When Rhino 5 SR5 saves textures (while “Save Textures” option is checked) what happen if the same filename for two or more textures is used but these textures are all in different folders on the server each texture with different content or size? Will Rhino overwrite this textures by the last one it finds or will start rename texture filenames like - texture.jpg, texture(1).jpg, texture(2).jpg, texture(3).jpg, etc.? I prefer renaming.

I did test: When Rhino 5 SR5 unpacks textures to a new folder it OVERWRITES textures with same filenames, so from e.g. 10 different textures from different folders locations remains only the last one. That is bad behaviour i think:-(

Hi Petr,
Thanks for making this a separate topic.

I’m trying to reproduce this here to file a bug/change in behavior but I’m a little confused. Doesn’t the unpacking happen automatically in the same location as the 3dm and in a newly created folder named after that file? This would keep the textures separate from original server location.

Yes, the new folder is created in same place from where you are opening 3dm file. The textures are unpacked separately from the original textures on the server. That is correct.
BUT what i am meaning and where is probably the bug is that if you use in your project_C textures with same name e.g. “texture.jpg” but in different locations on the server e.g. from earlier projects (like M:\project_A\textures\texture.jpg and M:\project_B\textures\texture.jpg) where each texture has different content, so then when you use “Save Textures” option checked in Save As dialog while saving project_C, instead of having two texture.jpg files renamed (to be possible have them both) e.g. texture(1).jpg and texture(2).jpg we get only one file texture.jpg. This is wrong because the content of both textures was different.
I am not sure if it is happening when saving or when opening file. Anyway it is not good.

Hi Petr,

Thanks for your patience as I try to reproduce exactly what you are seeing here. Can you answer a few more questions?
1- Are the 3dm files you are working on (Project A, Project B etc.) stored on your computer or on the server as well? And are they in separate folders wherever they are or one folder?
2- Where are the overwritten textures happening after a save? In the embedded content folder unpacked for the 3dm file or on the server location?
3- What kind of edit are you performing on the textures? Is this an edit within the texture properties in Rhino or edited externally?
4- Do you have a sample folder of textures and files that reference them. I’m not able to reproduce anything that seems incorrect here testing server shared textures that also get saved within the 3dm. Please give us exact step by step instructions to see what you are seeing, I think I’m missing something that is obvious to you. :smile:


Ad 1) on the server
I will test it in local folder (C:) but i gues it will behive same. Tested and yes, same behaviour in local folder.

Ad 2) embedded content folder is problem. It oversaves texture.jpg over texture.jpg.
No problem with server locations/folders/textures.

Ad 3) external in Photoshop.
Differen textures are prepared, but with same filename texture.jpg but differen paths.

Ad 4) as i see my explanation is confusing. I will prepare sample project to show you what is going on. I will send you zip file then.

Ill try to be more clear.
Thanks for help anyway.

Hi, here is the step by step:

  1. Please download and unpack ZIP file to disk C: where you will get folder “Textures Test” with subfolders.
    link: http://db.tt/unqqzpUf (7MB)

  2. Subfolders “Project A”, “Project B” and “Project C” simulates structure on the server or project work flow where are now stored only textures which we use in last project in subfolder “Project D”.

  3. Focus on subfolder “Project D” and open the rhino file. You will see wooden wall with shoes in three columns. Each column has shoes with different shoe texture. There are three different shoe textures in that project D which are linked from Project A, B, C.

  4. If you look to subfolders “Project A”, “Project B” and “Project C”, you will find folder “textures” and there is “shoe.jpg” file stored. In each project same name but different content.

This is still OK. It works. But now

  1. If I save “Project D” with “Save Textures” enabled in “Save As…” dialog, it should save all three shoe textures and wooden wall texture used in that file. So we have 4 textures in total in that file.

  2. I saved Project D with textures in last subfolder “client folder”. The file “project_D+textures.3dm” You can save for reference same file.

  3. Save “Project D” with “Save Textures” enabled in “Save As…” dialog to any folder for later use. But you should get same file as it is in “client folder” now.

  4. Delete all subfolders with “Project A”, “Project B”, “Project C”, “Project D” to simulate that we are on the different computer and we only have “project_D+textures.3dm” file or yours created in step 7.

  5. Open file “project_D+textures.3dm” from “client folder” subfolder or use yours.

  6. While opening, rhino creates folder “project_D+textures_embedded_files” where we should find all 4 textures used in our project. BUT what is there? Only two textures! One shoe.jpg file and one wall.jpg file. That’s wrong, isn’t it? Now the wall have all three columns with same shoe instead of three different types in viewport. The two textures are missing.

I guess they were overwriten when unpacked to embedded folder. In this point would be great to deliver all textures even if they have same filename. Rhino should rename them to shoe(1).jpg, shoe(2).jpg and shoe(3).jpg and update links to them. Or ask if start autonaming or let user input new name(s) for colliding textures filenames.

Is it clear now?

Thanks Petr for sticking with me on this one. I was sidetracked on thinking this had to do with textures on a server location… sorry.

I understand completely now and have filed this issue as RH-20483. This is not a publicly visible report at the moment but that is planned. Thank you very much for taking the time to assemble the sample folders.

RH-37721 is fixed in the latest WIP

1 Like