Qt.pyを使ってQtDesignerのuiをMaya2017対応させる

Qt.pyとは

PySideとPySide2、PyQt4とPyQt5のコードの違いを吸収してくれるものです。
ざっくり言うと、一つのソースコードで両バージョンに対応することが出来るようになります。
fredrikaverpil.github.io

Qt.pyを導入する

PyPIに登録されているので、pipでインストールできます。

$ pip install Qt.py

Mayaで使う場合はmayapyでpipを使うなり、Githubから落としてきてPYTHONPATHに通せばおっけーです。
github.com

具体的なコード

通常PySideだとQtGuiは以下のようにインポートします。

from PySide import QtGui

Qt.pyを使う場合は、これを以下のように書き換えるだけです。

from Qt import QtGui

ただし、PySide2になってパッケージ構成が大きく変わっているので、そのあたりは注意が必要です。
たとえば、QWidgetはQtGuiの中にいましたが、PySide2ではQtWidgetsの中にいます。
したがって、QtGuiとQWidgetを使いたい場合は、以下のようにします。

from Qt import QtGui, QtWidgets
(略)
    self.horizontalLayoutWidget = QtWidgets.QWidget(Form)

QtDesignerで作ったuiをMaya2017対応させる

.uiファイルを読み込む場合は、以下のようにQtCompatというモジュールを利用します。

from Qt import QtCompat
QtCompat.load_ui(fname="my.ui")

ではpythonファイルに変換したものを使うにはどうしたらよいかというと、まずpyside2-uicで.uiを.pyに変換してやる必要があります。
pyside2が入っていない場合でも、Maya2017が入っていればMayaが持っているものを使えます。
OSXでいうと、以下のようにして.uiファイルを.pyに変換します。

$ cd /Applications/Autodesk/maya2017/Maya.app/Contents/bin
$ mayapy pyside2-uic ~/Documents/dev/qt/form.ui -o ~/Documents/dev/qt/form.py

さらに、ここで作ったform.pyをQt.pyを使って変換します。

$ python -m Qt --convert form.py
#
# WARNING: --convert is an ALPHA feature.
#
# See https://github.com/mottosso/Qt.py/pull/132
# for details.
#
Creating "form_backup.py"..
Successfully converted "form.py"

これでQt.pyで利用できるファイルが生成できました。

あとはこれを以下のような感じで読み込むだけ。

# -*- coding: utf-8 -*-
from __future__ import absolute_import, division, print_function
from maya import OpenMayaUI as omui
 
try:
    from shiboken import wrapInstance
except ImportError:
    from shiboken2 import wrapInstance
from Qt import QtGui, QtWidgets
 
from ui import qt_test
 
 
class QtTestWindow(QtWidgets.QMainWindow, qt_test.Ui_Form):
    def __init__(self, parent=None, *args, **kwargs):
        super(QtTestWindow, self).__init__(parent)
        self.setupUi(self)
 
 
def maya_main_window():
    maya_mainwindow_ptr = omui.MQtUtil.mainWindow()
 
    return wrapInstance(long(maya_mainwindow_ptr), QtWidgets.QMainWindow)
 
 
def main(*args):
    dialog = QtTestWindow(maya_main_window())
    dialog.show()

すてき…!

shibokenのところはもうちょっとなんとか出来るかもしれません。
手が空いたときにたぶん…もうちょっと…詳しく…!

【Maya】ファイルタイプからFBX Exportが消えて困った話

FBXの書き出しを以下のような感じでmaya.cmdsのfile関数を使って行っているコードがありまして。

cmds.file(path, pr=True, es=True, f=True, type="FBX export")

prフラグってFBXエクスポートのとき意味あるんだろうかみたいな疑問はありつつもそれはおいておいて、一部の環境で「FBX exportなんてファイルタイプないよ」とエラーが出てました。

プラグインマネージャを見てみるとちゃんとfbxmayaは読み込まれている。
が、fbxmayaのプラグイン情報を見ると「ファイル トランスレータ機能」の項目にたしかにFBX exportがない。
しかも再現している環境としていない環境でMayaのバージョンに違いはない。

色々調べた結果、ダイアログスタイルの設定に依存していることが分かりました。
f:id:tm8r:20170106100256p:plain
ウィンドウ>設定/プリファレンス>プリファレンス>設定>ファイル/プロジェクトの下部にあるダイアログスタイルが「Maya規定」ではなく「OSネイティブ」になっているとファイルタイプからFBX Exportが消えてしまうようです。

