Rhino file saved with textures again after opening will not update paths to unpacked textures

Hi guys,

For our client we saved rhino files with textures. Client contacted us back that he is not able to render objects because textures paths leads to wrong place although textures are viewed correctly in viewport.

Rhino file saved with textures again after opening will not update paths to unpacked folder with textures.
Is there any way how to update texture paths automatically? Using some macro or another technique? Not to do it manually because it is lots of files?

We need to solve it as soon as possible.

Thanks for your help.

Hi Pit_79,

Is the client using a specific render plugin that you know of? @andy do you have any suggestions for path updates or would adding the folder to the search path directory in Options be what you’d suggest?

What version of Rhino are you using? A lot of work was done with respect to finding external files during the Rhino 5 Beta process, so I want to make sure you’re all running Rhino 5.

Yes I am running Rhino 5 SR5 (5.5.30627.15215, 27.6.2013)

Hi BrianJ.

I heard they use V-Ray render plugin running on Rhino 5.

For better understanding:

When we save rhino file with “Save Textures” option checked and then open it again, Rhino will create new folder in same place where the rhino file was opened and unpack there used textures. That is fine but

When we select any object in that opened scene and look into “Properties > Material - Assign material by: Object - Textures - Colour” and click the name of the texture, it will pop up Editing window where the Filename path is the original path leading to old wrong texture folder instead of path to new folder and texture created by Rhino while opening.

Is it possible by Rhino to update texture paths shown in Editing window leading to new folder and textures created when opening such type of file?

And another question: When Rhino 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.

Thanks for help.

I did test:
When Rhino 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:-(

Another test:
Rhino somehow knows and uses the new created folder with unpacked textures, because they are visible correctly in viewports and native render shows them too, BUT the only problem i see is that the path is not updated in Materials > Textures > Color > Filename Path

Thanks for doing these tests and explaining all this. I’ve struggled with these texture issues for a while.

Thanks for your patience PiT_79, I’ll need to get more information from our developers but I don’t believe there is a way to refresh texture file paths to use the extracted folder location. I think this is a bug. However, in my tests here, the file path does link to the correct location when clicking the … if the original file location is not present on the machine Rhino is running on. The textures will also show up in the render here in my tests using Vray however mapping information is not preserved from when the materials were assigned as basic Rhino materials. Is this what you did before sending the files to the client? I’m wondering if the reason they can’t render is that the textures don’t show up at all or that the textures are not the right mapping. These are two different issues.

After @andy can comment here I should know enough to file the naming bug but I can still render here despite this so I’d like to know more about what the client is seeing exactly. Maybe you can send the file to me too… brian.james@mcneel.com since I won’t have the textures locally either.


If you have any other specific issues please post them (in separate topics if not exactly related to this). I’m finding that one big misconception out there (and maybe this is not one you have) is that there is a universal material definition and universal UV mapping between rendering and modeling programs. Rhino 5 will have it’s own material settings and mapping info per object and whether or not a plugin uses all that depends on if it was made to do so. It can be very confusing I agree and I hope it gets easier as more rendering plugins adopt or translate this information from Rhino files directly.

We sent the client files where all objects uses basic rhino materials with textures and mapping.
I think (but I am not sure, because i dont have V-Ray Plugin) that V-Ray takes the paths from that rhino materials, but the paths are wrong there (as described earlier).
For example in our render plugin Air for Rhino, it renders objects correctly, because it takes the paths somehow dirrectly from the rhino and bypasses the wrong paths in materials.
I will ask client if the problem is with mapping or showing the textures basicly and let you know.

Client says that the objects in the scene renders all white without textures in V-Ray plugin.

I see the textures using Vray here. It must be something with the way the file is set up or the version of Vray as a guess. If you can send the file to me I can possibly help more. http://www.rhino3d.com/upload
send to tech or brian.james@mcneel.com

Thanks for sending the file over… I just replied. For anyone following here, it worked for me with Vray and the textures were present in both the viewport and render. I think the clients issue might be due to a version difference of Rhino or Vray at the moment. The file paths do have the old original location when seen in the Rhino material property but the file browser link there ‘…’ does lead to the correct extracted folder location.

Thanks. But it would be good if the path will change in both dialogs in material, not only here ‘…’ :slight_smile: no confusion then.

Filed as RH-20463… this is not publicly visible yet but that’s planned. I suggested a refresh all texture paths command as one option. It’s unclear to me if the current behavior is by design but it will get looked at nonetheless… thanks for bringing it up.

Thanks :slight_smile: