Showing posts with label PyMel. Show all posts
Showing posts with label PyMel. Show all posts

Maya Name Helpers

Hey, who likes well organized files? This guy. Who like manually renaming hundreds of objects? Nobody I've met.

I've found one of the best ways to help my art teams keep their content organized it to make it easier for them to manage their object names. I've wrapped up some of the most useful little scripts into this handy tool on Gumroad.

- Written for Maya 2019
- Batch rename multiple assets at once.
- Easily add, remove or replace elements in names.
- Quickly add or remove prefixes and suffixes.
- Easily convert between camelCase and underscore_naming
- Docks with the Maya GUI.
- Works on nodes, materials, objects. Pretty much anything you can select via the GUI.

Maya: Animation Event Definition Tool

I've been working on a new set of tools to define animation event data in Maya and export it into Unity for consumption by the AssetPostProcessor. This has been kind of a cool learning experience, because before now I really didn't have much to do with the Animation pipe, which has been an entirely manual process for the animators.

Previously clips were cut up and events were defined by hand in Unity once the .fbx files had been exported from Maya. This wasn't such a bad thing, except that the tools in Unity for defining events were very un-intuitive. The aim of doing all this was to allow the animators the ability to work in a tool they were familiar with, and get the AssetPostProcessor to do most of the boring legwork on the Unity side.

The Maya interface. 
The Maya tool is pretty simple right now, and responsive enough that the animators don't hate me. Navigating to different clips or events will move to that time range on the slider. The event list is directly correlated to events called by the engineers in engine, so they are only available as pre-set items in a drop down.

The data is stored in the scene as attributes on empty nodes. On export time, the data is compiled into dictionaries that are then written into a .JSON file named after the .fbx.

The end result is something like this:

Data for an 'Attack' animation. The first clip is the entire duration, the next three are the intro, loop and outro. In the anim events the unit fires it's weapons three times, once on frame 5, then on 9 and 13. 'Index' is used for the muzzle position on a unit or turret, as those are the only entities in game making use of the system. I would prefer to be using named bones for more flexibility. 
Once this animation is out there, the engineering team pull it into the AssetPostProcessor and generate the required clips and event metadata from the contents. 

All in all, the Maya side is pretty basic at the moment, and implemented on a project that currently has pretty basic animation requirements. Even so, the idea of feeding data into the AssetPostProcessor is something that really appeals to me, and the .JSON format has been pretty easy to write to from Python. 

Eventually I would like to be able to define custom VFX events on named bones, and mark up non-event related data like whether you want an asset to automatically generate lightmap UV's on an imported model or not. There is a lot of potential there. 

Model Monkey: Now with Configs!

I've decided to use ini files to make it easier to port my Maya exporter across different projects with as little fuss as possible, using the standard Python ConfigParser module. The last time I really played around with .ini files was to mess with Command and Conquer Red Alert, and that was some time ago. It's really awesome that the .ini file format is still worth using today.

There is a bug where you can add new file rules until the tool grows so long it is
bigger than the screen. Time to add a scroll bar...
Part of getting this to work includes creating a GUI interface to minimize the manual file editing that you might expect. Being my first major use of an .ini for a tool (I did use a teeny tiny .ini on Texture Monkey) I suddenly realized that I had to re-work a lot of my previous configuration code in order to make my tool flexible enough to be re-configurable without breaking into a million different lame parts.

BUT! It's working now, whoo! A couple of things have to be modified, but I can get info into the tool, change it, and get it back into the .ini again, rinse and repeat. In other words, I can now do what people have been doing for decades! Whoo etc. But hey, it works!


Model Monkey: A Maya Exporter

When I started on the project I have been working on for the last few months, it lacked any kind of automation or pipeline tools for the Art department. There was no kind of convention in the names, and no kind of structure to the project. It was a nightmare! Did I mention the pipeline had artists working on two different platforms? Compensating within the tools for the different folder structures on Mac and PC computers also became a concern, although it did not end up being as much of a problem as I thought it would be.

From day one it was a goal of mine to introduce naming conventions, and restructure the project to be more pipeline friendly. It was a crazy-big job, but now its starting to pay off with some art tools.

To address the lack of exporting tools I wrote a Maya exporter that takes advantage of the new naming conventions, predictable folder structure and Python's awesome ability to manipulate strings. Behind the scenes it has a dictionary that matches the scene file's prefix with the Unity project directory the exported FBX is meant to go in, as well as loading in a pre-configured fbx settings file to reduce the chance of messed up exports. 

