2013年1月15日火曜日

SoftImageと3DSMAXのエクスプレッション/スクリプトコントローラー対照表 その2

スクリプトコントローラーではスクリプトコントローラーオブジェクトにdependsOnでコントローラーを割り当てる他に、
特定のオブジェクトノードを指定して、そのtransformの更新をリアルタイムにスクリプトコントローラーオブジェクトに反映する方法があります。

MAXScriptヘルプの ノード変数

AddNode <&TSTR>Name Node

と書かいてある部分がそれですが、具体的には

$dummy_a.pos.controller.X_position.controller.AddNode "Node_0" $dummy_b

のように書くようです。
  • $dummy_a.pos.controller.X_position.controllerはオブジェクト内にあるスクリプトコントローラーの場所です。
  • .AddNode "Node_0"でスクリプトコントローラー内にNode_0という名前でノードが登録されます。
  • $dummy_bはこれが動くとスクリプトコントローラーがリアルタイム更新するオブジェクトです。

dependsOnと違って使用するスクリプトコントローラーが入っている正確な位置を特定して書かなければならないため
メンテナンスを考えると頭が痛いような気もしますが、Max8以降はdependsOnに変わって.AddNodeでの指定が推奨のようです。
dependsOnはMax9~Max2012でも一応挙動するので、特に循環従属問題等でエラーが出なければ、対応している間はこちらを使うのもありかもしれません。

前述のヘルプ内では

ノード変数はシーンノードの参照を含有します。参照は名前に従属しないため、変数に格納されたノードの名前を変更してもスクリプトコントローラの動作は影響されません。

とありますが、実際のところリグ等でパス名リテラルを使ってオブジェクト名を管理する方法をとると、うまく行かないので注意が必要です。
一応下にSoftImageと3dsMaxでの挙動説明など書いてみました。

挙動説明 SoftImage
(Expression)
3DSMAX
(ScriptController)
  • null_bのローカルX軸位置を動かすと
    null_aのローカルX軸位置が追従する
  • dummy_bの親X軸位置を動かすと
    dummy_aの親X軸位置が追従する
null_b.kine.local.posx pass_dummy_a = ""
objname_dummy_a = execute("$" + pass_dummy_a + "dummy_a")
pass_dummy_b = ""
objname_dummy_b = execute("$" + pass_dummy_b + "dummy_b")

objname_dummy_a.pos.controller.X_position.controller.AddNode "Node_0" dummy_b

objname_dummy_b.inode.posInParent.x


2012年12月31日月曜日

SoftImageと3DSMAXのエクスプレッション/スクリプトコントローラー対照表 その1

自分が今まで色々3DDCCツールを使ってきて、毎回悩む分野の一つにコンストレイント、エクスプレッションやスクリプト等の習得がありました。

この領域はデータ作成の効率化とかに直接関係してくる部分ですが、その分ツール作者達の思想に近い部分でもあるので、ちょっと敷居が高いなと毎回思います。
スクリプトについては、最近各ツール共pythonを使う方向なので、その流れでいずれ統合できるようになって欲しいものです。
最近3DSMAXに触り始めて運良くいろいろ学べ、またいくつかGoogle先生に必死こいて教えてもらった事柄もありましたので、そういった部分をちょこちょこまとめてみます。

とりあえず今回はRigやFカーブ系で使うことの多いエクスプレッションを書こうかと思います。
どう簡潔に書くか悩んだ末にSoftimageと3dsmaxでよく使うエクスプレッション/スクリプトコントローラーの対照表を作りました。

3DSMAXのスクリプトコントローラについては無駄に長々と書いてあるように見えますが、表の後にエクスプレッションを書く時に必要な補足があるので読んでみてください。


挙動説明 SoftImage
(Expression)
3DSMAX
(ScriptController)
  • null_controllerのローカルX軸位置を動かすと
    nullのローカルX軸位置が追従する
  • dummy_controllerの親X軸位置を動かすと
    dummyの親X軸位置が追従する
null_controller.kine.local.posx pass_dummy_controller = ""
objname_dummy_controller = execute("$" + pass_dummy_controller + "pass_dummy_controller")
dependsOn objname_dummy_controller
objname_dummy_controller.inode.posInParent.x
  • null_controllerのローカルX軸回転を動かすと
    nullのローカルX軸回転が0以下で追従する
  • dummy_controllerの親X軸回転を動かすと
    nullの親X軸回転が0以下で追従する
MIN(0,null_controller.local.rotx ) pass_dummy_controller = ""
objname_dummy_controller = execute("$" + pass_dummy_controller + "pass_dummy_controller")
dependsOn objname_dummy_controller
degToRad( amax #( 0, obj_dummy_controller.inode.rotInParent.x))

//補足
1) 3DSMAXは同一シーン内で同じ名前を付けられます。(モデルIDなどで個体判別は可能です)
2) 3DSMAXでは、スクリプトコントローラーの埋め込まれたオブジェクトの挙動が、どのオブジェクトが動くと再計算されるか明示的に指定する必要があります。

3) SoftImageのローカル座標系は3DSMAXでは傾き自体はローカル座標系数値は親座標系でみます。

補足1)は Rig等で同名オブジェクトを持つ構造体を同一シーンに読み込んでくる際に厄介です。
SoftImageは名前が同一でない前提でエクスプレッションを組 めますが、3DSMAXで同じ事をやると先に読んだRigの右足を動かすと後に読んできたRigの右足まで一緒に動く等の不具合が出ます。
問題回避のために、3DSMAXではパス名リテラルを使用して個体判別を行うことができます。

補足2)はコントロールする側のオブジェクト宣言で、スクリプトコントローラ内に dependsOn $オブジェクト名 と書きます。

スクリプトコントローラでは他にも指定方法がありますが、これが一番簡単だと思います

//例示

下記構造体のr_heelの親X位置をr_heel_controllerの親X位置で動かしたい場合、スクリプトコントローラーには次のように書きます。


pass_r_heel_controller = "c_hip01/"
obj_r_heel_controller = execute("$" + pass_r_heel_controller + "r_heel_controller")
dependsOn obj_r_heel_controller
obj_r_heel_controller.inode.posInParent.x

1行目はr_heelの親までのパス名リテラルを入れる変数と捉えてください。
2行目はパス名リテラル入りのオブジェクト名です。これでオブジェクト名確定す。execute()は文字列をオブジェクト化します。
3行目はコントロールする側のオブジェクト宣言です。
4行目でスクリプトコントローラの実行部分を書きます。

ち なみにパス名リテラルはすべてを省略せずに書かねばなりません。

MAXスクリプトではこれを省略できますがスクリプトコントローラーではできません。
この構造を複数別々扱いたい場合は一番上のノード名"c_hip01"を "c_hip02"などと変更してからスクリプトコントローラ内の対象文字列もすべてそれに書き換える必要があります。
また文字列ノードはツリー全部を直書きするので、Rig等エクスプレッションを多数扱う構造体を複数同一シーン内に配置する場合
 スクリプトコントローラ内の文字列を自動で書き換えるスクリプトの支援が必須になると思います。
//



参考文献 : 
Softimage SDK プログラミング ガイド
エクスプレッションによるアニメーション
エクスプレッション関数リファレンス
3DSMAXスクリプトヘルプ
パス名リテラル
スクリプト コントローラ用 dependsOn
インタフェース : INode
文字列値
Number値
コレクションのタイプ

2012年9月17日月曜日

SoftImageでpythonのモジュールが動かない場合に試して見ること

SoftImageのPythonと別個にモジュールを追加した場合、そのままスクリプトでモジュールを
importしても読み込みエラーが起こることがあります。

その場合にはモジュールを追加した場所をsys.pathに登録してやるとうまくいくかもしれません。
私の場合はPythonの画像処理系ライブラリ(PIL)のモジュールImageGrabを使おうとしてエラーになりました。


その時は以下のスクリプトを使って解決しました。
sys.pathの中身を覗き、PILをインストールしているディレクトリがなければ追加する、というものです。
AppendPathは、PC環境やワークグループなどに応じて書き換えてみてください。


import sys

AppendPath = "C:\\Python26\\Lib\\site-packages\\PIL\\" #モジュールのインストール場所
SystemPaths = sys.path

for SystemPath in SystemPaths:
 List = []
 if SystemPath == AppendPath:
  List.append(1)
 else:
  List.append(0)

if 1 in List:
 print ("Already added : " + AppendPath)
else:
 SystemPaths.append(AppendPath)

print SystemPaths

2012年8月27日月曜日

CEDEC2012 バイナリードメイン関連の講演についてまとめ

2012/08/22 ご縁がありましてCEDEC2012へに行って来ました。その中でSEGAの龍が如くチームが作り上げたゲーム[バイナリードメイン]の開発システムが、少人数で大規模開発をまわすというとても野心的なものでした。
講演後幾つかゲーマー向けのサイトを覗いてみたのですが、SEGAが行ったこれらについてはどこも詳細を説明をしていないようでしたので、こちらでメモ書きした部分などを公開させて頂きます。
自分自身ゲームの開発者サイドにいるとはいえ、個人がメモ書きをしたものを記憶を頼りに書き起こしています。
一連の講演は開発プロジェクト自体ががSoftImageを使うこと前提で発信していましたが、MAYAでも似た構造の基盤を開発可能だと思われます。3DSMaxでは少々きついところがありますが、その点もご留意ください。

ちなみにこの記事はSEGA公式ではありません。
また間違っていること、情報を端折って書くことでわかりづらい部分などが大いにあります。
元々の講演自体がかなりゲーム開発の中でも専門的な事柄になりますので、その点ご了承ください。

以下、箇条書きでの講演内容のメモ書きになります。誰かの役にたちましたら幸いです。

■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■
08/22    16:30-17:30
セッションタイトル   バイナリードメインにおけるモーションワークフローの作り方
講師         株式会社セガ 白子路央(モーションディレクター)
                       麓一博(テクニカルディレクター)
                    豊田卓也(モーションリーダー)
■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■

セッションの詳細記事はこちらで
CEDEC2012    :http://cedec.cesa.or.jp/2012/program/VA/C12_P0077.html
参考資料     :http://www.youtube.com/watch?v=2auSoB5gRTw

・バイナリードメインの正規モーションスタッフは3人
・プロジェクト当初からロボットが壊れる、また壊れたらそれに合わせてモーションが切り替わるなど1体につき数
 百のモーション作成する必要があったため、かなりの作業を自動化するための環境構築がマストだった。
・最終的にはかなりの部分を自動化でき、それにプラスして、モーションをある程度作ったら重要部位以外の
モーションは実機上で自動生成するようにプログラマにお願いし、挙動をSIシーン上である程度作ったら、そ
れを基に再現実装してもらった。
・たった一人でロボット33体分のRIGをどう管理するか。またモーション実作業者のヒューマンエラーを排除する
かを念頭に環境を構築した。
・プロジェクト途中で必ず起こるRIGの変更を自動でSIシーンへ適用する環境を構築する必要があった。

・作業環境構築に6.5ヶ月。白子と麓が話しあいながら環境構築の規模感などを話し合いつつ、最初の1ヶ月
で週3日づつかけて基盤+運用プロトタイプを麓が一人で作成し、それを白子が引き継いで改定しながら運用
しつつ完成度を高めていった。

・作業環境の基盤を構築した麓は次の作業を行った。
    ・白子と話しながらプロジェクト運用に必要な基盤をどう作るか、技術的な問題点などを洗い出して実装
     内容を検討した。
    ・スクリプトベースのRIGを作るための命名規則などの仕様決めなどモーションリグ環境の下地。
    ・素材の大量処理に対応できるよう、各種データや情報をSIワークグループ上に配置してサーバーから共
     有環境として投下するような環境づくり。
     ※各種データ → プラグイン/スクリプト/webページ上での管理データベース/モーションクリップ/シェーダー
      プリセット/SIシーン起動時に共有されるカスタムパラメータ/キャラクターの基本RIG構造
    ・カットシーン用SIシーン内にある各種データに対して編集/変更があった場合に、カットシーンを開いたら
     自動でバージョンアップできるような支援環境づくり。
    ・SIシーンを開くと、シーン内のRIGと比較して自動で最新のものに差し替える機能の作成/運用
    ・知的財産を守るためのスクリプト/プラグインの分散化仕様作成
    ・モーションテンプレートの作成

・運用部分を担当した豊田は実作業に時に発生した諸々に対応した。
    ・キャラクターのバージョン管理
    ・キャラクターにあわせて実際のRIG作成、RIGのバージョン管理及びキャラクター変更への対応。
     RIGを変更する際にVBSで変更部分を書き、それをメールで周知後、サーバー(SIワークグループ)経由で
     モーション作成者に意識させることなく修正した。
    ・実作業に伴って要請のあったVBS支援スクリプトの作成
    ・カットシーンのモーション作成及びカットシーンやサイクルモーションのディレクション
    ・RIG用プロジェクトパスの設定とスクリプトコマンドの共有環境作成
     これをSIシーンへカスタムパラメータとして仕込むことで、外注先へモーションを発注する際に、ドライブレターを
     共通にするなどの煩雑な仕様を作らずに済んだ。
    ・ポリゴンモデル/骨/RIG/シェーダー/ライト/カメラ、などすべての素材をプロジェクト独自のモデルインポーターを
     作成して対応した。
     SIのシーンリファレンスはシーンデータのクラッシュなど深刻な問題を引き起こすのでこのプロジェクトでは実
     体シーンをいじるようにしてもらった。
    ・SIシーンを開くときにはキャラの大きさ(主人公基準からのスケール)などのデータベースを参照して適正なも
     のかチェックしてヒューマンエラーを防止した
    ・SIシーン内のレイヤーとパスを適切にするスクリプトでPC環境の相違吸収し、作業に集中できるようにした。
    ・サーバー上のエクセルで最新のキャラスケール/カメラ/レイヤー/シーンネーム等を確認/変更できるようにて
     作業を効率化した。
    ・エクセルから最終モーションの出力とモーション動画の自動作成、モーションリストを作成できるようにしてPC
     前にいない時にでもPCを動かしておけるようにした。
    ・エクセルで作業者のスケジュールも管理していて、作業者がエクセルを閉じると作業量と各種リンクの更新が
     行われるようにし、データ更新時の煩雑性を極力抑えるようにした。
    ・作業者以外はプロジェクトweb上でキャラクターの各種情報/モーションリスト/モーション動画を参照してシーン
     チェックや作業者へのフィードバックを行った。

■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■
08/22    17:50-18:50
セッションタイトル    バイナリードメインのボディリグ・フェイスリグの構造と実機との連携
講師            株式会社セガ 麓一博 豊田卓也
■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■-■
セッションの詳細記事などはこちらで
CEDEC2012                :http://cedec.cesa.or.jp/2012/program/VA/C12_P0078.html
音声解析システム(Clipper)    :http://www.cri-mw.co.jp/product/lineup/recognition/criclipper/index.html

◆ボディリグについて
    ・SIのディスプレイインフォとコントローラーで表示する情報を振り分けた。
    ・ディスプレイインフォでは主に各コントローラーの数値情報/ロールのプロキシパラメータ/ブレンド値を
     制御するようにした
    ・各種コントローラーはディフプレイインフォで表示をON/OFFできる用に作成した。
    ・実際のモーション作成はコントローラーを使って行うようにした。

◆フェイシャルリグについて
    ・各部の肉の動きはnul+スキンでコントロールした。まず各部のnullを使って表情(喜怒哀楽驚)をキャラクター
     毎に作成してからプリセット化、それをフェイシャルコントローラーでミックスする構造とした
    ・フェイシャルコントローラーはオブジェクトビューで操作するようにした。また少ない手数で左右のバランスを良
     い感じに崩せるよう、制御nullをLRで分け、表情を変えられるようにもした。
    ・フェイシャルコントローラーは表情/視線と目周辺/頬周辺/口周辺/母音制御/各部の皺をそれぞれ制御する
     構成にした。
    ・口~頬周辺については音声解析ソフト(Clipper)によってモーションを自動化できるよう母音制御や皺と
     ある程度と連動するようにした。
    ・視線などは視線の先にコントローラーを配置し、そちらでも視線を動かせるようにした。また目周辺の動きを
     自動追従0~100%で変異きるようにした。
    ・皺はSIのRealTimeビューを使って頂点変形+ノーマルマップで表現した
    ・それぞれのコントローラーで付けたモーションは最終的なnullに全て加算されて反映されるようにした。

    ・フェイシャルモーション作成する場合の流れ。
        ・フェイシャルの基本サイクルモーションを作っておき、音声がない時はそれを再生する。
         小鼻の動きなど、ちょっとした部分の動きはこのサイクルモーションで少しづつ動かしておき、顔のどこも
         一定にならないようにしておく。
        ・音声解析がある場合はそれを使って荒モーションを作る。
        ・フェイシャルコントローラーで喜怒哀楽驚のどの程度か決める。
        ・顔や視線を動かして見ている方向を決める。
        ・口/頬/眉毛/シワ等で付けたい表情を細々つけていく。
        ・実機に出力して確認
        ・FIXしたモーションをエクセルで出力するとモーション動画とバージョンが自動アップされる
        ・モーションアップ後、web上に出力した各種データがフェイシャルのページに反映されて製作者以外は
       そこで確認した

---------------------------------------------------------------------------------------------------------------------------------
以上

ではあんまりなので、ちょっと当日書いたメモ書きや自分の今までの仕事などから再構成したフェイシャルリグの外装やワークフローを画像に起こしてみました。
もしかしたらオブジェクトビューの構造体に眉毛とかの上げ下げも入ってたかもしれません・・・。
細かい部分は超怪しいところですが、大まかには外れてないと思いますので、思考の一端には
なるかと思います。
この男が何なのかとかはSI使ってる人には説明不要ですよね?なのでリグの形自体もそういう
ことですのでいろいろお察しください。

 ↓↓↓下の画像を別ページで開いてもらうと大きなものになります。 ↓↓↓
http://fc01.deviantart.net/fs71/f/2012/239/f/8/facial_rig_system_in_cedec2012_by_kotobukimansaku-d5cmyzw.png

あまり拡大できない場合は↓↓↓のリンクを開いてみてください。
http://fc01.deviantart.net/fs71/f/2012/239/f/8/facial_rig_system_in_cedec2012_by_kotobukimansaku-d5cmyzw.png

全般的に見て、バイナリードメインのフェイシャルシステムは、複雑になりがちなフェイシャルアクションをどう簡略化するか、またそれと反して時間をかけて細かく調整を利かすにはどうするか、をよく考え洗練していったものだと思いました。
音声(母音)解析による口周りのベースアクションを基にして、プリセット化してある表情/母音/皺などを加算して行く手法は、ここ最近の大規模開発には欠かせないものでしょう。
規模感から言えばシンプルでしたが、過不足なく色々な状況に適応できるとても学ぶところの多いシステムづくりだと思いました。
SoftImageのワークグループや独自のビュー関連を巧みに使ったフェイシャルシステムは、 ゲームの面白さとは直接関係ないかもしれませんが、ワクワクさせてもらいました。

この場ではありますが、CEDEC2012で惜しげもなくいろいろな開発情報を開示して下さったバイナリードメイン開発者の方々に感謝したいと思います。
ありがとうございました。

2012年6月16日土曜日

pythonでバイナリファイル はじめの一歩

file = "G:\\test.bin"

# -*- coding: utf-8 -*-
import struct

print u"先ずは先頭から順番に読み込む"
f = open(file, 'r')
print '1. signed char (1): %s' % struct.unpack('<b', f.read(1))
print '2. unsigned short (2): %s' % struct.unpack('H', f.read(2))
print '3. char[3]: %s' % struct.unpack('3s', f.read(3))
print '4. char[9]: %s' % struct.unpack('9s', f.read(9))
f.close()

print u"tupleへ一気に格納することも可"
f = open('hoge.bin', 'rb')
data1, data2, data3, data4 = struct.unpack('<bH3s9s', f.read())
print '1. signed char (1): %s' % data1
print '2. unsigned short (2): %s' % data2
print '3. char[3]: %s' % data3
print '4. char[9]: %s' % data4
f.close()

とりあえずバイナリファイルも読め無いと行けない時代に突入しそうなので
時間見つけて訓練してみようと思います。

2012年5月19日土曜日

3dsmaxでfbxからbipedへモーションを移植する方法 その2

今回は、[3dsmaxでfbxからbipedへモーションを移植する方法 その1]で設定したファイルを基に
実際にbippyを使ってbipedへモーションを移植するフローを書いてみます。



今回テストした環境は↓ですので、Windows7や他のバージョンのbippyだと別挙動かもしれません。
OS : WindowsXP SP3(32bit)
DCC: 3dsmax2010日本語版
bippy : 1.97

01 まずbipedに対応した骨構造を持つfbxファイルを読み込みます。bipedの骨構造は背骨など各
関節数、尻尾やポニーテールなどが付属で付く可能性がありますが、そのあたりはbippyがうま
く処理してくれます。骨の親子構造が合っているか確認し、違っていたら骨構造を処理元のDCC
ツールであわせてから再度読み込みます。


02 fbxファイルを 読み込んだらbippyスクリプトを起動します。
先程記述したBipedとFBXの骨構造を関係付ける設定ファイルを
Load Definisionから読み込みます。各骨の名前がファイルと同じか確認し、必要なら修正します。


03 次に、最初に3dsmax上で作ったbipedのfigファイルを指定します。これをしないと腰から下の
bipedがきちんと対応ファイルを設定しているのにうまくコンバートされない場合があります。
骨構造が同じ場合、3dsmax上でbipedを新規で作ってからfigファイルを出力すれば使えます。
身長や腰の位置、肩の位置はなるべくその骨の通常ポーズ時のものに合わせておくと精度が
上がります。、またfbxで入っている骨数やポニーテールなどのオプションが入っているかどうか
しっかり確認します。



04 リストを比較して、リスト左側の*のついた必須項目に対応する名前が右のFBX側にきちんと
入っているのを確認したら、ウィンドウ下のGO!ボタンを押します。


05 うまく行ったでしょうか。肘や膝の位置など、多少再計算の途中でぴったり同じにならない部分
がありますが、概ねモーションデータが渡っていると思います。ここからさらに精度を上げる場
合、figファイルの体型を、基になる体型により近づけるのが良いでしょう。


以上


次回はこれまでの一連の流れを使い、

bipd[3dsmax] ⇒ SIでRIGにアタッチして編集[softimage] ⇒ biped[3dsmax]

のフローを書きます。

2012年5月7日月曜日

3dsmaxでfbxからbipedへモーションを移植する方法 その1

2012年4月現在,3dsmaxで使用する機会の少なくないbipedですが、
最初bipedで作成したモーションをfbx経由で更に外部で編集後、再度bipedへ戻す
フローには、Bippyなどのインポート支援スクリプトが必要です。
今のところ日本語検索だとそれ関係の記事が見つからないのでちょっと書いてみます。


bippyがどんなスクリプトかは次の動画を見て下さい。


今回は、Bippy v1.97をダウンロードしてユーザー定義ファイルを作成するまでを書いています。

※骨名、階層構造、初期値(いわゆるバインドポーズ)の各回転値(Rotation)はbiped準拠
しているか、コンバート可能な近しいものとして説明しています。


今回テストした環境は↓ですので、Windows7や他のバージョンのbippyだと別挙動かもしれません。
OS : WindowsXP SP3(32bit)
DCC: 3dsmax2010日本語版
bippy : 1.97

01 まずはここから。必要なzipファイルがダウンロードできます。
http://www.geoffsamuel.com/Project_Files.php?proj=6


02 zipを3dsmaxのスクリプトフォルダ(C:\Program Files\Autodesk\3ds Max 2010\scriptsとか)で
解凍するとbippyフォルダとBIPPY - v1.97.msができます。
またStartupフォルダ内にBIPPY - Startup.msができていると思います。


03 その後3dsmaxを起動すると、環境によってはエラーが出るかもしれませんが、エラーの内容を
見て対処します。たいていはアイコンが所定の場所に無いとか言われるようなので、3dsmaxの
インストールフォルダ以下を検索して所定の場所にコピーして再起動してやります。
うまくスクリプトが入ると3dsmax画面の左方向にアイコンが出来ています。
次回からここでbippyを起動すると作業が早くなります。

画面が狭くなって嫌な場合は、スタートアップから先ほどのスクリプトを外します。
その場合、bippyを使うには画面右のUtilityパネルから[maxスクリプト]ボタンを押して
更に[Runスクリプト]ボタン、 BIPPY - v1.97.msを選択してスクリプトを起動します。

04 スクリプトを起動するとこんなウィンドウが出てきます。
出たウィンドウのStandard Setting内にあるListで、ボーンを選択後クリックすると登録できます。
ここは3dsmax上でやると、一度に一つずつしかボーン登録できずに面倒ですが、一度関連づけ
れば関連付けファイルを保存できるので、我慢してすべてのボーンを関連するbipedと関連付け
登録を行います。 保存したユーザーファイルは
 C:\Program Files\Autodesk\3ds Max 2010\scripts\Bippy\User Defined
などに保存されます。


骨の命名定義を3dsmax上でする手順は以上ですが、保存ファイルはアスキーエディタでもできる
ので、数個関連付けたら保存して、後はそちらでやるのが良いかも知れません。



Save やLoadはC:\Program Files\Autodesk\3ds Max 2010\Scripts\Bippy\User Defined
などを参照するので、ここでファイルを編集すると読み込みが楽になります。



今回はここまで。
次回はリストを使いつつfbxファイルからbipedへモーションを移すフローを書きます。

2012年4月12日木曜日

kinect2台をPCに接続するときのドライバインストール手順について

■kinect2台をPCに接続するときのドライバインストール手順について

2012年4月現在、PCでKinect2台用いてモーションキャプチャする場合には、iPi Desktop Motion Captureを使うのが良いと思いますが、1台目のkinectを使用中にもう一台追加したい時、2代目をUSBに接続したけどドライバがうまく入らない、なんて場合があります。


そんなときは次のことを試してみるとよいかもしれません。



■kinectを2台接続するときには必ず1台毎にUSBのHUBが違うコネクタに接続する。
USBのコネクタが違っていても、HUB、つまり根元が同じだとうまくいかないことがあります。
そういう場合はHUBの違うUSBポートにそれぞれを接続してみましょう。

■一旦2台ともドライバをアンインストールする
デバイスマネージャから2台のドライバセンサーをすべて削除します。1つにつきドライバが3つ
インストールされていると思いますが、すべて削除します。 ?となっているのも削除です。

■Peimesenceドライバアプリも削除
プログラムの追加/削除 などでPeimesenceドライバアプリ自体も削除しておきます。
こうしないと後述するiPiRecoderからドライバがインストールできないためです。

■いったん再起動
おまじないかもしれませんが、私の環境ではこうするとうまくいきました。
■iPiRecorderSetup.exeからドライバをインストール
OS起動後iPiRecorderSetup.exeでKinextドライバをインストールしてみると
2台ともきちんとドライバが入っていると思います。

Kinectの目は無事にピカピカ光ったでしょうか。



先ごろ、PCを更新したのでkinectドライバを入れ替える際、1台目を誤って先に取り付けてPCを
起動してしまい、2台目でかなりてこずりました・・・。いやいや難儀なことです。

2012年2月14日火曜日

スクリプトのアップロード

GoogleDocsで今まで自分が作ってきた自分用のスクリプトをアップロードしていこうかと思います。
アップしたスクリプトは必要に迫られて作った荒削りなものばっかりです。
今後時間ができたら若干説明等を加えたりバージョンアップをする予定です。

PythonとSoftImageのSDKを読める人を尊敬していますので是非OMの書き方を教えて下さい。
Junkyさんのページの解説で、自分にもできる!と判った気になっただけで、分かりませんでした。

OMで開発しようとすると、眠くなるか頭痛がする呪いにかかってるんですかね。

このページの右下にある Pase's Category からスクリプトのページ飛べます。

一応免責として、スクリプトのご使用は使用者の責任の範囲内でよろしくおねがいします。
賠償できるお金とか時間とか責任感とか有りません・・・

2012年2月7日火曜日

アンチ義理のバッサリ感

色々あって色々ですがネタが浮かんだので。

■レンダリングのアンチエイリアスを切りたい場合の設定
・mental ray RenderingタブのAliasing(Raytracing & Scanline Only)のMin LevelとMax Levelを0にする
・samplingContrastを真っ白(V = 1)にする
・FrameBufferタブのFilter Typeを Gauss か確認してから Filter Sizeを1

幾つかgoogle検索してみた結果こういう手順を踏めば大丈夫そう、までは行ったのですが、やってみるとまだ少しもやがかかっているようなきがします。

良い解法はないものでしょうか。

2012年1月11日水曜日

結局iPiを使っても前転は上手く収録できませんでした。色々頑張って見ましたがダメでした。
腕とか足とかひどい事になり、寝っ転がるくらいで諦めました。


そんでもって、今年はシェーダーをどうにか理解できればと思いましたので
とりあえず初めはソースの中身を理解するためにも既存のシェーダーを移植するところから始めようかと思います。

http://xoliulshader.com/で公開されているMAX用に開発されたxoliulshader2.0がフリー公開されていましたので
勉強のために構造を解析していきます。
以前xoliulshader1.6がSoftImage用に移植されていましたが、そういう感じで2.0も移植できればと思います。
何から手をつけたらいいのか正直わからないので途中で挫折する気もします。
とりあえずWinMeregeを使って公開されているデータを比較してみます。
使ったことない人は、画像の感じで比較部分が色が変わったり段をある程度合わせてくれたりと見やすくなるのでお勧めです。



色々分からないなりに分かったので下にまとめてみます、.fxファイルとはHLSL言語(Cっぽい?)で書かれているらしいですが、 シェーダーの構造体をまず書いてから後半のtechnique部分で実行内容を書くっぽいです。

以下構造体の名前と 中身の差を抜き出したものです。
※変更無しのものはfloat Gamma<>とかのように何も記述していません。
※float DistanceBlur<> <-2.0で無し max?バージョン? のように記述がついているのは変更ありのものです。
※int DiffuseMapUV<> <-2.0で実装? 272行 とか行数が書いてあるのはXoliulshader_2.0.fxの行番号で1.6や1.6XSIと比較して大幅な変更があった部分を記述しています。

次の更新では各中身を拾い食いしながら変更してみてどう変わるか試してみようと思います
-------------------------------------------------------------------------------------------------------
bool bUseObjectNormalsfloat4x4 WorldViewProj

float Gamma<>

int numberOfActiveLights<>

//===========LIGHTS

int numberOfActiveLights<>

float4 light1_Position<>

//SHADOWCODE <-複数シャドウを扱う宣言部分?SIでは重いのでカットしてる感じ

bool bUseShadow<>

uint Shadow1Type<>

float Shadow1Strength<>

float DistanceBlur<> <-2.0で無し max?バージョン?

float4 light2_Position<>

float4 light2Color<> <-結構違う

float4 light3_Position<> <-結構違う

float4 light3Color<> <-書き方が違う

bool bUseHalfLambert<>

float HalfLambertPower<>

float3 ambientcolor<>

bool bUseIBL<> <-2.0で無し

bool bUseIBLCubeMap<> <-2.0で無し

texture IBLcubemap<> <- 2.0でtexture Envcubemap<> ただの変数宣言違い?

samplerCUBE IBLcubemapSampler = sampler_state{};

bool UseIBLambient<>

float IBLBlur<>

float IBLmultiplier<>

float CubeMapGamma<> <-2.0で実装? 216行

UseGradientRamp<> <-2.0で実装? 225行

//==========LightMAP

float LightMapStrength<> <-2.0で廃止?

sampler2D lightSampler = sampler_state<> <-2.0で廃止?

//==========DIFFUSEMAP

bool bUseDiffuseMap<>

half4 diffuseColor : DIFFUSECOLOR<>

texture diffuseMap : DIFFUSEMAP<>

int DiffuseMapUV<> <-2.0で実装? 272行

float VertexDiffuse<>

bool bColorDiffuse<>

sampler2D diffuseSampler = sampler_state<>

half4 diffusefresnelColor<>

float diffuseFresnelPower<>

float diffuseFresnelMult<>

//==========OPACITYMAP

bool bUseAlpha<>

bool bClip<> <-2.0で実装? 341行

float GlobalOpacity<>

//==========SPECULARMAP

bool bUseSpecMap<>

half4 specularColor<>

float speclevel<>

texture specularMap<>

sampler2D specularSampler = sampler_state{};

//==========GLOSSMAP

bool bUseGlossMap<>

texture glossMap<>

sampler2D glossinessSampler = sampler_state{};

float glossiness<>

float glossoffset<>

//==========NORMALMAP

bool bUseNormalMap<>

bool bUseObjectNormals<>

texture normalMap<>

int NormalMapUV<> <-2.0で実装? 475行

bool bFlipGreenChannel<>

bool bFlipRG<>

sampler2D normalSampler = sampler_state{};

//==========GLOWMAP

bool bUseSIMap<>

texture siMap<>

sampler2D siMapSampler = sampler_state{};

float siMapMult<>

float siLevel<> <-2.0で廃止?

bool bUseEdge<>

float EdgeStep<>

float3 EdgeColor<>

//==========Reflections

bool bUseFresnel<>

bool bAlphaMasksFresnel<>

float FresnelPower<>

float FresnelBias<>

float FresnelMult<>

float3 FresnelColor<>

float FresnelMaskHardness<>

bool bUseWorldMask<>

bool bUseReflMap<>

texture ReflMap <>

sampler2D ReflMapSampler = sampler_state{};

bool bUseCubeMap<>

texture reflcubemap<>

samplerCUBE reflcubemapSampler = sampler_state{};

float CubeMapBlur<>

bool bUseReflGloss<>

float EnvRotation<> <-2.0で実装? 650行

//----------------------------------MAXSCRIPT UI VARS
このあと数十行max用?2.0で実装?
//----------------------------------TEXCOORD MAGIC
このあと数十行max用?2.0で実装?

//----------------------------------VS & PS structs
以下頂点,ピクセルシェーダーについての記述

struct VS_InputStruct {}; <-
half2 texCoord4 : TEXCOORD3; の行が2.0で実装

struct VS_To_PS_Struct {}; <-内部の記述がいくつか変更

//==============Custom Functions

void SetupMatrices()

//standard diffuse lighting by dot product

float diffuselight( float3 normal, float3 lightvec){}

//Half Lambert lighting, function by Valve Software.
以下十数行同じ

//seperate specular calculation to make my life easier coding this thing
以下float近辺の幾つかが2.0で変更

//Fresnel falloff function for all round application
フレネルの減衰設定部分?以下961行まで変更なし

float3 NormalApplication(float3 normal, VS_To_PS_Struct In){} <-2.0で実装? 962行

//SHADOWCODE

float ShadowLookUp(float4 position, float3 tangent, float3 binormal, float blur){} <-2.0で追加 983行

//Vertex And Pixel Shaders

//VERTEX SHADER
VS_To_PS_Struct vs_main(VS_InputStruct In) //vertexshader gets input struct from application, all automatically
{} <- VS & PS structsでTEXCOORD0が1.6<-2.0で変更になった関係でココらへんの幾つかも変更 1011

//PIXEL SHADER
float4 ps_main(VS_To_PS_Struct In) : COLOR{}
1029 - 1429行 構造が部分毎で幾つか変更

technique Default {}

technique TwoSided {}

technique Glow{}

-------------------------------------------------------------------------------------------------------

2011年11月27日日曜日

iPi Desktop Motion Capture 収録まとめ4 キャプチャー本番編

iPi Desktop Motion Capture 1.3.1.124のモーションキャプチャの手順と成果メモです。
今回いよいよ本番です。


以下の手順説明部分は結構 iPi soft wikiから引用してます。手順は一応守ってますが、
正確でない可能性があるのでこちらも参照してください。



■iPi Recroderでモーション録画
・最初の2-3s何も動かない環境を録画
・アクターがキャリブレーション時に取り決めた所定の位置と角度にあわせて立ち、Tポーズする
・1秒程度Tポーズした後、アクションする



取った動画がこれです。最初の数秒とTポーズするまでは省いています。
この動画ではkinect1台分しか流れてませんが、 収録動画は2台分の映像情報が収められてます。

動画を収録したらiPi Desktop Motion Captureでモーション解析に移ります。 iPi soft wikiには
iPi Desktop Motion Captureでアクターの身長設定をする方法や、キャラクターとアクターのマッチン
グをスムーズに行うためにいくつか方法が用意されています。

キャリブレーションの時にしっかりとアクターとキャラクターの位置関係を揃えておくと、ここに使う
労力をかなり減らせます。

iPi Desktop Motion Captureに動画を読み込み、キャラクターとアクターのマッチングを済ませたら、
あとはTrackFwardボタンを押してモーション解析が終わるのを待つだけです。

