Anyone moving to maya 2015?

Pipelines
#1

If so, is it an easy upgrade?do things compile without issues?Did they bump pyside/python versions?

#2

Compiler is now VS2012. Python and Qt are minor upgrades and my .pyc seemed to load fine. Some BIIIIIGGGG improvements that are making us want to upgrade as soon as possible - even though we just made the move to 2014 - after all the issues with that one.

#3

2014 was a pain, i’m hoping 2014->2015 is painless(ish)

#4

Care to elaborate?

#5

Please go to the Autodesk site and you can watch for yourself. It’s better than describing it here.

#6

Oh, I’ve seen the videos, I was just curious what stuff had you interested.

#7

The release notes were released recently too
http://download.autodesk.com/us/support/files/maya_2015_assets_checklist/Maya2015_Readme_enu.html

#8

I wonder if this will require recompiling the win32 and PIL modules again…

#9

I think it does… they went from VS2010 to VS2012? no?

#10

Hey

I’m trying to test our tools on Maya 2015 right now, the problem I’m having is that it appears the P4 plugin / P4API.pyd isnt supported in 2015 yet ( I’m going from 2013 > 15 - so no idea if this is working in 14 either. )

Anyone got any ideas?

Cheers

Joe

#11

Hmmm

this version imports & I’ve got communication with Perforce ( yay ) - Doing complete test of all our tools now :slight_smile:

http://www.youcandoitvfx.com/p4python-for-3ds-max-2015-maya-2015/

If i understand “you can do it!” correctly - am i right in saying that Perforce need to release a new version of their API for Python 2.7?

{ Maya broke binary compatibility with previous versions, making the P4API for Python 2.7 no longer compatible with Mayas Python 2.7? }

#12

P4Python just uses the C++ project under the hood. Their expectation is that you will download the source and compile it for the flavor of Python you are using. Yeah, they could make it easier, but they do “release” it.

#13

Cool thanks for the clarification :slight_smile:

#14

something to look out for if you plan on upgrading to 2015.

PySide 1.2 has a crash bug related to QSelectionModels.

#15

Here’s a nasty 2015 but to watch out for:

cmds.ls now crashes on bad characters in an object name, which is a new behavior that can break lots of old scripts.

Patch here

#16

It’s a good thing no one uses the ls command…

#17

Or you could write your own Python wrapper that calls the standard P4 commands via subprocess module. The P4 command is well documented and seems stable over time.

def __callCommand(self, args):
‘’’
executes external system command using subprocess
This is essentially like using os.system, but allows you to use subprocess.PIPE to pipe the output back into variables for use here
‘’’
piped = {}
process = subprocess.Popen(’{0} {1}’.format(self.p4Command, args), stdin = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.PIPE)
piped[‘stdout’], piped[‘stderr’] = process.communicate()
return piped

#18

Yeah, we have a bit of this in house. It’s fine for simple commands. They’ve put quite a bit of effort into the the C++/Python support though. For instance, editing changelists and other “forms” through their API is done on a dictionary of fields returned by the libs. Editing forms from the command line is pretty awkward and it would take a fair bit of effort to come up to their level of completeness.

#19

And the usual question:

“Moving to 2016?” Have P4API.pyd compiled for it yet?

#20

on that note, i am developing a perforce wrapper in python that uses processes only, no compiled extension. I’m trying to make it as pythonic as possible. Is this something you guys would be interested in? I keep hitting the wall of “is this even worth it?”

I’d love to move to 2016, though. Building extensions shouldn’t be too difficult