[Maya]Fixing Absolute texture paths in referenced files

Pipelines
#1

Hello,
Happy Monday!
This gist:
An employee just installed a new hard-drive and his Maya assets now live in an “E:/” drive.
Everyone else in the studio uses a “C:/” drive.
We have a Maya project setup at the root of our project for everyone in the studio (this should resolve it?).
When he opens any file in Maya it does not resolve the absolute texture paths on startup, so he gets all blank (invalid) textures.
I wrote a scipt which runs on ‘scene startup’ to resolve texture paths. Which works great on files that don’t reference anything.
But our animation system requires us to reference in rigs in our animation files.

Is there any way to change texture paths for referenced files?
Or will I have to detect that a texture is invalid on startup, then open the referenced file in a background Maya, change the texture paths, save that file, then re-open the original file?

There’s got to be a better way! This is crazy!

Thanks,
Adrian

#2

Are you setting the workspace for the user’s Maya?

Also, you may want to browse this thread

One thing to note is that the absolute references in Maya come from the UI, not from user input - if you paste a rel path into the field in Maya it will be resolved to an abs path even though that’s not what you want. You can, however, catch that at save time (well, you could if there was a save time callback in Maya - I do it at export time) and fix it from code and it won’t absolutize.

#3

Out of the blue: If you’re in windows, have you tried simply remapping to a virtual drive using Subst? This will atleast get you out of trouble until your path issue in Maya is resolved.

NEVERMIND - this won’t work with the C: drive. You have to explicitly map to a virtual drive. I’m not aware of remapping between two folders.

#4

if i am understanding the question correctly, this is happening when opening a maya file that references another maya file that points to a texture?
what happens when he tries to open the maya file containing the texture? does the project take care of the path resolution?

if your project is set to c:/project/ and his project is set to e:/project, then the textures should be found, as long in both cases the relative file path is the same.

#5

[QUOTE=rgkovach123;23230]if i am understanding the question correctly, this is happening when opening a maya file that references another maya file that points to a texture?
what happens when he tries to open the maya file containing the texture? does the project take care of the path resolution?

if your project is set to c:/project/ and his project is set to e:/project, then the textures should be found, as long in both cases the relative file path is the same.[/QUOTE]

Thanks everyone!

does the project take care of the path resolution? it does not.
-I wrote a script that will resolve the original files. He has to open the original file, the script will resolve the texture paths, and then when he opens the file that references the original file, everything works. I want to avoid having him open the rigs and saving eveytime he needs to open an animation.

if your project is set to c:/project/ and his project is set to e:/project, then the textures should be found, as long in both cases the relative file path is the same
-Our whole entire studio’s projects are setup that way. Maya isn’t able to resolve it still

#6

I read through the post.
What I’ve got now is:
I’m hijacking that Maya save procedure (actually the studio was doing this already, I’ll piggy-back off it)
After the save, in the background, I will simply do a find and replace and try n’ resolve it then.
The only other solution I could think of is to have a script that will find and replace when checking the Maya Ascii file into P4

#7

what version of maya are you using? last time i used projects was maya 2008 and it worked well for us (except in the case of branches).
currently we are using environment variables that get written into the paths when the maya file is saved.

i wouldn’t be surprised if there were bugs in maya’s project code, but the whole point of projects/workspaces is to enable different drive configurations and move content around.

#8

if your project is set to c:/project/ and his project is set to e:/project, then the textures should be found, as long in both cases the relative file path is the same
-Our whole entire studio’s projects are setup that way. Maya isn’t able to resolve it still

For textures, check the .ftn attribute - it’s probably got absolute references where you want relative ones.

For file refs, you can use environment variables instead of fixed paths: http://download.autodesk.com/global/docs/maya2012/en_us/index.html?url=files/File_referencing_File_referencing_tips.htm,topicNumber=d28e119571

#9

[QUOTE=rgkovach123;23233]what version of maya are you using? last time i used projects was maya 2008 and it worked well for us (except in the case of branches).
currently we are using environment variables that get written into the paths when the maya file is saved.

i wouldn’t be surprised if there were bugs in maya’s project code, but the whole point of projects/workspaces is to enable different drive configurations and move content around.[/QUOTE]

