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だとこの前後のキーはブレイクダウンでうつとキーの色も変わってだ・・・・。

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

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

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

2016年2月13日土曜日

アクションゲーム制作 記録 その1

すごく久々の更新

今年の頭(2016初頭)から前々からアクションゲーム制作をやりたいなぁと
心におもっていただけだったのをついに行動に移すことにした。

企画内容は

・アクション要素がある → プレイヤーを自分で操作
・合戦っぽい要素がある → 大勢がぶつかり合う
・シュミレーションもちょっと混ぜるか → 味方のユニットをある程度指揮できる
・でもシンプルなものがいい → 操作は簡単
・PC向け

みたいなぼんやりとしたところから初めて近しい機能や遊びをもった
ゲームのプレイ感やよいところわるいところをまとめて・・・・
ベースにするゲーム性も目標をブラさないようにさだめ・・・

仕様書も作成してC#も勉強しつつ・・・

ついに仕様書は エクセル15ページに及ぶ物量になって、
キャラデザを知り合いの方に相談してやってもらえることになったので、
そちらの資料も作成して・・・

気が付けば1月が終わり、2月も半ば・・・

ちょっと後々のメモというか今後に生かせるように作業記録をブログにかいていこうかなんて
思い至る。


とりあえず1~2月頭までの進捗


戦闘関連

・大勢のキャラの登場

単純に前々からキャラごとに使用するマテリアルやメッシュ情報がインスタンスを一回だけしたものを参照する形にする場合はメモリを食わないのは知っていたのだけど、
InstanceとDestroyを繰り返すと「なんか重いなぁ」状態になっていた。

調べるとどうもこのInstとDestを頻繁に繰り返すことでガベージコレクションっていうメモリ解放の処理の際に危険を及ぼすらしく、このままでは出せて画面に20体くらいが限度なのか・・・?

と途方にくれてたら知り合いから「オブジェクトプール」というこれまた便利な方法があるということを聞き調査、スクリプトを試しに書いて機能を理解したので、キャラの死亡や復活のシステムはこいつを主体に動かすことになった。

あとステージセットアップ時に大量のキャラがGetCompornentをすることになるのをさけるために、
動的な参照はプールマネージャにまかせて、静的な参照はあらかじめプレハブで登録することにした。

ただオブジェクトプールシステムの性質上オンオフ切り替えのため、
復帰時の処理をどうするかが問題になったけどこれまたいろんなゲームのキャラ制御みてると
だいたい予測がついたのですぐに解決した。(肝心のなにをみて予測したか覚えてないw)
これメモになってるのか!?

ダメージ数値表示、エフェクト表示も実装。

ダメージ表示だが、RectTransformで制御するんだけどこれUIがスクリーンオーバーじゃなくて、
カメラ前表示だった場合普通にCanvasの下にいれててもワールド空間の座標を流し込むと、
いちいちWorldtoScreenSpaceとかやんなくてもいいようだ。

ただ大きさを一定にできないから、カメラの距離に応じてなにかしこうもうか悩み中。

それ以外だと映ってないのにUIが見えたりどっかとんでいったりとひどいことになる・・。
どうしたもんか。

・味方、敵AI

1クラスでAI制御を全部やろうとして複雑化、Update内容がとんでもないことになっていたのだけど、ステートマシンという概念を見つけて導入。

とりあえずまだ全部は書き直せてないけどうち1体のステート管理を完了する。
そこで Interfaceやクラス継承、仮想化とかの基礎を覚える。


Unityには関係ないんだけど、
Pythonにクラス継承があることをここにきてはじめて知る。
(いままで3年も使っててしらなかったし、多重継承できるってきいて余計ビックリ)

まぁMayaでの作業の効率化とか程度のスクリプティングだと
まったく使用しなくていいのだけどもw

リグシステムも複数のクラスは作ってたりはしたけど、今見ても継承するほどじゃなかった。
まぁところどころここもっと汎用性高くできるんじゃないの?とかいうところは
C#の基礎やったおかげで、オブジェクト指向プログラミングの便利さの片鱗にふれいろいろアイデアは思いついたので機会があれば書き直してみたいw
(これはUnity作業と関係ないw)