終わったのモーションは多少ガタ付いていたり、抜けがあったりするかもしれません。
手の抜けなどがあれば、腕を回転させるなどで修正できます。位置合わせする時にはIKではなくジョイントを
選択してFKで合わせるのが良さそうです。IKだと特に肘とかが変な場所へ行ってしまうことがありました。
許容出来るモーションになったら、最後にガタつきをsmooth3程度でスムージングすると丁度良くなります。

このレベルのモーションがキャプチャ出来ればガイドだけでなく、RIGに流しこんでの修正にも
使えると思いました。正直ここまで取れるとは思わなかったのでたいへん驚いています。

iPiは標準のbvhの他にも3DSMAX(biped),MotionBuilder,iClone,Blender,Endorphinに対応したbvhを
出力できます。softimageには標準bvhで読み込むのが良さそうです。

以上 iPi Desktop Motion Capture 収録まとめ でした。


次回前転してみる に続く

2011年11月26日土曜日

iPi Desktop Motion Capture 収録まとめ3 キャリブレーション編

iPi Desktop Motion Capture 1.3.1.124のモーションキャプチャの手順と成果メモです。
今回は収録前のキャリブレーション編

以下の手順説明部分は結構 iPi soft wikiから引用してます。手順は一応守ってますが、
正確でない可能性があるのでこちらも参照してください。

iPiはKinectを2台使う場合キャリブレーションが必須になりますが、撮影環境が保持できる場合や
ビス、テープやカメラ撮影しておくなどで、後日正確に再現できれば1度だけで済みます。
またキャリブレーション情報はiPi Desktop Motion Captureで編集/保存できるので、Kinectの部屋の中での位置を予め定規などで測っておけば後で正確に合わせることが可能です。



 Kinectを所定の場所に配置したら、iPiの環境を実空間と正確に合わせるキャリブレーションに入ります。

ここは、流れが把握できていれば、PCの性能にもよりますが5-10分程度で終了します。
2度目以降は環境変化がなければ必要ありません。

以下順番に手順をメモします。一部、個人の体験上よさそうだと思った事が加わってます。
特にアクターとキャプチャ後の仮想空間でのキャラとのマッチングを素早く行うため、
事前調整部分が必要なくなるように色々書き加えて見ました。参考程度ってことで。



・iPi Recorderを起動して2台のKinectを選択
・同心円上に配置した2台のKinectの中心にアクターが立つ
・ここで、仮想空間でのキャラとアクターとのズレをみるための仮素材を数秒録画する

・iPi Desktop Motion Captureを起動して仮素材の動画を開く
・iPi仮想空間内のキャラクターの初期位置とアクター位置のズレをメモなどで記憶する
・アクター位置、身体正面や手先の回転がずれていたら動画を元にアクター/Kinectの位置など調整
・調整が終わったらアクターは収録可能範囲から出て、リファレンスプレーンを持って待機

・iPi Recorderで録画開始。最初の数秒は2-3秒は何も動くものがない動画を撮り続ける
 
・アクターがリファレンスプレーンを持ってKinectの中心に立つ
・2台間の中点に正面を据えて、それぞれのカメラから板の正面が見えるのを確認する
 
・正面に板を据えてから、数秒かけて板を、体を中心にして左右20度程度回す
・なるべく板の黄色部分が少なくなるようにするのが正解
・板の黄色部分がほぼ無くなっている動画が5-10s収録できたらストップして録画終了

・iPi Desktop Motion CaptureにうつってCalibrationタブに移動しAngleのラジオボタンで適切な方を選択
・下のバーで最初の2-3s間をbackgroundで指定、また板をもってアクターが立ち、適切にキャリブレー
ションできた範囲の5-10s間をROIで指定して[Calibrate based ~]ボタンを押す
・数分待つとキャリブレーションが終了する。事前にメモした位置と大体合っているか確認する
・違いが5cm単位である場合は、メモに合うようにカメラを動かして調整する。キャリブレーションし直すより早い




・キャリブレーションがある程度満足行く内容になったら一旦設定を保存する。
・設定ファイルをロードすると実空間がiPi Desktop Motion Captureの仮想空間にほぼ一致する


キャリブレーションの流れはこんなでしょうか。精度は低くはないですが、予めカメラ位置や角度をメモして
おき、キャリブレーション後の仮想空間に展開しているカメラ位置とアクターの録画された震度マップがうま
く同一空間上に重なっているか確認できるようにすると手間が省けると思います。
メモした数値と結果を照らしあわせ、手動で仮想カメラを修正すると、より良い調整ができると思います。

事前計算で大体あわせてメモを見ながらより正確にあわせるという流れで行くのが良さそうです。
数センチは許容、5センチ以上は修正な感じでしょうか。


次回 キャプチャー本番編 に続く

iPi Desktop Motion Capture 収録まとめ2 セッティング編

iPi Desktop Motion Capture 1.3.1.124のモーションキャプチャの手順と成果メモです。
今回は機材と収録環境のセッティング編

以下の手順説明部分は結構 iPi soft wikiから引用してます。



 ■PCとKinectの接続するときの注意点など
・Kinectは給電が別途必要なので必要なコンセント数を用意
・Kinectは必ずPCのUSB2.0以上のポートに単体で接続
・録画前の段階でKinectは使用ポート毎にドライバインストールを済ませておく
・PC起動後数分はKinect及びPC機材が安定しないため収録しない

また、初めて録画をする場合は、Kinectのドライバがきちんとインストールされているかを
デバイスドライバで事前に確認するのが良いです。左がOKで右がNG一例です。
 
右になっていたら、一部ポートがUSB2.0未対応か配電自体がセパレート構成の可能性ありです。
PCを起動して数分後、一度iPirecorderを起動してKinectが2台認識されるか確認し、

画像のdepth入力を確認します。
問題ないようだったら次に進みます。


■キャプチャ環境の条件
・3m*3m*2m程度以上の範囲に大きな凹凸のない照明付きの室内、または薄曇りの公園など
・秒数間Tポーズで立っていられるアクター
・そこそこ体にフィットした、赤外線を変に反射しないジーンズと長袖

ココらへんの条件は結構曖昧ですが、キャプチャの精度を高めるためにはいろいろカオス要素を
排除していくのが肝心だと思います。

キャプチャ環境は 1R程度の広さで最低限のキャプチャは行えますが、床のゴミは片付け、
服装は形状がひらひら変わるようなものはやめたほうが良いです。

キャプチャ環境を整えたらKinectを配置していきます。

■二種類のKinect配置方法
iPiで選択できるKinectの配置方法は2つ
・2台をアクターを中心にした同心円状に30-90度で並べる


・2台をアクターを中心にした同心円状に110-180度で並べる


この二種類は部屋の環境によって選ぶのが良いと思います。 どちらも選べる空間があるなら、
収録アクションの胴体~手がどのように重なるかを念頭において配置するのが良いです。
立ち止まって両手を交差させる演技が多いなら30-90、くるくる回る演技なら110-180でしょうか。


配置を決めたら実際に置いて行きます。

各Kinect配置の位置と高さは図に書かれた通りにですが、追加で幾つか注意点を守るようにすると
、収録後作業や全体の精度が上がると思います。

■配置時に気をつける点
・30-90度で展開する場合、80度程度が理想に近い
・1台目のKinectで上半身と接地面を過不足なく捉えられる場所に配置する
・2台目はアクターの身長より少し高い位置で、接地面を捉えつつ胸部をカバーできるよう配置する
・次回以降、環境を正確に再現できるように、Kinectの位置と高さをメモで残しておく。



 次回 キャリブレーション編に続く

iPi Desktop Motion Capture 収録まとめ1 機材編

なぜか家にKinectが2台あったので、iPi D0esktop Motion Capture 1.3.1.124でモーションキャプチャして
見ました。キャプチャテストの手順と成果メモです。

結果は驚きの精度でした。

iPiのKincet1台接続の場合、足と胴体のキャプチャについてはかなり精度が高かったのですが、
どうしても肩から先、特に胴体正面で両腕をクロスさせる動きの精度が悪くなりがちでした。
剣道の面をカメラ正面に向けて演技するのがわかりやすいかもしれません。
それが2台使用することで、きちんと収録できるようになりました。


今回は使用した機材についてのメモ


■iPiでKinectを2台接続するときの使用条件
・(必須) Direct3D 10互換のグラフィックカード
・(必須) 2つ以上の USB 2.0 または USB 3.0ポート
・(推奨) HDDまたはSSDの書き込み速度が 55 Mb/sec 以上あるもの
・(推奨) Windows7 64bit

今回は、以上の条件を最低限クリアできる環境として次のものを使いました。

■テストに使用した機材
・ASUS K53U
・iPi Recorder  1.6.0.79
・iPi D0esktop Motion Capture 1.3.1.124
・Kinect2台
・横1m縦1.3mのボード (キャリブレーションプレーン)
・ノートPC冷却台(一応)


K53Uの3DMARKのスコアは大体1700程度ですが、録画環境としてのコスパは優秀だと思います。

http://www.asus.co.jp/Notebooks/Versatile_Performance/K53U/
しかしキャプチャ後計算や長時間連続録画(10000f超~)の収録は向かないので、別途高速のCPU
を積んだPCを用意すると色々スムーズに進むと思います。
今回はこれで録画後計算もしましたが、1f処理するのに安定して12~13sかかりました。
現状Corei7使用のミドルレンジPCでも、3DmarkのCPUScoreが20000程度は出ますので、処理速度
も段違いになります。



次回セッティング編に続く

2011年11月22日火曜日

