Maya GoZ UV issue.

[Mykaljaye]

I am using Zbrush 4R4 with the latest GoZ version, Maya 2013, and 2012. I created a UV set for a simple cube to test the problem. UV looks fine in May. In Zbrush I flatten the UVs and they are all scrabbled. I have tried this with several different models but I end with the same result when using GoZ from Maya to Zbrush. Going from ZBrush to Maya seems to work just fine. Exporting as an Obj from maya seems to carry the UVs across to Zbrush. I used GoZ frequently before 4R4 with no UV issues. Anyone else seeing a problem with UVs when going from Maya to Zbrush?

[MentalFrog]

You try checking/changing your UV export/import options? Sometimes it's just a matter of UV getting flipped the wrong way.

[Mykaljaye]

Yeah, it's not flipped, basically one side looks collapsed and the other side looks like the uvs are disconnected.l

[MentalFrog]

Can you show some screenshots?

[Mykaljaye]

These are the two screen shots of the problem. On is with GoZ the other is with Obj Export from Maya. This is with Maya 2013. But i have also tried 2011 and 2012.

[ionblue]

I'm having the same exact problems, its making goz useless for me now

[tchoa]

I'm having the same exact problems, its making goz useless for me now

Same issue for me
But one thing I noticed is that it's only happening on very simple geometry.
UVs positions are written with wrong values when the mesh has less than, let's say..., 500 points.
Not sure about this number but e.g the mesh I'm working on atm has about 221 vertices and its UVs are keeped by GoZ when I subdivide it to 812 vertices. Don't know if I'll take the time to write another python plugin to work around this new issue.
UVs can always be 'pasted' on the lowest subdiv level by importing an .obj or .ma exported as usual.
Anyway this seems like some file io issue. If the .ma export's time is short enough, the file will be corrupted. This is weird.

[tchoa]

Seems I found a workaround.
I've not been deep too far but mainly what I found is that GoZPublicPath/GoZBrush/GoZBrushFromApp modifies the ma file (especially when the ma file is small). The bug has been introduced in the 4R4, in some way, probably because of the small changes done to the maya ascii file format by the 2013 version.
So I went to this simple idea: unlock and lock the file before GoZBrushFromApp accesses it.
In the GoZBrushFromMaya.mel (usually located in C:\Users\Public\Pixologic\GoZApps\Maya\)
@ line 488 change this part of the code for

// Then exports it to a Maya file.  $maFileName = $GoZProjectPath + $gozName + ".ma";
  python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IWRITE)");
  sysFile -delete $maFileName;
  file -f -op "v=0;" -typ "mayaAscii" -es $maFileName;
  python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IREAD)");

It's python so it should work on any os.

[omnivern]

It's defiantly a Zbrush/Goz issue that showed up with the 4R4 update. It does look like it's a bug based on # of polys per mesh. Any mesh containing less than 418 polys will transfer to Zbrush with totally jacked UVs. If your mesh contains no tris you can subdivide your object in Maya and rebuild in Zbrush (pain in the ass) but it will get you working again.

Our studio is working on Maya 2009 with 4R4

[ionblue]

Seems I found a workaround.
I've not been deep too far but mainly what I found is that GoZPublicPath/GoZBrush/GoZBrushFromApp modifies the ma file (especially when the ma file is small). The bug has been introduced in the 4R4, in some way, probably because of the small changes done to the maya ascii file format by the 2013 version.
So I went to this simple idea: unlock and lock the file before GoZBrushFromApp accesses it.
In the GoZBrushFromMaya.mel (usually located in C:\Users\Public\Pixologic\GoZApps\Maya\)
@ line 488 change this part of the code for

// Then exports it to a Maya file.  $maFileName = $GoZProjectPath + $gozName + ".ma";
  python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IWRITE)");
  sysFile -delete $maFileName;
  file -f -op "v=0;" -typ "mayaAscii" -es $maFileName;
  python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IREAD)");

It's python so it should work on any os.

I'm on OSX 10.8.2 and I'm when I try to run the script with those modifications I get this error in Maya:

# Error: OSError: 2

[tchoa]

I'm on OSX 10.8.2 and I'm when I try to run the script with those modifications I get this error in Maya:
# Error: OSError: 2

As I'm not working with osx and it seems you get a file path error, try checking if the path is correct with this:

// Then exports it to a Maya file.  $maFileName = $GoZProjectPath + $gozName + ".ma";
print ("goz file test : " + $maFileName + "\n"); 
python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IWRITE)"); 
sysFile -delete $maFileName;  file -f -op "v=0;" -typ "mayaAscii" -es $maFileName; 
python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IREAD)");

Not sure but check also if you've rights to change the file's lock attribute.
Maybe the os.chmod command can't do lock/unlock operation or another os command should be used with python and osx.

[ionblue]

As I'm not working with osx and it seems you get a file path error, try checking if the path is correct with this:

// Then exports it to a Maya file.  $maFileName = $GoZProjectPath + $gozName + ".ma";
print ("goz file test : " + $maFileName + "\n"); 
python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IWRITE)"); 
sysFile -delete $maFileName;  file -f -op "v=0;" -typ "mayaAscii" -es $maFileName; 
python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IREAD)");

Not sure but check also if you've rights to change the file's lock attribute.
Maybe the os.chmod command can't do lock/unlock operation or another os command should be used with python and osx.

Here's the print result:
"goz file test : /Users/Shared/Pixologic/GoZProjects/Default/pCube1.ma"

The only thing is it never created that file.

After some playing around I discovered that if I remove the first python command the script works and the UV remains intact. Keep in mind I have no idea what I'm doing when it comes to python so hopefully this solution is okay

  // Then exports it to a Maya file.    $maFileName = $GoZProjectPath + $gozName + ".ma";
  //python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IWRITE)");
  sysFile -delete $maFileName;
  file -f -op "v=0;" -typ "mayaAscii" -es $maFileName;
  python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IREAD)");

[tchoa]

Good catch ionblue!
My mistake! I wrote this too quickly, working with an existing .ma file goz linked... (stupid me)
So the code should be the one, as we want to unlock the file before delete and rewrite it if it already exists:

// Then exports it to a Maya file.  $maFileName = $GoZProjectPath + $gozName + ".ma";
if (`filetest -r $maFileName`)
  python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IWRITE)");
sysFile -delete $maFileName;
file -f -op "v=0;" -typ "mayaAscii" -es $maFileName;
python ("import os, stat\nmaFile = '" + $maFileName + "'\nos.chmod(maFile, stat.S_IREAD)");

But maybe it's not necessary to unlock the file before deleting it... anyway that should be ok now.

[ionblue]

That works perfectly, thanks so much!

[ionblue]

If I send a file back and forth more than once (unless I rename it in ZBrush) I get this error and ZBrush will crash on me.