Disk mapping and cross platform setup

General
1

Would you please explain how the Disk mapping feature works across platforms? If I understand correctly, on Windows it is relatively easy. Say I have local site on D: but the studio uses Z: drive, so in order to have correct paths everywhere, I can run subst Z: D:/myWork and this will create a virtual drive Z: with D:/myWork folder contents. In OP settings the Destination: field would be Z:, and Source is D:/myWork…
But how it is supposed to work across platforms? For instance, there might be a studio server on Windows and a couple of remote users on Macos, what would be the best solution for OP setup? How would the disk mapping work for macos clients?

Platform dependent configuration for mapping of virtual disk(s) on an artist’s OpenPype machines before OP starts up.
Uses subst command, if configured volume character in Destination field already exists, no re-mapping is done for that character(volume).

2

There is a disk mapping feature in OP which you might be able to use for cross platform depending on the DCC you use;

Settings path: general/disk_mapping

3

Yes, I’ve checked this page in the docs, but I think it does not cover the cross platform part of the question. To my understanding, the subst command doesn’t exist on macos or Linux. So how this mapping should work on those platforms?

4

Sorry, I not familiar enough with this part of OP so something else from Ynput Team would know more.

Think you need to do something similar to this, but not 100 % sure;

Capture
Capture890×144 4.4 KB

5

This is actually handled on multiple fronts: One is the way of “subst”. The other one is using multiplatform definition of project roots:

image

and support in DCC.

For example in Maya, you have these settings in AYON (and similar in OP):

image
image746×171 13 KB

if you define source paths and destination paths, it will use Maya dirmap function. If you enable Use env var placeholder in referenced paths it will use environment variables in path for all loaded references in Maya that will be transparently remapped to project roots (as they are set as environment variables on OP/AYON start)

Similar thing can be done in Nuke or Houdini, wherever you can support variable substitution in file paths.

Also all publishes store template that was used to publish them so with multiplatform project roots you can reconstruct platform specific path.

1 Like
6

Thanks, @antirotor.
Ok, now I see that the path mapping in OP settings, set for macos or Linux, would run symbolic linking command.
Mac:

scr = f'do shell script "ln -s {source} {destination}" with administrator privileges' 
args = ["osascript", "-e", scr]

Linux:

args = ["sudo", "ln", "-s", source, destination]

I guess this part was just skipped in the docs, so it needs some clarification on how it is used on other platforms.

So, as it seems to me now, the general/disk mapping option does not do anything for cross platform compatibility, and just sets alternative place for the workdir inside the current platform environment.

Let me describe what I’m trying to achieve so you could see and, if possible, correct my approach.
I have an OP database on Mongo Atlas and a shots published on the Windows machine. Then I set up the site sync between the mac laptop and the studio location, it looks like this:

image
image800×558 21.7 KB

I use Fusion and, unlike Maya and Houdini, it has no path mapping options in OP settings (although it has internal path mapping, which I didn’t set yet)
In case the Mac user wants to continue working with the shot started on Windows, they sync the published workfile and open on Mac with no issues. But the paths in all contaiters and renders would still be Windows-style, like D:SYNC/Openpype, and hence not available immediately. The way to handle this is to set pathmaps inside the DCC settings. The question here would be, which site should I map in my DCC, local or studio?
If I just map studio site, I will not benefit from the site sync anymore, as all paths would be mapped to a network location. I would need to map to the local site then, but as you can see on screenshot, the local path has nothing in common with the studio path. And since the local site can be set in local settings, it may differ from artist to artist. This seem a nightmare to handle.

Alternatively, as I have just realized, I can open the Scene Inventory on a Mac machine, right click on the asset and choose Switch Asset. This will update the Loader file path according to the local site location. This seems to be a workaround, but it is a bit counterintuitive and requires some manual work, especially if the workfile has a lot of assets. This either needs some automation, or I’m just doing this wrong. Oh, and I will still need to replace the renderer path as well, either by creating a new render with publisher, or writing some script for render path replacement. Do you have any suggestions for such workflow?

7

I think that the solution of it is the use of environment variables in paths, or script that will do that if DCC doesn’t support it.

Because when you load something in and you use path like

[OPENPYPE_PROJECT_ROOT_WORK]/Project/Asset/publish/renders/v001/some_render.%04d.exr

this will be then resolved to specific path on any platform or site because OPENPYPE_PROJECT_ROOT_WORK maps to the project root work set in the settings. That is set on DCC start and it should take into account local settings and site if I am not mistaken.

Issue is when DCC doesn’t support expansion of variables in path - in that case the loader can be tweaked to modify the path on load - like it is done in Maya here -

8

Hey, thanks, I think it is a great idea.
I guess I can even build a simple script for Fusion for reverse mapping the part of the full path to the OPENPYPE_PROJECT_ROOT_WORK, so the workfile would be ready for exchange immediately.

9

And of course, PRs are welcome. :slight_smile: