Maya Python Libraries

maya.cmds 並不是 Maya 的 API, 而是 Maya MEL 指令的 binding. 在概念上 MEL 是高層次的, 功能更接近 artists 會做的事. 而 OpenMaya 則是從 Maya C++ API 產生, 有更多底層的指令.

舉例來說 cmds.polyevalute 就沒有對應的 OpenMaya 指令或類似的功能, animation layer更是完全用 MEL 和 cmds 實作. 反過來說, 透過 Python API 的 OpenMaya.MDagModifier.renameNode 來更改物件名稱可以直接 bypass 被 cmds.lockNode 鎖定的 node.

Python API 1.0 vs 2.0

Maya Python API 有兩個版本, API 1.0 & 2.0
1.0 的功能涵蓋範圍更廣, 語法更接近 C++.
2.0 更 Pythonic, 所使用的物件更容易以 Python 的方式操作, 效能一般來說更好, 但缺少了許多 API 1.0 有的功能和物件(e.g. MIt iterators).

string vs object

maya.cmds 的回傳值和節點的 argument 幾乎都是字串, 而物件本身的名稱會隨著操作改變, 在編寫的過程需要不停地重新取得節點或屬性這些操作物件的名稱. OpenMaya 則是以物件為主不會有這個問題.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

import maya.cmds as cmds
import maya.api.OpenMaya as om2

# maya.cmds
null1 = cmds.group(em=1)
group1 = cmds.group()
group2, null2 = cmds.duplicate(group1)
cmds.select(null1)
# ValueError: More than one object matches name: null1

# Maya在複製 parent 物件的時候, descendents 就可能會發生名稱重複
# 在執行 null1 = cmds.group(em=1) 的時候我們取得的 null1 實際上是
# string, immutable, 所以當我們要選取這個物件的時候 一開始取得的名稱已經
# 無法執行操作了, 要用 partial or full path name 才能找到正確的物件.
# i.e.

null1 = cmds.group(em=1)
group1 = cmds.group()
group2, null2 = cmds.duplicate(group1)
# goup2 在上面的操作中是最上層的物件, 所以取得的 name string
# 會是 unique name. 在下面的 listReative在使用這個
# unique name 去重新取得子物件的 full path name(避免重名).
children = cmds.listRelatives(group2, fullPath=True, child=True)
cmds.select(children)

語法

前面提到 maya.cmds 是 MEL 的 binding, 所以 maya.cmds 的語意上會更像是不停地對物件下操作的指令, 沒有像 OpenMaya 那麼物件導向.

和 Python API 2.0 相比 API 1.0 更像 C++ 的語法. 舉例來說, API 1.0 常需要把物件傳遞到指令中處理, 而不像 API 2.0 Pythonic 的方式那樣物件直接回傳.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 拿取得物件的 mobject 為例
import maya.OpenMaya as om  # Python API 1.0
import maya.api.OpenMaya as om2  # Python API 2.0

node_names = ["persp", "side"]

# 1.0
sel_list = om.MSelectionList()
for name in node_names:
    sel_list.add(name)
side_mobj = om.MObject()
sel_list.getDependNode(1, side_mobj)

# 2.0
sel_list = om2.MSelectionList()
for name in node_names:
    sel_list.add(name)
side_mobj = sel_list.getDependNode(1)

# Python API 1.0 要先 init 一個 MObject, pass 給 getDependNode,
# MSelectionList.getDependNode 在改變這個 MObject.
# 在 Python API 2.0, getDependNode 就直接回傳了 side 的 MObject.

穩定性

不管是 maya.cmds 或是 OpenMaya 都有很多 API 設計上的缺陷, 像是不一致的操作邏輯, 變動而不合理的回傳資料類型, exceptions 種類太少導致難以準確的抓取錯誤.

在熟悉 API 指令和 Maya 本身運作邏輯的清況下兩者的穩定度應該是一致的. 但在現實製作環境, 大部分開發者對 OpenMaya 的熟悉度遠低於 maya.cmds, 使用 OpenMaya 就會比較容易遺漏掉需要處理的例外狀況而導致程式不穩定.

另一個因素則是 maya.cmds 在設計上常有額外的防錯機制, 當操作無法達成的情況下有時會有 fallback 的邏輯來完成, 甚至是直接略過某些錯誤. 這樣的行為模式會造成 maya.cmds不夠"準確", 但在大部分使用者都習慣 Maya 操作邏輯的情況下, 這種半自動的 error handling 的確能在達成使用者的目的的同時又能減少程式報錯的機率.

效能

大多數情況 OpenMaya 的效能遠高於 maya.cmds, 但 maya.cmds 內建支援 undo, 而 OpenMaya 需要使用者自己實現 “undo” 的方法, 開發時間更長, 在 pipeline 日常的支援工作裡, OpenMaya 會更適合 non-interactive 的環境, 或用來取得資訊而不是執行操作.

混用

有些開發者認為在同一個 module 中不應該同時混用 Maya Python API 和 maya.cmds. 有很多種說法, 像是要減少使用的packages/modules, 兩者語法不同造成閱讀困難, 兩者的設計邏輯不同會混淆讀者對變數的解讀等等. 我是覺得最終目標還是用程式碼做了什麼, 這樣使用的需求和效益是否高於撰寫時的概念, 單純把coding style and practice 無限上綱有點本末倒置, 更不用說這些理由在整個 Python 生態圈都不太成立.