・アニメーション・モデル

まだ本番モデルがないので仮の別モデルを読み込んでアニメーションつけて、
プレイヤーのコンボシステムや移動関連を実験中

ゲーム用のモデルじゃないからマテリアル数と骨数がはんぱなくて重いw
でもおっぱいは揺れる(手付け&やる気アップ)

やっててよかったモーションデザイナー!
でも本番の揺れものはさすがに物理使いたいw


・ステータス関連

ステータスというクラスを定義してあらゆるキャラクターのステータスの箱を用意、
一人一人が持つ形をやめて、ステージ読み込みなどの際にメモリには最小限の情報だけが残ってそいつを関連するやつだけが見に行けるようにした。

レベルアップシステムは導入するつもりなのだけど、
キャラごと個別じゃなくて全員同じステータスの計算式を使う予定だから、
レベルをなげれば自動で計算結果が返ってくるクラスを作成してそいつを呼び出すことにした。


その他


・画面遷移

ほぼほぼ必要な機能と要件をまとめきった。
あとはUIを仮置きしてデータセーブとか読み込むべき情報といらない情報等を
洗い出してメモリになにをもたせるかの仕様を切る。



1か月半くらいで自分的にかなり大きく前進したと思う。
土日をメインにすすめてるからまだまだ先は長いけど
頑張っていくぞー。




2012年4月29日日曜日

Demoreel & Showreel etc...

どうもあまぐりです。

GWですね。
世間では9連休という方もいらっしゃるようですが、
羨ましい限りです。

そういえばチュートリアルの動画やら参考にしているデモリールとか、
ブログでメモしておこうと突然思い立ったのでちょっと紹介しようと思います。

思い立ったが吉日です。


1、Richard Lico Show_Reel

Ricard Lico Show Reel

haloなど数多くの作品のモーションやアニメーションを手がけるRichard Lico氏の
ショウリール。

緩急の付け方が非常に好みで、参考にしています。

2、M&M Heroes 6 -fun reel-

M&M_Heroes_6_fun_reel

ハンガリー共和国にある2D,3Dのアニメーションスタジオ Puppetworks Animation Studio
のいわゆるお遊びリール。

本編で使用されたリールは動画横のリールからどうぞ。

あえてFunreelを紹介。
この動画はクリーチャーが大半ですが、人間のリールもあります。

非常に個性豊かなクリーチャーが数見れるので、
動きのネタやアイデア蓄積に良いのではないかと思います。


3、島田氏が送るパルクールアニメーション

Prkour Animation

CEDEC CHALLENGEという企画のアニメーター列伝Autodesk社のインタビュー
などで紹介された方のアニメーションです。

カメラワークなどもご自身で手がけられたとのことです。
カッコいいポーズの流れが魅力的です。

4、動物の動き・・・

VFX Creature Animation school

以前MOX MOTIONさんのBlogで紹介されていた(はず)、動物ばかりの
アニメーターを目指す人の学校のShowreel。

繊細な動きが多い野生の動物が大変よく再現されています。
これキャプチャーしたのではないかと疑うほどの出来です。

5、ハリウッドアニメーター

Makoto Koyama Animation DemoReel

ニュージーランドのWetaDigital所属のCharacterAnimator、コヤママコト氏の
アニメーションリール。

あの鉄男や猿の惑星など有名タイトルの有名シーンばかりで度肝を抜かれます。


6、鹿男の災難

Meet Buck

学生作品だそうですが、とっても素敵なアニメーション。
メイキングも確かリンク等からいけたはずですので、
気になる方は要check!


7、恋する忍者

Les Dangereux

ちょっと詳細は動画の説明をご覧下さい(英語)
休暇中の忍者が恋をする話らしいです。

短いですが目の動きだけで表情を作っているので目の動きの参考に。


8、pixer studio animator.

Character Animation reel

ピクサーのアニメーター alexis wanneroy氏のアニメーションリール。

ヒックとドラゴンのこのシーンも、カンフーパンダのあのシーンも、
当時はまだ勉強していませんでしたからただただすごいだけでしたが、
今は余計にすごさがわかります。