QUMA出動


http://gadget.itmedia.co.jp/gg/articles/1111/22/news073.html
遂にQUMAの発売日が決定したようです。2012年5月。
CGWorldカンファレンスから色々あったでしょうが、無事に発売されることを祈るばかりです。
連休中にWBS辺りで紹介されたりするんでしょうか。
人体を直接撮ることがメインだったモーションキャプチャーの世界に、新しい切り口ができそうです。

価格はやはりintos一台程度でしょうか。気になります。

2011年11月19日土曜日

KinectSDK-v1.0-beta2-x64のインストール

http://blogs.msdn.com/b/kinectforwindows/archive/2011/11/03/it-s-official-kinect-for-windows-is-coming-soon.aspx
KinectSDK-v1.0-beta2-x64をインストールしてみました。簡単すぎて吹きましたわ。
OpenNIの敷居の高さはなんだったんでしょうか。


必須OSがwin7ってところが難点ですが、こちらがユーザーに優しいので、是非Kinect関係を
使ったモーションキャプチャー開発が活発になってほしいです。
mikumikudanceも対応してくれないかな・・・

211/11/2現在、表立った対応アプリがなさそうなですが、インストール手順は大きく3つです。

------------------------------------------------------------------------------
1.Microsoft .NET Framework 4 をインストール

http://www.microsoft.com/downloads/ja-jp/details.aspx?FamilyID=9cfb2d51-5ff4-4491-b0e5-b386f32c0992
2.Visual C# 2010 Expressをインストール(ファイル名はvcs_web.exe)

http://www.microsoft.com/japan/msdn/vstudio/express/
3.自分のOSに応じて32bit,64bit対応のKinectSDKをインストール


http://www.kinectforwindows.org/download/

---------------------------------------------------------------------------------
OpenNIをインストールしていると競合するとの情報もありますので、これを入れる場合は、
回避策を調べたほうがよいかもしれません。



土日にiPiの体験版を触ってみたので、次書くことがあったら、そこらへんを書いてみようかと。
Kinect2台でかなりパフォーマンスがあがってます。マジで。

2011年11月14日月曜日

XSIEnvelope v1.1を使えなかった時に試して見ること

SoftImageのEnvelope関係のaddonで、SoftMonkeyさんが開発したXSIEnvelopeがありますが、 http://www.softmonkey.org/
いくつか環境依存の問題が有るようです。
その内の一つ、先日自分の環境で起こった問題の解決方法をまとめて見ました。

・OSにPythonがインストールされていること。(SoftImage2010以降はネイティブ対応で基本不要)
・インストール後、SoftImage起動時にXSIEnveloping関係のエラーが出ていたら
 ・C:\users\ユーザー名\Autodesk\Softimage_~\Addons\XSIEnveloping\Application\Pluginを見る


 ・OSに応じて32bitか64bitのどちらか必要ないdllファイルを削除
・SoftImageを再起動してXSIEnvelopeツールバーのボタンを押し、何も動かない場合は

 ・ボタンをカスタマイズしてPythonスクリプトとして動くようにする

これで動きました。動くまで2日悩みました。
環境が違うとすんなり動いたりするので、一応こういう解決をした人もいるよって事で

特にスクリプトボタンがきちんとPythonスクリプトとして認識されていない問題については
数日答えが出なくて、相当悩みました。

2011年11月8日火曜日

Kinect for Windows is Coming Soon...


2011年の春先から夏にかけて、Kinectについて新しい動きがありました。
Microdoftからデベロッパー向けに幾つか告知があり、またカンファレンスなどが各地のゲーム系
コンベンションで行われ、ここ数週間でゲーム系サイトを中心に正式な情報が出回り始めたました。
http://game.watch.impress.co.jp/docs/news/20110301_430252.html
http://xbox360.ign.com/articles/121/1211083p1.html
KinectというデバイスがWindowsへ本格対応するとしたら、iphoneなどで始まったデバイスの新たな
流れが一層加速するかも知れません。
http://blogs.msdn.com/b/kinectforwindows/archive/2011/11/03/it-s-official-kinect-for-windows-is-coming-soon.aspx
現在のKinectは、深度センサーの精度があまり良くありませんが、これからデバイスメーカー各社が
MicroSoftライセンスを受けて開発を進めれば、より良いものがたくさん出てくるきがします。
ゲームモーションの敷居もグッと下がりそうでワクワクします。
こんな文章書いてたら、本日(11月9日))ASUSTECからOpneNIを利用したモーションキャプチャデバイス
が発表されました。11月11日発売。価格はどんなもんでしょうか
http://plusd.itmedia.co.jp/pcuser/articles/1111/09/news042.html
大体\25,000程度?こちらのブログで導入まで細かく説明されています。
http://d.hatena.ne.jp/hagino_3000/20111106/1320562275
この流れが続いてくれると嬉しいです。

2011年11月4日金曜日

CGWORLD 2011 -クリエイティブ カンファレンス- (2011/10/23) のまとめ 4

カンファレンスの4コマ目。最後は人形タイプのモーキャプツール、QUMAの講演を選択しました。
開発元のビビアンを中心に幾つかの関係企業の方々が講演者として来場していました。



この一風変わったモーキャプツール。youtubeでも一時期話題になっていたのもあり受講しました。


----------------------------------------------------------------------------------
3D-GAN1630-1730
講演タイトル:パーソナルポーズキャプチャシステムQUMAのテクノロジーと有効性
----------------------------------------------------------------------------------

まず、開発元のビビアンや3D-GANなど講演者の活動内容の紹介がありました。

ビビアン : http://bit.ly/uil5gI
SOFTEATHER : http://www.softether.co.jp/jp/
3D-GAN : http://www.3d-gan.jp/
セルシス : http://www.celsys.co.jp/

3D-GANは秋葉と御徒町の間にあるとか、原型師の方の略歴などつらつら紹介していました。
QUMAの最新バージョンをYoutube見た時から見たことある造型だなと思っていたら、やっぱり浅井さんでした。
20分ほどQUMA開発の道のりを話した後に、現在の進行状況やPC他ツールとの連携話がありまし
た。コミスタ等のセルシス社系アプリと連携しているそうで、最新QUMAで実演が有りました。


QUMAは背中のアームを原点として検知しているそうです。
手付けでフォームを簡単に作れるのが売りだそうで、確かに実演でもそれを示すような流れでした。
ちょっと関節が頼りないと思ったので後で聞いてみたら、まだガワがモックのまんまだったそうで…。
以下聞きとりしながらまとめたQUMA情報です

QUMAの開発動機は、ビビアンの社員2名が、絵心のない自分達でもマンガやゲームを作ったりで
きないか、その補助装置が欲しいと思ったことがきっかけ。その後1週間ほどで棒人形型の0号機を
作成した。

QUMAは本体側にCPUを積んでいて、データ転送の重い処理もPC前ででき、遅延があまり無い。
楽にフォームが作れる。

今は人間型で開発しているが、関節は全て同一ユニットで構成されている。原理的に蛇や四足にも
対応できる。人間型以外のライブラリ開発については未定。

人間が無意識的にする回転(膝から下のX回転が180度近辺でロックetc)については構造的にオミッ
トし、ソフトウェア側での修正前提。

USBでデータ取得は120fps

間接耐久度は実験データで50万回。ガンプラより大分厚いポリキャップを使用。

スペアパーツ・モジュール単位の販売予定は不明。組み合わせパーツ用のAPIは用意中で、また細
かい部分の詰めができてない。

QUMA二体(USBポート2つ使用)で、キャラの絡みもできるようにアプリ側で準備中。

体格の違いを補正する機能は研究中で、どこかで導入したい。体格補正用のマッピングライブラリ
(SDK)で解決する予定。そもそもQUMAのマニピュレータとしての形状が人間側での補正を促してい
るため、多少の違いは目と画面で補正してしまえる。

手首と足首は関節が入っていて回転値が取れる。モノとして手のひらをグーにしたりしたものを作成
しモーションイメージによって取り替えられるようにする。

ほかの3Dソフトとの連携は、セルシス製品をQUMAへ同梱する予定。SDKは用意はしているが、で
るかどうかは大人の事情。

発売前の商品評価について、年末くらいまでにいろいろできる状態に持っていきたい。会社単位で
サンプルを見てもらうなど検討できる。窓口はビビアン、softeatherや3D-GANでもOK。

接続ソフトの公開予定は、API/SDKのどの程度で出すか未定。発売してすぐには出さないと思う。
モーションキャプチャについてアプリを提供する予定はある。

発売時期と価格はまだ未定。来年の夏?大きいペンタブレット一つくらいの値段にはしたい。

こんな感じ。

--個人的なまとめ--

アットホームなとても良い講演だったと思います。質疑応答も含めて1時間程度、会場は和やかで受
講者も皆興味津々だったようです。

講演終了後に実物をさわらせてもらえました。間接が頼りなかったのはまだ材質が最終品質ではな
くモックだったことが原因で、近くで一目見たら実際そんな感じでした。削り出しをそのまま使ったよう
です。個人的には出たら即買いなので、是非早めに製品化して欲しいと思います。

2011年11月3日木曜日

CGWORLD 2011 -クリエイティブ カンファレンス- (2011/10/23) のまとめ 3

3コマ目は今後ゲーム屋でも必要になっていくであろうVFX の基礎についての講演を受講しました。