Functionally its still fairly basic, but it has been written to be expandable as required, and portable across projects, just by editing the separate configuration file. It also has the added bonus of working across both Mac platforms and PCs. 

Maya 2014 includes Pyside, which allows access to the powerful QTFramework. With just a few lines of code, any artist has access to the same tools that would have previously required a separate PyQt4 installation. 

Tooling around- Maya Photoshop Bridge

My current little pet project to bridge Photoshop and Maya, from within the Maya environment.

The tool is in very early development stage, but currently supports project configuration and opening a selected model's source PSD from within the Maya environment.

Other neat time savers:

  • Exporting a selected model's UV map and using it to create a new PSD.
  • Calling Photoshop to export all of a model's maps from their source PSD. 
  • Renaming shaders based on their diffuse texture name.
  • linking associated known map types (eg- specular, gloss and normal) 
The tool is written entirely in Python/Pymel and uses the win32com module as a bridge. 

Various options to clean up scenes. 

The current texture tools. More to come!

Project options.


Maya, Python and Wings IDE

I've recently moved away from the Maya Script Editor for my Maya scripting and started using Wing IDE, which is great in that it has full code auto-complete, debugging support and can be rigged up to execute code in Maya straight from the IDE window using a simple server setup.

Here are a couple of guides I found handy in getting Wings to work with my Maya install:




PyMel- Getting texture file from a material

So, my first inelegant-yet-functional PyMel script is done and working. The core of it is in this little snippet here, that digs through a mesh's inputs until it finds the texture node on the surface shader:

#Pass through the mesh's shape and return a texture name. 
import pymel as pm

def getTextureFile(geo):

    sg = []

    #Get the shading group from the selected mesh
    raw_sg = pm.listConnections(geo, type='shadingEngine')

    #Rapidly check for duplicates in the list- I do this by checking each item 
    #against an empty list. 
    #If the item is not in the empty list I append it. 
    
    for element in raw_sg:
        if element not in sg:
            sg.append(element)

    #Get some info
    sgInfo = pm.listConnections(sg[0], type='materialInfo')
    fileNode = pm.listConnections(sgInfo[0], type='file')
    textureFile = pm.getAttr(fileNode[0].fileTextureName)



    print 'This is the file', str(textureFile)
    return str(textureFile)
It still leaves a lot to be desired, for instance it doesn't know what to do if a mesh doesn't actually have a texture! But, provided it does, using the win32com module I can then send the texture file information onto Photoshop and Alienbrain and open files/check out texture chains etc etc.

EDIT:
------------------------------------------------------------------------------------------------------------
Thanks to Daydreamer who pointed out the missing pymel reference at the top of the snippet, as well as other issues with the script which I am working through...

After a happy weekend of actually reading part of the official tutorial, I have a slightly better understanding of how to access a mesh's attributes and nodes using PyMel. Here is a snippet of the above snippet that does pretty much the same thing, only using the pymel connections, input and output commands. The intention is only to test the functionality.
    
    import pymel as pm

    geo = pm.ls(sl=True)[0].getShape()

    #Get the shading group from the selected mesh
    sg = geo.outputs(type='shadingEngine')

    #Work through the node to get the file texture name
    sgInfo = sg[0].connections(type='materialInfo')
    
    #It falls apart here if you have no file node! Oops...
    fileNode = sgInfo[0].connections(type='file')

    #Get the file texture name attribute's value
    textureFile = pm.getAttr(fileNode[0].fileTextureName)

    print 'This is the file', str(textureFile)

Getting Maya to talk to Photoshop

Sadly, at work I am not blessed with the latest and greatest Maya versions, and I have to be content with Maya 8.5. That also means I have to be content with Python 2.4.2 in Maya... eh. Its enough to do some cool stuff.

It has been a little pet project of mine to get Photoshop and Maya to talk to each other and share texture information (like texture file locations, etc etc) and after a bit of fussing around, and a total failure to get comTypes to work (missing ctypes module in py 2.4) I have been able to get the win32com module to work within the Maya Python 2.4.2 scripting environment.

I don't think its going to be a two way street, but it does mean I can open a model's source PSD file(s) in Photoshop from within Maya. Kinda a neat little workflow thing.

If anyone wants to share a better method give me a shout!

-Pete