本当に表情の作り方だけじゃなく緩急や感情間の演技が素晴らしいです。

2011年11月3日木曜日

3DCGアニメーションを始める

Twitterにて発言させていただいた、3DCGのアニメーション・モーションを作る上で
知っていなくてはならない基礎の一部をできるだけ「体で覚えていく」ということと
「ソフトウェアに依存しない」という2点を重要視して、書き出していこうと思います。

3DCGアニメーションをこれから始める方のお役に立てればと思います。

なお、本稿は”ゲーム系に適した省略や誇張の表現”、つまりは筆者の自論が多く含まれています。

全てに対して有効であるかなどは現在模索中でもありますし、なるべく多くの人が理解できる文章を執筆したいと思っています。

駆け出しデザイナーとは関係なく、私の文章力や理解力など至らぬ点があるとも思います。

その場合ご指摘、ご感想をTwitter;AMA_GLY mail : ikoro02*gmail.com まで頂けると幸いです。
*=@に変えて送信して下さい。

長い挨拶は私も嫌いなのでこの辺りで。


ではようこそ手付けアニメーション(キーフレーミング)の世界へ。




本日は”観察力” と ”連動” というものについて記述します。





Capter.1 3D空間でキャラクターを動かす前に

1.現実空間における物理現象を知る

”アニメーション・モーション”と聞くと大抵の方がピ○サー,ド○ームワー○スなどの
フル3Dアニメーションなどが頭に浮かぶと思います。

そしてかの素晴らしい作品群を参考にまず手付けから入ったのではないでしょうか。

しかし”真似して付けても、どうにもしっかり動いてくれない”などという場面に直面した事はないでしょうか?

これはキャラクターが”現実の空間ならばどうなるのが自然な動きなのか”という発想が
抜けている為に起こります。

例えば
なぜモーションキャプチャーの動きは3D空間上で動いてもあんなにリアルなのでしょうか?

手付けアニメですごいと呼ばれているものは、どうしてあんなに重さや空間を感じるのでしょうか?

これは”現実空間”というものを考慮しているからこそなせるものです。

3D空間上にキャラクターがあるとどうしてもキャラクターには”省略された”動きや挙動を付けてしまいがちです。

そしてそのまま3D上でずっと悩んでいても良いアニメーションは付けれません。

そんな時は一度現実の人間をよく観察しろ、と言われた事はないでしょうか。

しかし現実の挙動を観察して付けるなんて「リアルじゃないキャラクターには不自然じゃないの?」

と思う方がいると思いますが、大きな間違いです。

リアルじゃないキャラクターはあくまで現実の人間を、或いは現実にあるものに
”ディフォルメ”を行った表現の一つなのです。

これらを付けるにもきちんと”現実空間”が取り入れられないと良いアニメーションは
付けられないものです。

イラストに置き換えると解る人もいるのではないでしょうか。

絵が上手い人とは”観察力”がある人だと言われています。つまりデッサン力です。

アニメーション、モーションに至っても”観察力”は同じ様に重要です。

「じゃあ自分は絵が下手だから3DCGアニメーションは無理か。。。」

安心してください私も下手です。

しかしそんな絵が下手な私がプロになれた考え方を少しご紹介します。





 1、現実空間での人間と3D空間でのキャラクター

それではさっそくリアルの人間について。

現実空間における人間は完全に静止することはできません。
人間は常に、バランスをとり続ける為どこかが動いています。

本論ではこれらの動作を物理現象と呼びます。

例えば人間は歩く際、足から足へと重心を移動させますし、
足が接地した時や地面を蹴る時に体が沈みこんだり、浮き上がったりします。
また左右に垂れる手は前後左右に振られますし、体や顔も当然傾きます。

体の一部が地面や平面に接する時も、いきなりベタっとは付かないものですし、
まるで吸いついたかのように固まることもそうそうありません。

このような事が無意識の内に“自然“に起こっています。


2.より感覚的に現実空間の物理現象を学ぶには

              1、現実空間を再現する為の理論

学び方は諸説ありますが、私が特に注目したのは
“自分でやってみてどこがどう動くのかを確認する”ことです。

