2017年11月12日日曜日

MotionBuilderとMayaと

お疲れ様です。
あまぐりです。

MBさん面倒なんですよね。
普通になにかツール作りたい時に、UI考えるじゃないですか。

Pysideで普通にかけちゃうから。

わざわざかのMotionBuilderさんので書かないわけです。

というかMBと共通で共有する情報欲しいわけで。
座標や回転情報やらね。

かつ共通のUIであればあるほど、いいわけで。

Pysideでかくじゃないっすか。

社内ツールMBで起動しても、Mayaで起動しても同じの使いたいわけで。

とはいえ完全に外部には出せないからまぁ共通でいけるの作ったわけです。

各個人の情報を共有するときにdump使ってたわけです

だってclassで構造体みたいにやりたかったわけです。

妥協すると辞書in辞書でいいんですけど

それだと取り出す時にちょっと厄介なので

classがいいんですけど、MBさんときたら

日本語対応してないわけ(バージョンによるかも)

普通にスタッフは日本語使うのよ。

まぁ普通に日本語保存希望する人多いしまぁしゃーない

エラーはくからさ、例外処理逐一書いてられないわけ。

とりあえずjsonさん最高です。

dumpのほうが色々いいんだけど、jsonさんいいですね。

MBに色々もってくならjsonで辞書型で色々いこう。

と思った日々であります。
(UI上では問題ないんですけどJisでも問題ないんですけど)

2017年4月30日日曜日

【モーション記事じゃない】Python 辞書の作成時の登録順番を維持

あまぐりです。

最近作業中階層が非常に深かったり、
飛びまくってるところへ度々アクセスすることが多いんですね。

ので、エクスプローラーさんと行き来することが多いんですが、
案件変わるたびに入れ替えたりお気に入りフォルダやショートカットが
多大なことになってきて古いの消したりとかしてるんですが

普通にフォルダ名かぶってることがあったりするわけです
そうすると

ProjectA
ProjectA(2)

とかかってにつくわけですわお気に入り
お気に入りの方名前かえりゃいいけど
数が多くなってくると面倒くさい

ってことでMaya用ファイルブラウザが欲しかったからPysideで作って、
(Pysideで作ったのはmodelやViewの概念が使いやすかったのと、
あとウインドウのアイコン変えたかったから)
ブックマークも独自のを組んだわけですわ
csvから読み込んで辞書で

ここで問題が発生する

辞書は中の要素の順番は保証されない

保証されないんだって
だから取り出す時そのままitemを取り出すと順番が勝手に変わりやがる

やめれけろ

辞書内にlineread時のインデックス残しとくか・・・・?
とも思ったけどそれも違う

辞書内がややこしくなる

ってことで見つけたのが
from collections import OrderedDict
TestDict = OrderedDict()
あとは元々辞書宣言していたのを上みたいにしとけばいいだけ
これ辞書を作成したときの順番を維持するやつみたい

collectionsさんいつもお世話になってます
あんた本当優秀だな

import collections
TestDict = collections.OrderedDict()
from ~ が嫌いな人はこうだぜ

from collections import *
これは勘弁な

いいね

ファイルブラウザへの要望で一つ、
ブックマークの並び順を変えさせてほしいってのもきたけど、
これならなんとかなりそう。


コンテンツブラウザは重い・・・


2017年4月28日金曜日

Pyside2 csvから日本語の文字列を文字化け回避

あまぐりです。

最近社内用のデータベースありきのMaya用ブラウザー作成してる時に、
pyside2ではpysideだったころの日本語対応がうごかなくて、
C++のほうのリファレンスで調べて出てきたのも解決にはならなかったので、
どうしたもんかと思ってたら・・・

for key, value in self.ProjData.items():
if '#' in key or key == '':
continue
if asciicheck.Is_Ascii(key) == None:
key = key.decode('cp932')
m_MenuAction = QtWidgets.QAction(key, self)

まぁようは普通にデコードすりゃいけたんですが、
魔法の言葉もいるのかなと