というわけでFBX exportをどうしても使いたい状況でそんなファイルタイプないよーと言われたらダイアログスタイルが「OSネイティブ」になっていないか確認、なっていたら「Maya規定」に戻してMayaを再起動してやれば利用できるようになります。
罠。

GAでMayaのプラグイン利用状況を計測する

f:id:tm8r:20161222010226j:plain
この記事はMaya-Pythonアドベントカレンダー2016の12月22日の記事です。

はじめに

社内で開発したMayaプラグインをアーティストさんに使ってもらう、みたいなケースにおいて、

  • どのツールがどのくらい使われているか
  • 例外がどこでどのくらい出ているか
  • どんな環境で使われているか
  • どのバージョンのプラグインが使われているか

みたいなことが分かると、改修の優先度決め、改修の影響範囲確認、サポートの終了判断といったことに役立ちそうです。

アプリの計測方法は色々ありますが、今回は個人的に使い慣れているGoogleAnalytics(GA)での計測を試してみます。

続きを読む

GoogleスライドからGASを実行する

おしごとで進捗報告のためにGoogleスライドを使っていて、URL変わるのがダルいので毎週同じスライドを更新、ただし更新前に議事録も兼ねてコピーするという面倒なフローになってます。

スプレッドシートなら簡単にGAS(GoogleAppsScript)を呼べるのでどうにでもなるんですけど、スライドだと自分が知る限りスプレッドシートのように簡単にGASを呼べないので、なにか実現する方法はないかなーと調べてみました。

Web Apps  |  Apps Script  |  Google Developers

こちらに書いてある通り、GASを使って簡単なWEBアプリケーションを作ることができるようなので、これを使う方法を考えてみます。

続きを読む

【Unity】指定したTypeを持つオブジェクトをHierarchyで選択する

あんまり使うシーンないとは思いつつ。

指定したTypeを持つオブジェクトをHierarchyで選択するエディタ拡張です。
ソースコードは以下。

gist.github.com

Selection.activeGameObjectに選択したいGameObjectを突っ込むことで、Hierarchyでこのオブジェクトをクリックしたのと同じ結果を得ることが出来ます。

インスペクタはロックされてない限りはHierarchyで選択されたオブジェクトの内容が表示されるので、インスペクタから変更することを想定したプロパティを持つTypeを指定しておけば、頑張ってHierarchyから探すことなく簡単にアクセスできて楽ちんですね。(むしろそれ以外の使い道は思い浮かばない)

エンジニアならまあ多少面倒でも目的のものを探し出せると思うんですけど、非エンジニアに使ってもらうことを考えると、この名前のオブジェクトをシーンから探し出してーとか言うのも偲びないので、分かりやすいメニューを作るなり、ショートカットを作るなり、ウィンドウを作るなりして目的のものにたどり着きやすくする、という意味ではこういうツールの需要があるプロジェクトもあるんじゃないかな(あった)と思います。

今回の実装ではTools>SelectTypeを選択、またはShift+Tで起動します。
キーボードショートカットに関しては以下を参照。
docs.unity3d.com

ざっくり言うと「MenuItem」Attributeに通常通りメニューに表示するラベルを指定し、このラベルのあとにスペースを入れて以下の規定のフォーマットでショートカットに使用するキーを指定してやればよい、という感じです。

指定 キー
%t Ctrl+t(Win) Cmd+t(Mac)
#t Shift+t
&t Alt+t
_t t

尚、今回はFindObjectOfTypeを使ってるので、同Typeが複数あった場合は先頭のものが選択されます。
同じTypeが複数存在しうるものもAlt+Tabでアプリケーションを切り替えるノリで順番に見ておきたいとかであれば、FindObjectOfTypeをFindObjectsOfTypeに書き換え、staticで結果の数とかカウンタとかを保持して順番に見ていけたりもするかもですね。そんな需要があるかはさておき。

【CEDEC2016】テクニカルアーティストにおすすめのスライド

CEDECに初参加してきました。
TAに関係がありそうなセッションとスライドのまとめです。

多文化のテクニカルアーティストチームの力の発揮の仕方