そしてこれを反復して行い、現実空間の物理現象を頭に叩き込みます。

そしてその際に重要視するのは人間の各部の動きにおける“連動”を把握することです。

3.連動とはなにか?

              1、連動とは

いきなり連動といわれても何の事かしっくりこないと思います。

連動とはもっと極端にいうと”現実の物理現象の基本となる遅れの表現”です。

2Dアニメでは”のこし”などと呼ぶあの表現方法です。

遅れとはなにかをお話する前に、
まず動きを付ける上で必要な人間の構造についてお話します。



人間の構造と言われると、美術系の学校へ行かれていた方や現在学修中の方ならば一度は目にしたあのグロテスクな人体解剖図や筋肉の流れ、そうでない方は人体模型などを想像されたと思いますが、
私はそういった構造理解ではなくパーツを別のモノに例えて把握しています。

例えば

背骨は、衝撃を吸収しやすくするためバネのような構造になっています。



つまり背骨はバネに置き換えて動きを考えます。

バネとして解釈すると次のような事が言えます。
背骨は真っ直ぐの状態から右へ引っ張れた後、元の位置に戻るには左へ行きすぎてから元の位置に戻るのが自然な動きである。




これは背骨の現実空間における物理現象の一例です。
これだけでも人間が体を右へ傾けた後、元の姿勢に戻る為に少し左へ行きすぎてから元の位置に戻るのが自然な動きだという事が解ります。

              2、”自然な動きを捉える”

ここで「いや、やろうと思えば行きすぎず元の位置へ戻れる」と思った方は、
そこが重要です。

やろうとしてできてしまう動きは、“既に自然な動きではない”ということに
注目しなければいけません。

しっくりこない動きの中にはこういう“全て自分から動かしてしまっている動き”
つまりは“無理な動き、不自然な動き”になっているものが大半なのです。

無理な動きや、不自然な動きをさせると当人はよくても、やはり見る人にとっては違和感      が解ってしまいます。

人間のパーツの自然な動きを把握することで動きを再現することが可能です。


 “自分で動いてどこがどう動くのか確認する”。
“街ゆく人を見てどのような動きが自然の中の動きなのか観察する”。

              3、連動を理解する

さていよいよ連動です。

前述では背骨の自然な動きをお話しました。
背骨は別の場所へ向かい、戻る時は逆の方向に行きすぎてから戻るのが自然であれば、
“当然その上にくっついている頭蓋骨も同様に動く”はずですね。

しかし背骨と同じタイミングで頭が元の位置に戻ると腰から頭が棒のように見え、硬い動きになりすぎて違和感が生まれます。


ここで必要な見解が“連動”です。

人間は各パーツに動きの軸となる部分が存在します。

その軸となる部分からより近い箇所から動き、遠い部分は遅れて動きます。
この部分をきちんと付けなければ現実空間を再現していることにはなりません。

背骨と同じタイミングで頭が動くと違和感を感じるのはこういった理屈です。

背骨の動きに合わせて頭も遅延させて動きをつけることで、この違和感を無くすことができます。


     どちらも少し大袈裟ではありますが、印象は変わったと思います。 

手足も同様です。 手ならば 肩→ひじ→手→指 足ならば 骨盤→ひざ→足→つまさき
このように動きが遅延して連動していきます。



4、連動は決してひとつのパーツに終わらない

一繋がりの人間のパーツについてお話しましたが、
決して人間のパーツはその部分だけが動くことはありません。

どこかが動けばバランスをとる為に必ず別の部分が連動して動くものです。

例えば右手を上げる動作をとる場合で考えます。

人間が右手を上げる為に必要な動作を、連動する箇所を挙げながら
順番に並べていきます。

体の右側を動かす為に、体の左側に力を入れます。
骨盤が少し左へ傾きます → 腰の位置が左足に少し近づきます → それにより重心が左へ傾く為左ふとももが張ります → 胴体が左へ傾きます → 左肩が下がります → 右肩があがります → バランスをとる為左ひじが体から離れます → 左手が体から離れます → 右ひじがあがります → 右手が上がります → 最後に右手の指がようやく上を向きます。



何度もやると肩が痛くなります。たまには肩を回しましょう。