pysideでは日本語を受け取った時これいれときゃよかったのを
QtCore.QTextCodec.setCodecForCStrings( QtCore.QTextCodec.codecForLocale() )

pyside2ではこのようにってのを Qt5ではってんで見かけた
QtCore.QTextCodec.setCodecForLocale( QtCore.QTextCodec.codecForName('utf-8') )

のこうした。

が、これいれなくても普通にデコードでよかった。
魔法の言葉いらんくなったのかな。

あとpyside2ではQtGuiのWidget系が全部 pyside2.QtWidgetsに映ってるようですが、
modelやQIconとかはQtGuiのままようだわ。

紛らわしい。

早く公式のドキュメントこないのかーい。


2016年6月10日金曜日

アクションRTS開発日誌 その5 進捗動画あり

どうもあまぐりです。

こんな時間までなにやってんだろうかと自問自答しているわけだけど、
楽しいから仕方ない。

カバネリとか見ながらずっと作業してて
本日はスキルを仮実装しました。

魔法っていうカテゴリの攻撃にする予定なので、
物理攻撃とは別の計算式も用意して、敵やらボスやらのダメージ計算時に
も共通でいけるようにステートマシンの継承親に関数追加しましたとも。

ええ。

でスキルカメラまわりも思いどおりの感じになってきたので動画をとってみた。
最初はGIF化しようとして難儀してたらこんな時間ですよ。


とりあえずの感想としては、遊べるレベルにはほど遠い。
あとスキルのアニメーションのブレンドはまだうまくいってなくて、
上半身がTポーズ、本当はスキルの発射前と発射後がブレンドされる予定なのです。

ステータスのバランスとかは最終的にいろいろできてから調整する予定だけど、
そのまえにスタート画面ないしは戦闘前の画面とかもろもろ作らないと
ただのデモみたいな感じになっちゃいそう。

デバッグではそれでいいんだけども。

2016年6月4日土曜日

アクションRTS開発日誌 その4 と嘆き

色々進んでいます。

実装状況

・とりあえずコミケに受かるか受からないか待ち。
・足運びのブレンド
・速度調整した

・キャラデザしてもらって仮モデルきた
・もう一個キャラデザして仮モデルきた


画面こんな感じです。

Shiftでスキルモード 移動 4方向を 体を正面にとどめたまま下半身だけブレンドで

通常はアサシンクリード的な操作

動画でできないのが悔いですね。

プログラムでアニメーションも制御しつつ

コンボはいま4つまで。


移動速度も調整しつつ。


プログラムの制御や新仕様の対応を自分でやるには、
モーションしかやったことがない自分には色々つらいです。

2016年4月23日土曜日

アクションRTS開発日誌とアニメーション雑記 その3

開発雑記


少しづつ進めていってるー

最近自分自身にスケジュールを設けるようになってから自分自身の危機管理コントロールが
多少融通聞くようになった。

奮い立てるなにか大事やわー


さて、今日はただ垂れ流しも見返してなにしてきたかわからないので
ちゃんとメモっぽくする工夫をしていきたいと思う。

さて、ちょっとしたことですがカメラの位置や角度って本当大事っすね~と
思う今日この頃。


@スキルという攻撃動作を実装する予定なのだけど、
これはおおよそTPSに近い画にする予定。

アサシンクリードの銃や弓使う時のカメラ挙動と同じっすな。

@戦術カメラと戦闘カメラの二種類を実装するときの切り替えを実装。

@全ユニットの攻撃撤退指示を実装

このへんはやく画像なり動画貼れるようになりたいわー

最近ユニットの相性とかずっと研究してて、
難しいと思ったのがいわゆるウォーゲームにおいては結構数がメインなところが多くて
ユニットごとの相性つけちゃうのもあるにはあるけど体感しずらいのよね。

今回はアクションゲームに近いというのとおしくらべなので、
前線をいかにあげていくかを重要視したゲームにしたいので
そこを体感としてすごく感じるようにしたい。

って設計した時に便利だったのが攻撃を受ける関数の作り方ですね。