Thanks!
This is something I’m looking into now, using env variables when saving out files.
Are you hijacking Maya’s save function? How are you overriding maya and stuffing enviroment variables into your saved files?
I’m trying to use a search and replace function in python, that runs post-save, but i get funky results.

#10

UPDATE
Now I am trying to do a find and replace, post save.
I use an environment variable to determine the current users drive letter.
I use that to find and replace (find=‘E:/’ replace=’’)

When I do that in a text editor like Crimson, then save.
Then open the file in MAYA, the textures are resolved. Yay!

But when I use Python to script the find and replace:

  1. It destroys my Maya file. I get errors about missing a ‘Requires’ statement
  2. I get extra line space.
  3. In action, when would I run this script? post-save? wouldn’t the script fail because the file will be currently open in Maya?
    –Will I have to force open a blank scene, edit the file in the background, then reopen the original file? that would be terrible, you’d loose your undo’s everytime you save.

So what I’m thinking now is to have that script run on P4 check-in. Seems risky…
Anybody else with any tips?

Here’s the python code I’m using to find and replace:
import fileinput
filename = ‘C:/dfp-dfa/Dfa/SourceData/Characters/Monster/Rig/Monster.ma’
file_to_replace = fileinput
for line in file_to_replace.input(filename, inplace=0) :
print line.replace(‘C:/dfp-dfa/Dfa/’,’’)

“SourceData” is at the root of the Maya project

If I strip everything behind “SourceData”, in a text editor, then open in Maya everything is fine.

Using Python to strip out the path, breaks my “.ma” and wont load correctly

#11

It’s not easy to override save (the other thread has a method for doing that, I think). However it’s easy to override the UI for the hotkey / file menu save options which will catch most cases. You just want to replace the variable part of the path with a dollar-signed environment var like ‘$varname’. For example in my test file the ma file looked like this on disk:


file -rdi 1 -ns "sphere" -rfn "sphereRN" "$fred/sphere.ma";
file -r -ns "sphere" -dr 1 -rfn "sphereRN" "$fred/sphere.ma";

You might also want to add something to your startup script to create that environment variable if it does not exist, since you don’t want to have to worry about this.

Maybe the smartest, cheapest way to do this is not to worry about file save time, but just to wrap file references going forward - make a tool that creates references with the options you need and paths relative to your env vars, then you should be OK unless users are messing with it.

#12

[QUOTE=Theodox;23239]It’s not easy to override save (the other thread has a method for doing that, I think). However it’s easy to override the UI for the hotkey / file menu save options which will catch most cases. You just want to replace the variable part of the path with a dollar-signed environment var like ‘$varname’. For example in my test file the ma file looked like this on disk:


file -rdi 1 -ns "sphere" -rfn "sphereRN" "$fred/sphere.ma";
file -r -ns "sphere" -dr 1 -rfn "sphereRN" "$fred/sphere.ma";

You might also want to add something to your startup script to create that environment variable if it does not exist, since you don’t want to have to worry about this.

Maybe the smartest, cheapest way to do this is not to worry about file save time, but just to wrap file references going forward - make a tool that creates references with the options you need and paths relative to your env vars, then you should be OK unless users are messing with it.[/QUOTE]

Thanks Theodox!
What I ended up doing is hijacking the Save function. So right before save I change all texture paths to relative (I basically strip off the first few directories) and then save the scene.
It seems to be working now, I’ll be testing it throughout the day

#13

You may also be able to do this using the dirmap command. Since it is just one user he could set up dirmap rules for himself, and other users would be unaffected by the remapping in his session as the changes dirmap makes do not get stored persistently with the scene (as far as i can tell)

dirmap -en true; // enable it
dirmap -m "C:/" "E:/"; // case sensitive, so must remap both possibilities
dirmap -m "c:/" "E:/";
#14

If you do have an oddball user he can use dirmap in his personal usersetup to do this for himself, and it will work when he loads other people’s files.

I’m pretty sure that this won’t change paths created by that user, and unless you want everybody to have to map all possible combinations you’ll need to catch saves and relativize as in earlier posts