*ポージングとは異なる視点のモノですので、このポーズを付けていくと自然になるわけではありません。
あくまで動きひとつひとつを切り分けて考えていきます。


一瞬の動作ですが細かく動作を書きだしていくと人間は腕をあげるだけでもこれだけ細かく体を動かしているかと思います。

実際に行ってみてください。
力を抜いて順番に行っていき、無理な体勢にならなければそれが自然な動きです。

もちろんキャラクターに投影するにはこれらを誇張または省略する必要が出てくるのですが、まずはこういったものへの観察を怠ってはいけません。

また、よりリアルなキャラクターにリアルな挙動をつけるためにはこれらを正確につけなければなりません。

キャラクターにこういった“連動”を再現する事で、現実空間の物理現象を
3D空間上により正確に表現することができます。



5、人間の各部の可動域、可動性を考える
             
1、各部の可動域

連動も重要だと思われますが、更により自然なアニメーションをつけるには
各部分の“可動域“なども考慮にいれなくてはなりません。


可動域が考えられていない例として

手首がありえない捻られ方をしている。
足首がありえない捻られ方をしている、またはひざがありえない方向を向いている。
胴体(腰、胸、肩)がそれぞれ左右に90度以上曲がっている、または位置がずれている。
骨が感じられない連動感をかましだしている。(意図もなくただふにゃふにゃしているなど)

「YO、YO おまえ膝とつま先別々の方向に向けれるかい?」


特に物理演算によるもの(ラグドール)などでキャラクターが倒れるシーンを見た事がある方    は、最後の項目での違和感を直に感じたのではないでしょうか。

例として腕の可動域を考えます。

腕は肩を中心に可動します。体がとても柔らかい人など特殊な例を除くとある程度自然に可動できる範囲は限られているものです。

例えば伸ばしきった左腕を背中のほうに引き、そのまま腕を曲げずに右手に触る事はできません。



腕を右手側に曲げるにも真上を向いていたひじを左に捻らないといけません。


前に出しても同様です。

また右、左手首を反り返しても、指は腕に触る事はできません。




物を押した時、立ちあがる時に地面に手をつく時、
無理な関節の曲げ方をしているとやはり無理な動きになってしまいます。


*机についた手に力を込めた状態から、上体を起こすという動作のポージングによる
変化の違い。

左側は起き上っているのに手の角度に全く変化がなく、手が固まって見え、
上体も無理にそらさないと手を伸ばせません。
これでは手を使って机を押しているようには見えません。

右側は手首の角度を意識した状態です。自然と手も離れていき、上体もしっかり起き上ってい   るのがわかります。

実際にやってみましょう。

周りから変な人と思われるくらい大袈裟にしてみてください。

どうでしょうか?指を使って手を離していく感覚は。

こういった可動域と連動との関係にも目を配り、観察しましょう。

この辺りの知識はまだまだ僕も考察中です。

本当に”リアル”なアニメーションの為には、人体の構造をきちんと把握する必要があり、
時には解剖学的視点から抑えなければならない場合もあるでしょう。

しかしそういった知識からアニメーションに入るには敷居が高すぎますし、
他にも演技や演出、キャラクター性など考えなければいけないところが山ほどあり、
プロでもそんな余裕はないと思います。

前述した通りデザイナーに必要なのは”観察力”です。

しかしこういったモノを見る力は、自然と養われるものではありません。
興味を持って観察しようとしてから初めて養われるものです。

始めは好きなものからでも結構です。

頭の先から指先、つま先にいたるまで普段のなにげない動作を一度見方を変えて
見てみてください。

客観的に見られる、それが”観察力”だと思います。


本日はここまでです。

ご意見、ご指摘、ご感想は twitter : AMA_GLY か ikoro02*gmail.comまで。
*を@に変えて送信してください。

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

どうもあまぐりです。 こんな時間までなにやってんだろうかと自問自答しているわけだけど、 楽しいから仕方ない。 カバネリとか見ながらずっと作業してて 本日はスキルを仮実装しました。 魔法っていうカテゴリの攻撃にする予定なので、 物理攻撃とは別の計算式も用意して、敵...