「国の文化の違い」、「プログラマーとアーティストの文化の違い」、「ゲームと映画の映像制作の文化の違い」をテーマにしたセッションです。
直接聴講したTAに関わるセッションの中では一番参考になったセッションでした。
TAという複数の職種の間に立つ職種として意識すべき「違い」が紹介されています。
それらの違いを理解した上で、TAとしては改めて以下のようなことを意識することが重要そうです。

  • プログラマー、アーティストの双方の作業や問題点を理解し、溝を埋める
  • アーティストの要望は真意を探り、プロジェクトで使えるものに落としこむ

CEDiLのセッション情報
スライド

世界で戦うソフトウェアエンジニア ~アカデミー賞受賞ツールMARIの開発現場から~

まだスライドが公開されてないんですけども。
3DペインティングツールのMARIを開発したエンジニアさんによるセッション。
MARI | 3D Texture Painting Software | The Foundry

エンジニアって新技術を使ってみたくなりがちだと思うんですけども、それがどんなに素晴らしいものであっても使ってもらえるものでないと意味がなくて、問題解決のツールとして落とし込むことが重要といったお話がありました。
また、エンジニアがユーザー(TAとしてはアーティストさん)と話すときは以下のようなことを意識するとよいとのことでした。

  • 要点を絞る
  • 技術的に細かいことは話さない
  • 問題の解決法を明確にする
  • ソフトを使ってくれることに感謝する
  • 情報を共有してくれることに感謝する

今世代向けプロダクションにおけるアセット製作のための、Mayaへのエンジン組み込み

MayaのViewport2.0をカスタマイズする話。
同内容に関して連載も始まってるみたいです。
area.autodesk.jp

また、サンプルプロジェクトもGithubで公開されています。
github.com

CEDiLのセッション情報
スライド

増やせ!アーティストMELスクリプター

スライドはまだ公開されてないんですが、タイトルの通りMELを書けるアーティストを増やしてみたよというセッション。
MELの学習を推奨したものの、個人(独学)だとうまくいかなかったので、講習会を開いたようです。
また、この講習会では一旦命名規則やファイルのディレクトリ構成、制御構文といったとっつきづらいところには触れず、まずドキュメントの読み方を教えた上で(特に実装例を見てみるなど)、Maya上で実行することで結果がすぐ見える形で進めたとのことでした。
学習→課題→評価という小さいサイクルを繰り返し、できたという感覚をつけてもらうのは初心者にとってはモチベーションが保ててよさそうです。
また、forといった制御構文を後回しにし、こちらはコードを書いてボタンを押すと勝手にシーン上のオブジェクトに繰り返し処理するMaya上で動くツールを提供した、というのはなるほどなと思いました。

この講習を終えたあと、希望者だけ次のステップに進み、最初飛ばした各種規則や制御構文に関しても講習を行い、あわせてサイクルを計画→作成→検証→改善のように変えることでツール制作が出来るような形に変えていったとのことでした。

Technical Artist Bootcamp 2016 vol.1

「プロジェクト配属型TAとしての働き方、組織活動の実例とツール開発のヒント」と「自作Mayaレンダラーの作り方 」についてのセッション。

CEDiLのセッション情報
スライド

Technical Artist Bootcamp 2016 vol.2

「Unityゲーム開発パイプライン事例紹介」と「続・Pythonを中心としたチーム開発」についてのセッション。

CEDiLのセッション情報
スライド

ゲームにおけるインタラクションのための音楽技術「MAGI」~瞬間、波形、重ねて~

インタラクティブミュージックと、それを柔軟に実現するためのMAGIというシステムに関するセッション。
直接的にTAと関係があるわけではないんですが、インタラクティブミュージックという制約がかかりがちなクリエイターによっては難色を示すような形態の音楽を、クリエイターの視点に立ってその制約を取っ払うような柔軟な設定ができるシステムの提供によって実現するという点は多分に学ぶところがあるなあと思いました。

CEDiLのセッション情報
スライド

まとめ

初日の基調講演も含めて、今回のCEDECでは以下のようなことを改めて意識しないとなーと思わされました。

  • 「違い」を理解すること
    • アーティストとエンジニアの感覚の違いなど
  • ツールのユーザーを理解すること
    • 一度ユーザーの立場で仕事をした方がより求められているものを求められる形で提供できる
  • 適切にコミュニケーションをとること
    • お互いの理解や、適切な分業をもたらし、それぞれが集中できる時間を増やすことにも繋がる
  • 重要な部分を兼任にせず専任にすること
    • 必要に応じて横軸の組織にすることでナレッジを生かしやすい
  • 新しいことに価値があるのではなく、役立つことに価値がある

スポンサーリンク