----------------------------------------------------------------------------------
KojiVFX1510-1610
講演タイトル:映像合成基礎
----------------------------------------------------------------------------------

トロンアップライジングの開発を行っているKojiさんが講演者でした。

まずはトロンの映像をながしつつ現状の話をしていました。トロンノアニメ版はパイロット版を10本
作っている段階で、今後順次情報を開示していくそうです。アニメが終わって本題に入りました。

■合成の基礎について。
合成とは画像に計算式でもってアプローチする手法である。ハリウッドではこの考え方が本当に徹
底されているが日本では全くない。絵を見ながらやるだけの合成は合成ではないことを認識するこ
と。計算によってクオリティを保持するというのが合成の仕事。決して感性のみで画作りはしない。
画像合成の基礎をしっていることでほかのアプリにも応用できる。
色の計算式はリニアカラースペースで行い、最終出力でSRGBにするのが良い。

というような話でした。合成の基礎をきちんと知り、画像をどう弄るとどうなるかを確実に把握せよ、
今までいろんな人達が創り上げてきた画を自分で台無しにするな、と口を酸っぱくして言っていたの
が印象的です。合成の基礎について、確かにそのとおりだと思いました。

しかし講演の内容自体はちょっと話が基礎すぎるので他人のドキュメントを探して参照したほうが
良いかもしれません。photoshopでレイヤー合成したことがあれば大体分かるような内容です。
以下抜粋して書きだして見ました。

各RGBチャンネルを合成する場合は必ず各チャンネルの荒さを見て精度の高い作業を行う。
特に黒について。32bitだとマイナス値があり得るので、必ずスポイトで画像を隅々まで照らして
マイナス値がないか確認する。

RGBをリニアにして作業する

γはやっかいなので仕組みをきちんととらえれれば使うがそうでなければ使わないようにする。
日本では、プロでもただ闇雲に使っている人が多すぎて萎える。ハリウッドでは絶対にやらない。

ブライトネスや移動などは何度も重ねると画像が劣化しするのでやらない。やるなら1度だけ。

などなど本当に画像合成の基礎を話したという感じです。ガンマ弄りはプロはあまりやらないのでは
と思いましたが、まぁどうなんでしょうか。そんなに日本の合成レベルって低いんでしょうか・・・。
分かりません。

--個人的なまとめ--

期待していった割には、 私個人にはあまり得るものがありませんでした。確かにレイヤー毎の挙動
は確実に把握しながら作業していくのは基本中の基本だと思います。忘れないようにしようと心を新
たにしました。

CGWORLD 2011 -クリエイティブ カンファレンス- (2011/10/23) のまとめ2

前回に続いて、CGWORLD 2011 クリエイティブ カンファレンスについてのまとめです。

今回は2コマ目に受けたモーションキャプチャスタジオのレビューです。
受ける前からトテモ期待していた講演でしたし、個人的にはトテモ有益でした。
帰宅後に集めたムービー等のリンク等も貼りながらご紹介します。

----------------------------------------------------------------------------------
ゼロシーセブン株式会社1400-1500
講演タイトル:モーションキャプチャのご紹介
----------------------------------------------------------------------------------

会場入りすると、Xsensロゴの書かれたスーツケースと専用スーツを着たアクターさんが現場にいて、池田さん 早川さん(アクター)という方々でした。あと操作用のノートPCが2台。
性能はHP製のミドルノートとのことです。OSは64bitでメモリだけはたくさん積んでいるようです。

最初の10分程度、ゼロシーセブンの紹介がありました。赤坂に事務所があり、各種キャプチャシス
テムを一箇所で試用できる。海外キャプチャの輸入販売を主業務にしていて、スタジオに縛られな
いモーションキャプチャの提供やサービスを目指しているそうです。
通常のモーキャプの他にフェイシャルやハンドキャプチャツールも提供していて、赤坂事務所では
格安でキャプチャサービスも可能だそうです。高品位をきっちり必要な場合は是非使ってください。

ここから怒涛のように本題に移って行きます。まずは超格安モーキャプツールから

■iPi desktop MocapiPiの紹介
http://www.ipisoft.com/

Kinectを中心にしたモーキャプツール。+でWebカメラ4台まで使うことができ、着の身着のままで撮影
できるのが最大の売り。今冬中にマルチKinect対応予定。ロシア製。

現在のバージョンは、Kinectの深度カメラで陰になるところはRIGかカーブ編集で吸収するか、そこら
で売ってるWebカメラ4台を扇型に並べてやる必要がある。補助カメラを使うと重なりの補正が効き
高クオリティで入力できるようです。自作のキャラをにiPi画面に出しながらのMoCapも可能都のこと
です。
webcamはペンライトでキャリブレーションできるので、キャップはずすとライトが丸見えになるタイプ
を1000円くらいで買って使用してくださいとのことでした。

youtubeに上がってるiPiビデオチュートリアルを見ればほとんどの機能が使えるようです。

開場では実際にKinectを使ってiPiのモーキャプを実演しました。
youtubeのチュートリアルと流れは全く一緒で、アクターがいない状態から録画開始して数秒、アク
ターが画面に入りTポーズをします。数秒姿勢を保持してからアクション開始して、収録が終わったら
ストップ。が基本Mocapサイクルのようです。感想はとにかく簡単。
エディタ内でカーブのフレーム間隔を参照したスムーズができるので、簡易編集が入出力なしにでき
ていました。人間一人のキャプチャがてき、首と足首には今後対応予定とのことですが、ここはRIG
で吸収するのがどこでも前提だと思うので問題ないかと。

実演してくれたことで非常に使いかっての良いツールだということがわかりました。
洋服も変わっておらず、チェックの長袖シャツにジーパンでしたし、特に目印も付けてませんでした。

コレは欲しい一品です。iPiと持ってなければKinect、1台1000円前後のwebカメラ4台とキャリブレ用


ペンライト、で10万以下?



続いて、かなり高価なアプリの代表格
■OrganicMotion OpenStageV2のご紹介
http://organicmotion.com/

キャプチャ形式としては、iPiの上位番みたいなもので、5人以上でも同時撮影可能な高級機です。
高速動作200fps対応でFireWire接続。データ記録は本体と外部ストリーミングに対応しています。
マーカー計測はバージョンアップで対応予定。カメラは8台からで32台まで拡張できます。
金額的に個人向けでは無いですね。シーグラフ2011の映像棒を持って演技してる映像が紹介さ
れているとのことでした。↓でしょうか

Ver2は2011年12月発売予定だそうです。ここからまぁ個人向きじゃないと思います。
目の保養だけはしっかりしておきました。

■Xsens-MVN 映像紹介
http://www.xsens.com/en/homepage-ja
http://www.0c7.co.jp/products/mvn/

いきなり空中でのMocapしてる映像から始まって度肝抜かれました。

センサー式のキャプチャシステムでジャイロと加速、磁気内蔵。ワイヤレスなので屋外でも使える
し、車に乗り込んでアクションするのも簡単!という謳い文句だそうです。
個人用途にはぴったりだし使える!値段が700万円!身長とか踝までの長さなど各関節をアクター
毎にファイル登録して切り替えていました。
ここはかなり売りたいらしく、スーツ着た方のデモンストレーションがありました。
まず、軽くキャリブレをした後にMocapボタンを押して記録開始。講演では実演もしていましたたが、
カーブデータは超滑らかできれいでした。裏山しいです。

家に帰ってから見つけてきた動画では、足首や手のひねりがきれいにとれてました。
超いい!でも高い!みたいな感じでしょうか。
レコーディングボタンを押すと自動で新規ファイルに保存されるのは地味に便利ですし、精度がとに
かく高いのが魅力だと思います。一括でモーションをエクスポートする事もできてましたし、プラグイン
を使うとモーションビルダーにリアルタイム転送も実演していました。別途購入が必要だそうです。





導入実績が山ほどあり、ゲームから映画、CM IronMan2のプリビズなどに使用されているとのこと
です。youtubeでいくつかでてきました。アクロバティックな超絶アクションを作る際でも、磁気式の強
みを生かして運動補助を付けてMocapできるようで、youtube動画でもそれが見られました。確かに
欲しい。でも700万。です。

■Qualisys OQUS
http://www.qualisys.com/
http://www.0c7.co.jp/products/oqus/
光学式キャプチャシステムで、これはホントに人間ならもうなんでも撮れる。
でも個人ではもう無理、手が届かない!というシステムです。
水中でもとれます。飛び込みからバサロまで!国立科学サポートセンターに18台導入済み。
サンプリングレートは500fps。



絶対にこのカンファに来てる人が買えないツールの後はちょっと毛色の変わった3dモデラーの照会がありました。
■LeoNar3Do
http://leonar3do.com/
専用3Dメガネを使ったモデリングツールだそうです。ちょっと前2chのまとめサイトで見かけたかもし
れません。映像見てるだけだとやっぱり微妙・・・。SDKがついているので自分でいろいろ拡張できる
ようです。一度本物をこの会社いって見ることができればいいなぁ。でもまぁ使わん気がします。
子供をプロモーションビデオに使うのはいかんかったんではないでしょうか。


最後は個人用途向けのフェイシャルキャプチャを紹介していました。 凄い時代です。

■ZignTrack
http://www.zigncreations.com/zigntrack2.php