引数をclassにしちゃて、つまりはパラメータを個別にするんじゃなくてかたまりで渡す感じ
構造体でもいいかとおもったんだけど参照型であるほうが都合がいい。
(でも実際その瞬間しか使わないしメモリ的にはクラスにしないほうがいいのかね。)

これやっとけばいちいち全ユニットの調整入るときにもクラスのおおもとだけいじればいい、
攻撃する側の判定内は同じスクリプトつけれるようにしてればいい。

これでおそらく今後追加や削減したい!ってときに修正しやすくなった。


アニメーション雑記


最近フェイシャルのセットアップしてて、
リグに関してまぶたや表情筋の動きを移動一軸や回転で一括でうごかせるようにしたくて、
関数を探していたんだけど、

Maya 便利な関数 hermite

こいつがすごく優秀だと気が付いた。

前から見てことはあったんだけどいまいち理解できなかったんですよね、
ベクトル勉強する前までは。

ベクトルの理解があるならすごくわかりやすい。

こいつを使うと座標指定のほかにその補間にカーブを描かせることができる。
まぶたとかに本当に便利なんすね。

ボディしかつけたことないとか、ボディじゃないとなんかやだ。。。
って人結構いるんだけど(まぁ実際修正もふくめキャプチャー修正なみに地味になることは多い)
俺はフェイシャルも好きだなぁー。




2016年2月26日金曜日

アクションRTS開発日誌とアニメーション雑記 その2

とりあえずもう2月も残すところあと4日 営業日的には2日。

ゲーム開発の進捗的には

1、ステートマシンを使ったAIによる 味方ユニットと敵ユニットの制御実装 1体づつ完了
2、ヒットの判定、ステートマシンをインターフェイス継承で宣言型統一、
その時のダメージ送信処理実装完了
3、サーチエリア(索敵)→同様の取得 またレイヤーわけ
そんでもって敵と味方でステートに使うEnumとステート数を分けることを決意
アップデートが軽くなるからスクリプト増えるのはもういいや。
別にキャラにつくスクリプトは増えないし・・・・。

またサーチエリアと連動して味方ユニットの状況によるステート切り替えを少しシビアに、
まだ単調なキャラクターなので8ステートほどで、管理はまだ大丈夫だけど、
ちょっと複雑になってきた。エラー処理があっちこっちとんでやばいかも

ボスなどはHPに応じてステート変化と自分の持つスキルを最初になにかみてから、
Random関数とかで発生頻度の乱数化しようとおもってたけど、個別にすることを決意。

正直スキル数もバラバラだし HP残量に応じて行動かえたいのでステータスが20を超えそう。
これは正直 噂の ビヘイビアツリー に移行したほうがいいのだろうか・・・・。

Unityで開発してるけど、アンリアルエンジンはブループリントでしかもそれがビヘイビアツリーということらしい。

一瞬ふらふらと行きかけたけど よくよく触ってみると自分のしたい内容を実装しようとすると、
C++やらないといけない。

業務ではMayaでPythonを自宅ではC#でUnityをそれに加えてC++は正直キャパオーバーだと思うので、やっぱり手を出さないよ。

ごめんねアンリアル!

とくにアンリアルにする決定打が今のところないんだよなぁ。
結局ゲームエンジンによってできることが変わるわけじゃないし。

シェーダーも自分でかけるしね。

開発日誌はこのへんで。



さてアニメーション。

開発日誌を(不定期)書き始めたおかげで、
色々とまたブログを有効活用していこうと思っている。

今年は自分の中でなにか覚醒する年なのかいろいろたぎってる。
というか去年一年で 相当な挫折というか無気力感みたいなものを味わい、
年末付近というか10月ごろからいろいろ心が折れてたんだけど、そこでなにもしなかった
反動かも。


☆キーの管理方法


2年ほど前からなのだけど僕はある種の法則に従ってキーを管理するようになった。

その管理方法というのが結構気に入っていて、名前もつけてしまった。


その名も「3つうち」。

映像系とかだとあまり通用しないかもしれない。
ゲームでもまぁ限定的なんだけどやろうと思えばできるのかな。

3つうちの特徴その1:


主要キー(特にダウンとアップ)を3つに分解する。


使える状況例:


どういうことかというと、
まずブロッキングを行う際にアップダウンなど主要キーを打つ。

仮アップ納品できる案件なら提出!

詰めてええで!っていわれたらつめはじめるときに
ポーズ間のタイミングやらインパクトやらをかえないようにしたい!
けど、連動だったりフォロースルーなども加えたい(のこしね)!

しかしながらのこしをいれようとしたりしたときの質量感だったり、
ポーズによっては短絡的にならないようにするには結構ポーズトゥのキー以外に
キーが必要になったり、1Fごとに打つのはやなのでキーをずらしたりすることになりがち・・・。

リグが少ないとなんとかなるんだけど、リグの数が多いと正直本来の緩急を
ブロッキングしてた頃の感じで(つまりは完全なポーズトゥで)管理できないんですよね。

(リアルな動き求められるときは特に。 バラバラ感がでるのと実際キーがばらけているのは
全く関係がないしね)

けどポーズトゥで作ると60fpsなんか顕著なんだけど正直キー揃えてより細かくなりがちだし、そこまで細かくうたなくていいところにまで影響するし邪魔になってくる。
かといってずらすとわっけわからんくなるからずらしたくないけど(以下ループ)

とか個人的にキーずらしをあまりいれたくない派としては(後々修正の時しんどいから)
そうそうになんか解決策ないかー!? となる状況があるとします。


使える解決:


そんなときにずらすという発想から もはやポーズを”前後”に増やすという発想に変えます。

そして増やすときには 必ず全部にキーを打つ(つまりポーズトゥを崩さない)

これが3つうちのキモです。

ずらしたい~あぁあああああああああ!!!!(以下略

の部分において 遅らせたい、ずらしたい分だけ良いと思う間隔分前後に
2つ、すべてのリグへキーを追加します。(ポーズを追加します)

そこから前動作時に本体よりも先行するものを 前に打ったポーズでアップ(またはダウン)に
中間で主要部位のキーポーズ、
後のポーズで遅れる(のこる)部位のキーポーズを

それぞれずらした状態にポーズを作成します。

はじめの主要キーのフレーム+ 前後 1つずつ(のこしやツメタメ用)だけで
ポーズで作る+調整するようにするわけです。

*注意

足りないってことはないと思うんです。
むしろ”ポーズが足りない” はわかるけど”ずらすためのキーが足りない”なら
実はポーズ不足じゃないか? ってなのも確認ができます。(白目


まぁここでポーズ不足に気が付いたらそもそも3つうちじゃ解決できないんですけども・・・。


逆にポーズ大杉(最大フレーム数敵にこのポーズ省略しないと仕様超える)とかにも、
早めに気が付けるかも。 キーもずれてないしまとめて消せてお得。

とはいえあくまで”ずらしたいけどキーが1Fずつずれるとかバラバラになるのがいや”、
という時の解決方法の一種だと思っています。

☆考え方


この三つうちというのは ”前動作” ”本動作” ”後動作” という
ひとつの動作を切り分けるキーの発想を、もっと細かいものにも当てはめたらどうなるか。
という発想から実践しています。

静止のところなら静止入る前と静止中 静止を出た後 などに主要キーがあるはず。
といったセオリー通り作ってるという前提はもちろん必要です。

さらにMayaだとこの前後のキーはブレイクダウンでうつとキーの色も変わってだ・・・・。

実際ブレイクダウンだし。

間隔調整系の修正もこれでまとめてキーを移動すればいいだけなので、
そこそこ長尺でもあとから修正が楽になるというわけだわー。

人によって管理の仕方は違うので、キーずらし慣れてる人には
おすすめしない・・・かなぁ・・・。

MotionBuilderとMayaと

お疲れ様です。 あまぐりです。 MBさん面倒なんですよね。 普通になにかツール作りたい時に、UI考えるじゃないですか。 Pysideで普通にかけちゃうから。 わざわざかのMotionBuilderさんので書かないわけです。 というかMBと共通で共有する情報欲し...