Work-wrecking bug with mapped image paths being changed by Rhino

Hi RMA Team,

We have a terrible terrible bug that makes working on shared files really hard.

Context: We all work from a synced-shared drive that’s part of Dropbox for Business. Each user and each computer would have a different looking path to this folder based on their Windows username and in which drive they have installed Dropbox, so if a program is using a referenced/linked file we need to have ways that the link is always accessible regarding of username/dropbox installation setup.

How have we solved that? using virtual drives. So in our case we sue a common agreed upon virtual drive letter “F:”, so it does not matter how in each user the path looks to get to:


in my case it could be:

or in George’s case might be:

For both of us, and anyone in our team it will unequivocally will always be F:\projects\test_project_folder

So when we are going to add an image file to a material we make sure we go through the F: drive path.

This works for anything we use like Indesign documents, Modo files, Illustrator smart objects, etc.

But there’s one program that is swapping, all by itself the path we give it for the actual physical path that each user/computer has. And this is just not ok. It breaks sharing files among the team.

We used to think that some of us were distracting and linking files from the incorrect physical path, until after watching it closely we realize it’s not us it’s Rhino!

Watch here how my file path from F:Drive becomes D:drive all by itself.

BTW, when a different person opens a file we do encounter this absolutely useless dialog box:

…and I say absolutely useless because none of the things that a user working in a production environment would possibly want to do upon seeing this dialog can be done (easily). It’s unbelievable how little real world thinking all your rendering/materials/image tools have in them. I’m sure it makes perfect sense when you have cube_test.3dm with one material, like the video I just made. When I opend this today I just wanted to pull the Scotch bottle out while I wipe off my tears.

…but it’s late here and I have more work to do, so quick bug report for now, and I’ll come back on more specific feedback about how to fix that dialog another day. For now please fix ASAP the fact that we get to see that dialog at all, because something that Rhino is doing wrong, not us.




hi RMA Team,

just checking if this problem Gustavo described above is being worked on??


I’m unable to repeat the problem. Could you be very specific what you mean by “Virtual drives”?

I originally thought you must have meant “Mapped network drive”, but you are mapping your F: drive to a path on D: - not a UNC path. So it can’t be that…and anyway, I can’t repeat it with my mapped drives.

OK - he’s what I’ve figure out so far:

It would appear that you are using the ancient MSDOS command “subst” to re-map your Dropbox folders to a drive letter. I imagine you watched this:

With this workflow, I can repeat the bug, and I will now attempt to fix it.

Subst is pretty anachronistic. I would prefer “net use” if possible - that seems to work here. You will have to provide a UNC path, and that can be done this way:

net use f: “\localhost\d$\Dropbox…\projects\test_project_folder”

That’s a more modern way of doing things - and by “more modern”, I mean 1997 instead of 1982.

  • Andy
1 Like

Or with the Map Drive function on the Windows Explorer Home Page (using the same UNC path) - that puts it in the right place for you if you aren’t hot on the command line/powershell tools.


Almost. You need two backslashes at the start -> \\localhost\c$\Users....

I have added a workaround to V7 for the subst issue. The bug is here:

I’m not going to add this to V6 because it is too close to the core of the texture functionality - it needs plenty of field testing.

Hi all,

@andy you are correct we use the “subst F: “folderpath”” the reason we use that uncool 1982 approach is because sometimes the path is NOT in the userfolder. In a few laptops that have single SSD Dropbox does live in the user folder. In other laptops and all desktops with multiple SSDs they live in a completely different drive (like D: or E: drives). So f: “\localhost\d$\Dropbox…\projects\test_project_folder” will not always work, but I see if I can apply that method to any path.

I’ll look into Net use and @jeremy5’s suggestion. But for now it looks like this will be fixed in 7 soon?


Yes. Next build.

1 Like

“Map drive” and “net use” are the same thing. One is the UI term, the other is the command line.

RH-58500 is fixed in the latest WIP


I will get back to this soon, but can you confirm or deny that the fix for your top item works?

  • Andy

Hi Andy, all,

How to I force Rhino to NOT save/include any images used in the Rhino file (backdrops, material maps, picture frames, etc)? That’s the best way to test of when someone else opens my file in their computer everything is loading correctly from the virtual F:drive. Thx.


1 Like

Save As (or just Save for new file). In the lower part of the save dialog uncheck Save Textures.

Thanks Nathan, We’ll test tomorrow when the team is back at work and report back.


If you’re using huge textures a lot you should see quite some weight loss in your 3dm file :slight_smile:

Yeah we are going to need that. Is there a way to save without texture by default? Does that check-box uses your last used setting?

Doesn’t look like the checkbox has memory, but you can create a new button with -_Save that sets the _SaveTextures option to the value you want.

Hi Andy, I sent you a private message with a video on this. Still not working.