マーカーつけてwebカメラでとるフェイシャルキャプチャだそうです。廉価版でソフトウェアだけだと5万
円でアプリとマーカーのテンプレがいくつか付属していて、マーカーは自分でこさえることもできるそう
です。BVHで吐き出し可能。poserにも行けるのが売りだとか。
上位番は10万切る位の価格でHDVカメラに対応し最大8台まで拡張可能とのことです。
他の超高額機器を見た後だと手が届くようなきがします。


--個人的なまとめ--

モーションキャプチャはこれからのゲーム業界的にも起業は勿論個人用途でも手軽に導入できるツールとして期待しているだけに、今回の講演は有益な情報を得られてとても感謝しました。
フリーツールとして出回っているKinectを使用したツールは、やはり精度の問題が一部悩みの種で
したので、それがそこそこのお値段で解消できるので、是非導入していきたいと思いました。

CGWORLD 2011 -クリエイティブ カンファレンス- (2011/10/23) のまとめ 1

「CGWORLD2011 クリエイティブ カンファレンス」のセッションレビュー

カンファレンス詳細 : http://www.borndigital.co.jp/seminar/detail.php?id=221


複数の会議室で行われたカンファレンスを、全部で4コマ受講してきましたので、それを複数回に分けてレビューしていきます。淡々と思ったことをつらつらです。

----------------------------------------------------------------------------------
株式会社クオリス 12:30-13:30
講演タイトル:創造性と生産性を両立させる環境とは
----------------------------------------------------------------------------------
会社HP : http://www.qualice.co.jp/

■クオリスの業務履歴の話を色々
12:30から30分ほどこんな話。
この会社は立ち上げ当初ゲームプラットフォームやXSIやSI3Dのプラグイン開発、最適化システム
構築などをしていたそうです。XSIの初期APIについて先進性と扱いにくさは際立ってましたね、とか
話していました。
大半は退屈でしたが、ゲーム会社向けのシステム開発で一点だけ気になった話を。
どこかの会社向けのシステム構築で、SI3Dから.maを出力してRIGをMAYA上で完璧に再構成でき
たそうです。もったいないので是非SoftImage用に移植してください。
他にはアミューズメント向けのミドルウェアの調査運用コンサルするなどしているそうで、セミナーの
スポンサーだと思うので生暖かい目で見てますが、30分は使い過ぎです抑えめでお願いします。

■CGG制作環境の変化について
ここから10分ほど、1980年-現代までのエンタメ分野の略歴話をしていました。1980年のパックマン
から始まってファミコン、アーケードの話。I'ROBOTでゲームに初めての3が使われ、バーチャファイ
ターで爆発、2005年あたりから開発競争が落ち着いてきて云々と、そんな話でした。確かにその通
りですと懐古。

■3D制作環境の変遷
やっと本題です。残り30分ほど

2Dが3Dに移り変わるまでをそれぞれの表現技法を絡めて話ていました。とりあえずまとめると、

2Dドット絵でゲーム開発していた頃は、表現の限界が明確でピクセルに対して1対1に限りなく近く、
ゲーム要素の一部として機能していたため、アートがゲーム開発の行程に含まれることはスーファ
ミ開発の終盤に近くなるまで殆ど無かった。
3Dがゲーム表現として研究されるようになり、アート表現自体がゲームの開発工程に組み込まれ、
開発工数が増大した。またゲーム自体がアート重視になり、表現要求が高まっていった。
3Dゲーム初期から続いていたアート重視が市場に受け入れられると、それに篇什するようになり、
開発工程のボトルネックとなった。それらを改善するため、2004年頃から描画部分についてミドル
ウェアや社内のR&Dをたちあげる会社が増えた。

とこんな感じ。PS-PS3開発当初までの、日本の開発者から見た時系列的な感想は確かにこのよう
なものだったでしょう。

コレを踏まえ、現状の問題点と原因究明、どこを重点的に考えるか、へと話が移りました。
以下ものっそい長いですが、色々頷く点もあると思いましたので、講演内容をほぼそのまま羅列していきます。

3Dの黎明期から現在に至るまで、この分野の技術体系はハリウッドと主に発展し、その恩恵を全世
界が受ける形になっている。
ハリウッドは必然的にそのお膝元であるアメリカゲーム業界の技術発展を支え、初期はゲームの開
発資金投資やシナリオの着想点など恩恵を与えた。

最近は、PC性能の飛躍的増大という環境変化を受けており、ゲームと映画がお互いにフィードバッ
クする関係に発展し、影響を与え合う地盤ができている。

ハリウッドでは実写作品へのCG投入が盛んな為、実際にはないモノを如何に違和感なく合成できる
かを長年研究しており、その中で映像技法が非常に進化、その流れは今後も続いてくだろう。

CGアニメはキャラクターデザイン自体がはじめから3Dで有ることを意識しており、実写映画での考
え方や技法がそのまま使用できる強みがある。

またアメリカはPCゲームが主流であり、基板の進化が早い為、技術革新サイクルが早い。リッチな
チップの上で潤沢な表現を追求するといった方面に技術が進みやすい側面がある。現在の技術ト
レンドと非常にマッチした環境にある。

一方、日本では実写映画ではなくアニメとゲームがそこを担う立場にいるが、コンシューマー基板が
技術発展の基本になっている為、ハード限定の技術、特殊な環境での速度稼ぎなど技術が泡沫的
になりやすい面がある。そのような部分に長年コストを割いたため、現在ではアメリカに遅れをとっ
ているまた、映像表現としてのアニメはマンガ原作が多くキャラクターが基本2Dを意識した造形で
あるため、3DCGとの親和を深めるためには非常にコストがかかる。マンガアニメは職人の感に頼っ
た技法が多く技術革新のサイクルが遅い面がある。 

国内では、現在デジタルサイネージやカーナビ、アミューズメントの業界でムービーだけでなく3Dチッ
プが入り始めている。組み込み型のチップであるために、コンシューマ機家庭用と同じ問題を抱える可能性が高い。

そういった現状を解決しようと現在とられている手法の多くは、ミドルウェアの採用、高性能PC・レン
ダーファーム・人的リソースの導入、ワーク フローの改善ツールの導入などに終始し根本的な原因
に迫っていない。

ミドルウェアの問題点は汎用・生産性の向上が主なターゲットになっているため、ゲームアートの独
自性や品質と矛盾しやすくなり、消費者の目線で見たときに表現に差がない、特に代わり映えのし
ない同じようなものが生産される危険性がある。

また、ミドルウェアの価格はエンジニアの雇用や技術習得費用と比較し本当に安価か疑問である。

ミドルウェアの導入は社内での技術蓄積を諦め、表現の革新・斬新さを諦めることになる。
プロジェクト導入前に表現技法の特性の確認、プラグインなどが開発工程内で十分活用できるか、
生産性とのトレードオフを検証する必要がある。

といって、Unityなどは表現も多様になっているので、常に最新の情報を集めて情報をバージョンアッ
プし、プロジェクト開始前に、このミドルウェアが本当に必要なものかどうか徹底的にリサーチするこ
とが重要である。

コスパのみを課題にすると足元を救われる可能性があり、レンダーファームやワークフローツール
によって行程がどの程度効率的になるかを考えること。

当たり前だが、アメリカ発のツールはアメリカの開発工程で必要な考え方でつくられている。人的リ
ソース導入についても現場担当者の努力は、一時的な負荷分散にすぎない。

良いPCを三台入れても、人のパフォーマンスは三倍にはならない。

ゲーム・映像の現場が本当に望んでいるのは、製作者が十分に実力を発揮できる納期の中で最終
的に画作りに妥協しなくてよい制作環境とそれを的確に評価する、ということであり、そこに向かうこ
とを一番に考える仕組みである。そのためにはパフォーマンスの最適化、作業の増大といった問題
を変える努力が必要である。

現在の日本では、アメリカのように製作者の作業環境をバックアップする態勢を整え、それ専門の
研究会社を作るなどの、莫大なコストをかけることが難しい状況にある。画作りに直結しない部分を
重視しない風潮が一番変えるべき問題である。

付き合いのある会社に聞いてまわると、それはわかっているが、と言う。認識はしているがそこに手
を付けられないでいる現状がある。

アメリカと同じ制作環境整備は難しいし、単なる後追いをやっても環境の違いで役に立たない可能
性がある。

アーティストとエンジニアがどう協調するのかが課題であり、それらを結ぶ人材、つまりテクニカル
アーティストやそれを支える組織づくりが必要である。

と、こんな感じでした。確かに日本のエンタメ業界がどこでも抱えてる問題を、よく表現していると思
います。改善点もその方向性で間違っていないように思いますし、各社がそれをわかっていながら
手をこまねいている状況もそのとおりだと思います。


あとの残り10分はこの会社の宣伝でした。誰かクオリアをよろしくお願いします。


--個人的なまとめ--

現状認識や改善点などについて頷く処が多く、問題をきちんと認識してその対処をしましょうといっ
た内容には深く頷きました。

また、それらの問題を改善するためにクオリアを利用してみてはどうですか。といった売り込みにつ
なげる流れは感じ取れました。

ミドルウェアを使った、というか現世代のピクセルシェーダー体系を使った画作りについては、BF3な
どの一部を除けば、確かにどれも似たようなものになっていると思います。
そうした状況を打破してトップを取るといったことについては上記の方法ではもうどうしょうもないの
で、あえて深く突っ込まなかったきがします死なないために次善の策を、と言った内容でした。

問題を整理して、自分のプロジェクトで意識的に改善するのにとても良い講演だったと思います。

ありがとうございました。