Cross-Platform Paths

bug
rhino5

#1

Is it planned to fix cross-platform file referencing between Rhino and Rhino for Mac?

I can link an external block file in OSX and the PC version will pick up the link. However if I the insert a referenced block on the PC, the Mac can’t recognise the pathname.

With texture files on the Rhino Render side its even worse. Pathnames simply won’t translate between the platforms.

In terms of workarounds, I have tried using UNC file naming (smb://servername/etc…) but that won’t stick either, and with the textures dragging-and-dropping texture files into the mac interface again generates a pathname the PC can’t read.

Seems like a fairly simple fix, but 100% essential to using Rhino in a cross-platform environment. AutoCAD on the mac has a button to fix pathnames, or use local pathnames, either of which would be a welcome improvement here.


(Marlin Prowell) #2

Both Windows and Mac Rhino store full path names to linked blocks, and these full path names are specific to the OS where the link is created. Both Windows and Mac Rhino use the same core code to search “in the neighborhood” to find referenced files that are not at the exact full path name stored in the 3DM file, so misplaced files that are found by Windows Rhino should also be found by Mac Rhino. For example, this code looks for any missing referenced file in the same directory as the 3DM file, and this works correctly on both platforms.

If you can provide some specific examples of 3DM files and externally linked files, including the full path of all files and what kind of file system (Mac or Windows) where the files reside, then we can try duplicating what you are describing.


#3

Hi - thanks for coming back to me on this.

The problem relates to external references (textures or linked blocks) that are stored remotely on a central fileserver.

As an example (using textures), a file originated on a Mac stores the reference to the material texture file as /Volumes/pathname etc…, while Windows stores the reference as S:\pathname etc.

Opening a file with links created on one platform over on the other platform loses the link as the different OS versions don’t recognise the volume syntax.

By comparison, Adobe InDesign manages to resolve the cross-platform links issue without a problem.


(Dan Belcher) #4

Do you store the 3dm file and the external references on separate volumes? For example, is YourModel.3dm stored on your local desktop and the texture maps on a separate, network attached fileserver?

-Dan


#5

Hi Dan

The 3dm and the textures files live on different volumes on the same NAS fileserver - the model in a folder on our “Projects” volume and the linked block in a folder on our “Library” volume.

If a linked block is placed in an adjacent folder on the same volume by Windows Rhino, Mac Rhino will indeed resolve the reference. However, the same is not true in reverse - Windows Rhino doesn’t resolve the link to the adjacent folder if the link has been made using Mac Rhino.

If the linked block is placed on a different volume, neither Windows nor Mac Rhino can resolve the references - unlike Adobe InDesign.

And for texture links, these don’t work in either direction (Mac or PC or PC to Mac) even if the image file is in an adjacent folder on the same volume.

In general, I don’t favour software going hunting around for files, as it creates the risk of linking to out-of-date versions of references if the filenames aren’t rigorously superseded. Much better to be pointing to an exact location.

I can sense there may be a temporary workaround, placing all files in the same folder, or manually re-linking each and every file, but when there are many links involved that’s not practical, and since other software [Indesign, Vectorworks etc] can resolve these references, it seems to be a Rhino issue rather than an OS one.

…unless you find differently and maybe there’s something very a-typical about our network of course! In which case any pointers gratefully received.


(Dan Belcher) #6

Oliver-

Sorry for the delayed response. Thanks for taking time to elaborate and clarify. This helps. I’m going to try to gin up a plan of action for this, but bear with me for a minute more…

Interesting. I’m only a novice InDesign user, so please help me. Does it do this “automagically” or does it require setting the paths to the separate volumes on the NAS in some setting somewhere? I guess my imagination says that when you link to the image asset (in the Library volume) that is the setting the path to said volume (whereas the indd document lives in the Projects volume). Is that right? Or is there some Preference/Setting somewhere when you set search paths?

Understood. Given this, I’m presuming that InDesign isn’t really hunting around for files, just doing some path formatting heuristics on a per-platform basis. Am I following here?

Sounds painful, hence the request. I’m with you.

I doubt you have an atypical setup. At a previous job, we had a similar setup. It seems this would be good to fix for those offices that have a mixed platform setup.

Thanks again,
-Dan

PS: I’ll start logging bugs and post here.


#7

Since I use Adobe creative cloud along with Rhino I will help explain. InDesign works with links to assert files, so if bringing in images or text files it creates link to the “imported file”. If I have an asset in a folder, cloud, external or local InDesign knows where that file is. If someone on a windows machine adds an asset file to the InDesign document, that stays relevant even when I open the document on my Mac. The link to the assets file is kept.

So if I have a picture frame image in a Rhino for Mac file and then some one on Windows opens the file, the image is still there, linked.

@Oliver_Salway is mentioning textures and I am not sure if these are related to renders in Rhino or not? This to me would be a separate issue since render images work different depending on the render software.

The block issue should be resolved though. If I link to a block in Dropbox for example, someone on windows opening the file should also have that block in the file.

«Randy


#8

Hi Dan, Randy

I’m not sure how InDesign performs the feat, but it automatically resolves the syntax of the OS its running under; no need to specify anything about search paths in advance. So if you import an asset on the Mac, it shows the link as /Volumes/Library/StockImages etc… but when you open up the same file on Windows and check the link info, it shows up as T:\StockImages etc…without missing a heartbeat.

AutoCAD has a different approach and invites Mac users to “specify Mac path mapping to Windows server address” with a dialogue on opening the file or via the XREFPATHMAP command - which is useful, but not nearly as simple and effective as the way Adobe InDesign seamlessly handles the issue.

Thanks for your continued help on this!


(Dan Belcher) #9

Oliver-

Ok, thanks for the background on this. I think I have enough to do some testing and work up some issues. I’ll post them here for your review once I have them drafted.

Much appreciated,
-Dan


#10

That’s great thanks Dan


(Dan Belcher) #14

We’ve not forgotten about these issue. I’ve logged this in a couple of issues that are related…

  • MR-3111: Network files locations do not work properly cross-platform
    • MR-3112: External block references made on macOS do not work on Windows (but they do if made on Windows)
    • MR-3113: Texture file path names do not work between Mac and Windows on shared network volumes

We don’t have a resolution for this yet, but we’ve finally managed to (we hope) reproduce this common setup.


(Dan Belcher) #18

Hi @Oliver_Salway-

We’ve added a feature called File search paths to the latest RhinoWIP (5E199w). I hope this helps your situation. I did some tests with a shared volume between Rhino 5 for Windows and Rhino 5 for Mac and - once the search paths were set properly - the linked blocks and textures worked well.

Please give this is a try and let us know how it goes.

Thanks again for speaking up about this issue,