2017年11月19日

おい166番、ここまで作っても礼はナシか

何週にもわたってUE4の話題を取り上げてしまって、興味の無い方には申し訳ないのですが、ここしばらくUE4しか触ってなかったので書くことがこれしかないのです。すいません。
何でこんなことになったかというと、既にTwitterの方で上げたのですが、こんな動画を作っていたからです。



なんの気なしに作り始めた動画でしたが、まあとにかく完成まで苦労しました。一週間近く、というかそれ以上かかってたでしょうか、色々と問題があって、それを解消するのに時間がかかってしまってました。というわけで、今回はこの動画が完成するまでのちょっとしたメイキングを書こうと思います。


そもそもこの動画を作ろうと思ったのは、映画オブリビオンに登場するドローン166がフリーのCGモデルとして配布されていたのが始まりです。といってもこれを入手したのはだいぶ前の話であり、当時はPOSERなんかに移植して、ああ、すげー良くできてるなあ、という所で止まっている程度でした。
最近になってふとこのモデルの事を思い出し、そういえばこれをUE4に移植出来たら、さぞかし見栄えが良く映るんじゃないか?と思い、インポートしてみようと思い立ったわけです。
なお、映画オブリビオンを見たことない、知らない、という方は、我がブログで一度レビューしてるので参考までに。
ks_dron166_10.jpg

しかし早速ここで問題発生。このモデルは基本LightWave専用のファイルで配布されており、このままではインポートできません。Blenderやメタセコイアなどで取り込めるので一旦そこで読ませ、fbx形式に変換しようと試みるものの、あまりにパーツが細かいせいもあるのか、エラーで落ちてしまったり、形が正しく読み込めないなど、全く成功しません。うむむ、困った。もう詰みか?
仕方ないので予備で添付されていたObjファイルの方を読みこんでみます。しかし、これもUE4がフリーズしてしまい、失敗。しかし、どういうわけかBlenderでは読み込みが成功したので、一旦ここを経由させてfbx形式に変換してUE4にインポートするとうまくいきました。細かく見ると一部ポリゴンが崩れたりもしてるんですが、全体的にはほぼ忠実に移植出来たので良しとします。

とはいえ、Objファイルはパーツが一個にまとまった単一オブジェクトなため、Lightwaveファイルと違ってパーツ毎に分割とかしていません。とりあえず置物として配置するならこれでもいいんですが、せっかく入れたのなら、動かしてみたいじゃないですか。そうなると、一部のパーツは分離してないと都合が悪いのです。

Blender上でパーツ分解するのが一番良い方法ではあるのですが、残念ながら私はBlenderの扱いには全然慣れていないため、それを学びながらその作業をやろうとすると、どんだけ時間がかかるか分かったもんじゃありません。
そこで、以前ここでも紹介したUE4用のコードプラグインであるMeshToolを使って、UE4上でパーツを分離を試みてみました。こっちならまだ扱いが分かっているので何とかなるんじゃないかという期待があったためです。
ks_dron166_01.jpg

とはいえ、パーツ分離はどっちみち時間のかかる面倒な作業に変わりはありません。幸いMeshToolはLinkなどの便利な選択方式があるため、割とスムーズに行えたかと思います。
とはいえ、もともと超細かいディテールで作られたモデル故に、Meshtoolを起動するとメチャメチャ重くなりました。これ、それなりにマシンスペックが高くないと作業もままならなくなるくらい重くなりそう・・・。
そのうえ、要らない部分を消したりすると強制終了したりと動作が不安定になりがちだったため、少しずつパーツを消していったりとかだましだまし作業を行い、何とか動かしたい部分のパーツ分離に成功。


しかし、これだけでは足りませんでした。Droneは銃器が付いている手に当たる部分が、ボディからせり出すようになっています。しかし、このモデルにはそこの部分は省略されているため、手とボディをつなぐ骨格部分がありません。うーん動かすとなるとここが無いと厳しい。
ks_dron166_09.jpg

そこでネットで探してみると、なんとそこの部分がフリーで配布されているではありませんか。もともと3Dプリンタ用に配布されているデータですが、望みのパーツがあったので、こことかここから骨格パーツを入手。

これは簡単に移植出来たので、大きさを整えて完成。しかし、ボディの方にこれらを組み込むために、ボディ側に穴を開ける必要がありましたが・・・。これも何とかMeshtoolで作業を行いました。

ちなみに、Meshtoolで加工したメッシュは、通常のフィールドでレンダリングすると真っ黒になってしまいますね。しかし、ポストプロセスの範囲内に入ると問題なく表示されたので、UE4では基本ポストプロセスを使う事が大前提みたいです。まあそうでしょうね・・・。

UVに関しては元々マテリアルが細かく設定されていたのでその辺は楽でした。一部光沢のあるマテリアルにする等、軽い変更のみです。しかし、異常な程細かく分けられていたため、Meshtoolで加工するとマテリアルの順番が狂い、その度に設定し直しになるのは厄介でしたが・・・。
とりあえずこれで部品が揃い、完成。
ks_dron166_02.jpg

これでドローン君をUE4上で動かせるようになったぞ、やっほい、という所までようやく来ましたが、はて、どういうアニメーションを作ろうか、と考えたときに、既に購入していたScan FXというアセットが、このドローン君と相性が良いことに気が付きました。
Scan FXは文字通り、スキャンやセンサーといったエフェクトを簡単に描写することが出来るお手軽アセットです。それ以外にも、サーモグラフィ風とかナイトビジョン風とか、いかにもなポストプロセスも入っていて、非常に面白いアセットなんで購入していました。

映画を見た方ならご存知かと思いますが、ドローンは対象物をスキャンして敵か味方かを判断する、というシーンがあります。Scan FXを使えばまんまこのシーンを再現できないか? とふと思い立ったわけです。
そうと決まったら早速製作開始です。ミクと対峙させてスキャンさせる、というおおまかなシナリオも出来上がり、ドローンのアニメーションを作成していきました。
ks_dron166_03.jpg

本来ならシーケンサーを使うべきでしょうが、今回はブループリントで管理しました。面倒ではありますが、なんだかんだでこっちの方が後々編集するときに楽なので。
ドローンを全部まとめてひとつのブループリントクラスとし、その中のブループリントでアニメーションを作ります。
おなじみのタイムラインを使って動きを管理するのは、以前ここでもやったドア移動のやり方と同じ。ただ、ブループリントクラス内では動かす対象がアクターではなくコンポーネントという扱いになるので、若干通常と違います。
そこでSet Relative Locationとか、Set Relative Rotationというノードを使って、コンポーネント(各部位パーツ)を動かします。
ks_dron166_04.jpg

動かす前に、必ず変数を使って現在座標をセーブし、加算させるのは同じ。ただし、変数とターゲットとなる対象物はこのままだと互換性がなく繋がらないので、シーンコンポーネントのツリー以下にあるGet Relative LocationやGet Relative Rotationを中継点として使用します。

ドローンの動きはこれで大体出来上がりましたが、カメラの切り替えの方はシーケンサーの方が簡単なのでそっちで管理。
スキャンやドローン目線は当然Scan FXのアセットから拝借して、それを軽く編集して使用。
背景はポストプロセスも含め、Modular SciFi:Propsのアセットのサンプルを多少改変して利用させてもらいました。
ks_dron166_05.jpg


さて、ここまでは割と順調でしたが、また問題発生。今度はミクちゃんの方です。
ミクは今回Tda式のモデル(デフォ服版)をおなじみの専用プラグインを使ってインポートさせ、MMD側でアニメーションを作って、これまたおなじみのMMDBridgeを使ってモーションをベイクさせたvmdファイルを作成して、UE4にアニメーションを取り込みます。
この一連のやり方については、こことかで詳しく解説されています。
プラグインがUE4のバージョン4.16までしか対応してないので、仕方なく今回は4.16で作成してます。まあ取り込んだ後、別プロジェクトに移行させてしまえばバージョンはあまり関係ないんですけど、作業中に幾度と取り込むので、その度にいちいち移行とかやってられないので。

しかし、作ったアニメーションを取り込んでみると、おや、何故か目が動いていない。なんで目だけ動きが移植出来てないのか?
調べてみると、どうもMMDBridge側にも、インポートのプラグイン側にも問題があるようでした。
MMDBridgeでアニメーションをベイクすると、どういうわけか、右目左目のキーフレームだけ全部0座標に上書きされてしまっていました。これは他のモデルでは見られず、Tda式のみで起きていたので、モデル固有の問題みたいですが、何故起きるのかは謎。
ks_dron166_06.jpg

両目のフレームの方は生きていたので、じゃあこっちを使うか、と思っても、今度はインポートすると、フレームが正しく移植されず動かないという結果に。うーん、困ったぞ、全滅じゃないか。
別のモデルを使えば即解決する問題でしたが、このまま放置するのは気持ち悪いので、なんとか打開策はないかと色々試行錯誤した結果、2つの解決法を見出しました。
ひとつは、ベイクする情報を物理のみに限定させる方法。今回は歩かせるとかそういうことはしないので、髪の毛の物理演算だけ再現できれば良かったため、これなら目のフレームはベイクされず元のままです。mmdbridge_vmd.pyをメモ帳なので開き、export modeを1に設定すればOK。
もう一つは、ベイクする前に一旦右目左目の全キーフレームをコピーしておいて、ベイク情報を上書きした後、目のキーフレームを全部削除して、さっきコピーしたものをペーストする、という方法。これならIK情報をベイクしても目を動かすことが出来ます。
しかし、削除とコピペの作業はフレームが長いと割と面倒なので、ちょっと作っては試し出し、というのは難しいですね。

とりあえずこれで何とか問題は解決。ドローン君のアニメーションと帳尻を細かく合わせながら編集し、何とか形になってきました。


最後にドローン目線となるウィジットの作成です。ウィジットはあまりいじったことは無かったので手探りで作っていきました。
まずはドローンのUIを実際の映画で使用されていたものを参考に自作。アルファ抜き状態の物をpsdファイルとして作成すると、UE4上にそのまま移植可能でした。アニメーションさせるため、パーツ毎に分けて取り込み。
色々と各所で解説されているので、配置してアニメーションさせて表示、という所までは割と難なく出来ました。
ks_dron166_07.jpg

問題は、画面サイズに合わせることで、今回はエディターのビューポートに表示すれば良かったので、それに合わせる方法が分からなくて苦労しました。
結局、良い方法が浮かばなかったので、手作業で地道に帳尻合わせで配置させました。ウィジットは良くわからんなあ。

こうして、全てのお膳立てが揃い、ようやく動画が完成。途中で色々と問題が発生したために、中々苦労させられましたが、何とか出来上がってよかったです。
殆どがアセットやら配布モデルやらと借り物ばっかりで、自分で作ったものと言えばアニメーションとウィジットくらいのものだと言うのに、やたらと時間かかってしまって全然内容と見合ってないんですが(爆、まあ色々学べたりもしたので、今後に役立つといいのですが。

動画内でいじられまくったミクが少し不憫に思えたので最後にこんなショットを。
ks_dron166_08.jpg

あー実はこれを作ってる時点でもまた問題が発生してウギャーってなったんですが、もう長くなるのでやめときます(え







web拍手 by FC2
posted by KS(Koumei Satou) at 21:40 | Comment(0) | UE4 | このブログの読者になる | 更新情報をチェックする

2017年11月12日

数字があればもっとセーブ出来るぞ

今回もUE4の話題、前回の続きです。
ライトをオンオフする制御の際に変数を使うという所までやりましたが、今回はその発展形というかもう少し複雑な仕組みを作ろうと思います。といっても処理的には極めて基本的なやつなんですが。


■ノルマを達成出来たらイベント発生

・・・という仕組みは結構汎用性が高く、非常に多用する可能性のあるゲーム的要素ですよね。複数のスイッチを押して初めて開くドアとか、点在するアイテムをすべて拾ったらクエスト完了とか。
で、こういうのどうやって作ったらいいんだろうと、自分の力ではどうにも解決できなかったんですが(爆)、エンジニアの人にやり方を教えてもらって、なんとそんなに簡単に出来るのか、と非常にタメになったのでそれを記しておきます。
ていうか意外とこういう基礎的な事を解説してくれてる所が無いんですよ。みんなこれくらいは自分で解析できるよね、って思ってるんでしょうか。そんなバカな。分かるわけがない(え

やり方は前回やったような2択式のBooleanの変数を使います。とりあえずこれを使って、複数の床パネルを踏んだらライト点灯、という仕組みを作ってみます。
とりあえず2つの床を踏んだらノルマ達成としたいので、Boolean変数を2つ適当な名前を付けて用意しときます。

後は、前回やったライトオンオフの制御の応用です。この辺の仕組みについては前回の記事を参照してもらうとして、とにかく前回使ったブランチノードを使うという事です。
ブランチに繋がっている変数がON設定になっているなら、その先に進む、というのがライトオンオフの仕組みですが、言うなれば、この変数が複数個あるだけの違いでしかないわけです。つまり、複数ある変数がすべてON設定になってるならブランチの先に進む、とするなら、このノルマ達成の仕組みが出来上がります。
とはいえ、前回ではブランチに直接変数を繋げてましたが、当然今回は複数の変数があるのでそういう繋げ方は出来ません。
ks_ue4hensuu2.jpg
そこで登場するのがAND Booleanというノードです。
これは複数のBoolean変数を繋げることが出来るノードで、ブランチと繋げると、その全ての変数がOnかOffになって初めて先に進む、という制御になるわけです。

今回は2つの変数を使うので、このノードにゲットで2つ繋げます。なお、更に変数を繋げたい場合はピンを追加でリンク口を増やせます。
これで基本的な仕組みは出来てしまいました。Tureの先には前回やったライトオンオフの仕組みに繋がってさえいれば、ノルマ達成の制御自体は完成です。
ks_ue4hensuu5.jpg

おっと、床パネル側も指定しておかないと。というかこれも結局は前回やったトリガの仕組みの延長でしかないので、それを複数個用意しておくだけなんですけどね。
今回は、そのパネルの上に置かれたトリガボックスに各変数をセットで繋げ、全部チェックマークを入れておく、という事です。
更に、これらセット変数の先はすべてブランチにつなげておきます。こうすると、どの床を踏んだ時点でも、とりあえずブランチを通ろうとしますが、ノルマが達成していないうちは無反応という事になります。
全ての床を踏んだ時点で各変数がオン状態になるので、ノルマ達成となりそのままブランチを通過しイベントが発生する、という事になります。
ks_ue4hensuu1.jpg

この仕組みを応用すれば、前回やったスイッチによるオンオフでも可能で、スイッチを複数用意して、それらをブランチで繋げれば、全部のスイッチを入れた状態にしておかないとオンにならない、という仕組みも出来ます。


■一定数のノルマに達したらイベント発生

これもまたよくある仕組みですねえ。例えば敵を5体倒したらノルマ達成とか、点在するアイテムを10個中最低でも7個拾えばイベント発生とか。
流石にこの仕組みはBooleanでは難しいので、どうすんの、と思ってたらこれもエンジニアの人が教えてくれました。今度は整数の変数を使えと。
整数(Integer)はそのものズバリ数字です。Booleanがたった2択しか無かったのに比べると、相当に選択肢が増えたセーブ機能って事になるわけですが。

UE4上では緑色の変数、まずは一個用意しておきます。作ったら変数の型がIntegerになってればOK。
とりあえず前回のオンオフ制御を流用し、スイッチを押したら(Eキーを押したら)、という流れを使って、5回スイッチを押したらライト点灯、という仕組みを作ってみます。

Eキーのイベントノードの先に、IncrementIntというノードを繋げます。++という表記になってますが、これ、通るたびに整数を乗算する、というノードらしいです。そこでこの左下に先ほどの整数変数をゲットで繋げます。これで、このノードを通るたび、変数の中の数字が加算されていく、という流れになるわけです。
ks_ue4hensuu3.jpg

更に、ブランチにはEqual(Integer)というノードを繋げます。まあぱっと見分かると思いますが、繋がった2つのノード先の数字がイコールになってれば、右のリンクのBooleanはON状態とみなされる、という事です。
というわけでこのノードにも変数に繋げ、もう片側に5と入力し、Booleanのリンクはブランチに繋げます。これで、変数にセーブされた数字が5の数字と一緒になった時点でブランチを通過できる、という仕組みが出来上がりました。
5回Eキーを押すことで、ライトが点灯する、という仕組みの完成です。
ks_ue4hensuu4.jpg

ただ、このカウンター方式は、場合によっちゃ一回乗算させたつもりが超連続で乗算されてしまい、回数が狂う危険性があります。ノードをループで通ってしまうとなりがちなので、間にDoonceのノードを挟んで一回通るのみとするとか、色々対策が必要になる場合もあるので、注意が必要です。これはまだ色々検討すべき点があるようですな。まあ今回のようなシンプルな仕組みなら問題ないのですが。


■達成したノルマによって発生するイベントを変える

この整数を利用すると、整数の数字によって移動先を振り分ける、という仕組みも可能です。
整数変数はデフォで中身が0になってますが、セットで繋げて、その欄に数字を入れておくと、ノードに到達した時点でその数字に中身が上書きされます。乗算ではなく上書きであることに注意ですが、これにより、入力欄に0と入れておくと、中身がどんな数字であろうと0になるので、リセットなどにも使えます。
ks_ue4hensuu6.jpg

この仕様を利用し、「整数でスイッチ」というノードを使って、数字毎に行き先を変える、みたいな流れが作れます。
具体的な例を言うと、床パネルAを踏んだ状態でスイッチを押すとライトが赤に点灯、パネルBを踏んだら白に、パネルCを押したら青に点灯、みたいな流れとか、Booleanでは中々難しい制御も整数変数なら簡単に出来るわけです。

それぞれの達成ノルマに数字を割り当て、イベント発生時に変数にセーブされた数字と照らし合わせて、行き先を変える、という流れで、これも色々と流用が利きそうな便利なシステムですね。
ちなみに整数でスイッチのノードはswitchで検索すると出てきますよ。
ks_ue4hensuu7.jpg


■ランダムにイベントを発生させる

これも非常に利用度が高いシステムですよね。でも、中々やり方が見出せませんでした。最初はRandom Streamという変数を使う、というやり方を仕入れたのですが、これだとこっちが思うようなランダム制御じゃなくて、確かに最初はランダムで選択してくれるけど、一度選択したら以降はずっと同じ選択を繰り返してしまうという、中途半端なものだったので、他にないのか?と探して見つけたのがこれでした。
結果、変数も使わず、ノードを要しするだけで済みました。Random Streamとは何だったのか・・・。

マルチゲートというノードで、gateで検索すれば出てきます。これも、整数でスイッチノードと同じ感覚のもので、複数の選択肢を用意するのは同じ。
ks_ue4hensuu9.jpg

本来は通るたびに上から順番に選択していく、というもののようですが、randomのチェックを入れとくと、文字通りランダム選択になります。
ただ、このままだと全部の選択肢を通ると機能が停止してしまうので、Loopのチェックを入れておけば延々とにランダム選択が可能になります。逆に言うと、Loopを外しておくと、一度選択したところは二度と通らないランダム選択、という流れが可能という事ですね。


今回はここまで。これらを出来るようになったことで、結構色々なゲーム的制御が出来るようになりました。でも、大半は自力で見いだせなかったものなので、やっぱり素人がブループリントを独学で学ぶのはかなりハードルが高いなあ、とゲンナリです(爆




web拍手 by FC2
posted by KS(Koumei Satou) at 22:16 | Comment(0) | UE4 | このブログの読者になる | 更新情報をチェックする

2017年11月05日

1ビットセーブで充分なのだよ

今回も引き続きUE4の話題を書こうかと思います。
前回はコードプラグインである「Mesh Tool」のレビューを書きましたが、今回は久々にブループリントの話になります。

まあ仕事柄UE4に関わる機会が多くなったこともあり、色々学ばさせてもらってますが、相変わらずブルプリは奥が深すぎて厄介な代物ですねえ。

今回は、私がやり方を覚えた中でも、基本中の基本な事柄ながら、結構気付くまでに苦労した物を紹介しようと思います。
UE4をいじったことの無い人にとってはなんのこっちゃ記事になってしまうと思われますが、まあご容赦ください。


■ボタンを押すことでライトをオンオフさせる

ライトのオンオフについてはネット上にやり方が幾つも上がっていたので、これ自体は簡単なのですが、問題は、スイッチの前でキーを押すことによりオンオフさせるという仕組みを作る事でした。
ks_ue4bpbutton1.jpg

とりあえずライトをオンオフ化させるには、何は無くともライトをステイショナルかムーバブルにしておく必要があります(デフォはステイショナル)。
そして初期値でオフの状態にさせておきたいので、詳細の中にあるRenderingのVisibilityという項目のチェックを外しておきます。これでアクターはいわゆる非表示の状態になります。
ライトをオンオフさせるには、その要領で行います。そこで「Toggle Visibility」というノードを使います。
これは対象物が既に表示されているなら非表示にし、逆に非表示になってるなら表示させることが出来ます。
とりあえずEキーを押したらオンオフ出来るように組みました。(ちなみにキーボードイベントのノードは「キーボード」で検索すると出てきました)
ちなみにToggle Visibilityとターゲットアクターの間に何やら挟まってますが、繋げると勝手に出てくるものなんであまり気にせずに(え
ks_ue4bpbutton2.jpg

これで一応基本の挙動は出来ましたが、しかしこのままでは、フィールドのどの位置にいてもEキーを押せばライトをオンオフ出来てしまいます。
・・・流石にこれはない。やっぱりボタンの側まで行って、そこで押して始めて反応するように出来ないと。
ks_ue4bpbutton3.jpg

イベントTickで監視して、トリガの中にいるときだけ反応させる?・・・いや、というかそれどうやってやるの?とか途方に暮れてましたけど、AnswerHubで答えを見つけ、やっと打開策を見いだせました。ありがたや。

やりかたは、要は変数を使って管理すること。 ・・・うーん変数かあ。また嫌な奴がでてきたなあ。
どーもいまいちまだ私の中で変数というものがどういうものなのか理解できなくてモヤモヤしている状態です。
どこの説明を読んでも、「情報を入れておける箱で、情報の出し入れが可能」という書き方をされていて、「・・・で、だから何?」状態な訳ですが(爆

ただ、これちょっと言い方を変えて「データのセーブ機能」と考えると、ああなるほどそういう事か、とちょっと納得できたような気がします。
「いやちょっと解釈としては間違ってるんだけど・・・」と思われてしまうかもだけど、とりあえず謎の物としてモヤモヤしてるよかはマシという事で。
つまり、一旦ここにデータをセーブしておいて、それを別の所でロードして読み込んで、データを共有させる、みたいなイメージでしょうか。
ゲームとかでセーブ機能は大変便利、だからセーブ機能を持った変数は便利なのだ、という解釈(え
ちなみに、ゲームでも直で全部のデータをセーブ出来るのもあれば、パスワードでセーブするものもあるように、変数にも色んな種類のセーブ機能が用意されています。
今回使うBooleanという赤い変数は、あるかないか、1か0か、オンかオフか、といった、たった2択の情報のみしかセーブできません。
ks_ue4bpbutton4.jpg

しかし逆に、こうしたライトのオンオフみたいなシンプルなイベントにはこういう変数を使った方が分かりやすいしスマートというわけで。
(ちなみにBooleanの変数はデフォルト値が0、すなわちオンオフでいう所のオフ状態になってます)

さて、ボタンの前に来たかどうかを判定するために、ボタンの前にトリガーボックスを配置します。そして、そこからイベントを追加して、OnActorBeginOverlapとOnActorEndOverlapのノードを出します。それぞれ「トリガに触れたら」「トリガから離れたら」イベント発生、という仕組みです。
ks_ue4bpbutton5.jpg

そしてそこに作成しておいた任意のBoolean変数をセットで配置し、BeginOverlapの方に繋げた変数の方だけチェックを入れときます。
これで、いわゆるON状態をセーブさせることになります。逆にendOverlapの方はチェックが入ってないので、OFF状態がセーブされるわけです。
ks_ue4bpbutton6.jpg

さて、これでお膳立てができたので、メインルートのノードを修正します。ON状態の時だけイベントが発生、という仕組みを入れなければならないので。
そこで、ルートの間にブランチノードを挟みます。これは良く使うノードで、条件が満たされて初めてTrueのリンクを通るため、イベント作成やアクションを起こすときは便利です。平たく言うと、Conditionのリンクに繋がった先が「On状態」ならTrueに、そうでなければFalseを通ります。
そこで、ここに先ほどの変数をゲットで繋げます。セットがセーブなら、ゲットはデータロードという事ですね。

というわけで、変数からデータをロードし、読み込んだ情報によってブランチは通す先を変える、という事です。
当然ながら、ロードした情報がONならTrueを通ります。Falseには何も繋げないので無反応という事になりますね。
ks_ue4bpbutton7.jpg

BeginOverlapの状態だと当然変数はONになってるので、Eキーを押せばそのままイベントに繋がります。しかし、トリガから離れるとOFF状態に書き換えられてしまうので、この状態でEキーを押しても、ブランチはFalseを通りイベントは発生しません。これで「ボタンの側にいるときだけ反応」を再現出来ました。

ちなみに、OnActorBeginOverlapなどのトリガーイベントは、とにかくアクターなら何でも反応してしまうので、基本的にはプレイヤーだけに反応させるようにしなければなりません。色々方法はあるようなのですが、一番簡単なのはキャストノードを使う事です。
これまたこのキャストというのがクセ者で、なんだか良くわからない代物なんですが、とにかくここでは一種のフィルタリングとして機能するので、まあそういうものだと解釈しときましょう(え
cast toで検索すると大量に出てきますが、これでフィルタリングしたい対象物の名前を続けて入れれば望みのキャストノードが出ます。ちなみにプレイヤーを示す物はゲームモード毎に違うので注意がが必要です。
(ワールドセッティングのDefault Pawn Classに記載されているやつを使うらしい)
ks_ue4bpbutton8.jpg

これでプレイヤーのみに反応するように出来ました。(このキャストで指定されたアクタ以外の物が触れてもこのキャストの先を通してくれなくなる)

一応これで作りたいものは出来たけど、ライトをオフにしても電灯のメッシュのライトが点灯したままの表現になってるのはやっぱりおかしいので、ライトをオフにしたら、電灯もオフの感じにしたい。
考えられるやり方としては、メッシュを電灯オフの状態になってる物に置き換えるか、あるいはライトの部分のマテリアルだけ変更するか。
ks_ue4bpbutton9.jpg

使っている電灯メッシュが本体とライトで別個のマテリアルを使っていたので、後者のやり方が使えそうなので、それでやってみました。
そのものズバリ、Set Materialノードを使います。
これは、設定したMaterialにチェンジ出来るノードで、メッシュが複数のマテリアルを使っているなら、Element Indexでエレメント番号を指定します。
これでOFFの場合ライト部分のマテリアルを暗いマテリアルに変更させます。逆に電灯をONにした場合は元のマテリアルに戻すため、もう一セット用意。
ks_ue4bpbutton10.jpg

ん、ちょっとまて、ライトのオンオフをトグルのノードでやりくりしてるので、こちらもトグル化できれば簡単だったけど、残念ながらそうではないので、どう繋げればいいんだこれ?
そこで使用したのはFlipFlop。これは、通るたびにAとBのルートを交互に変えて通すというもので、これでトグルの代わりに使うことに。
ks_ue4bpbutton11.jpg

というかブランチのFalseの先にOFF状態を繋げた方がスマートじゃね?と思ったけどまあいいや。

これにて完成。
正直なところ、本当はボタンの前に立って更に視点がボタンの所に向いていて初めて押せる、という仕様にしたいのだけど、流石に現状ではそのやり方を見いだせてないので、今後の課題ですな。
ks_ue4bpbutton12.jpg

ちなみにToggle Visibilityはライト以外でもメッシュなら何でもオンオフできますが、物自体を完全に消してる訳ではないので、コリジョンは生きており、消しても通り抜けすることは出来ないんですけどね。
これを実現するための最適な方法は知りませんが、私の知る限りでは、これと同時に「Set Actor Enable Collision」を使ってコリジョンをオンオフさせるのが妥当かなあ、と。


・・・あれ、たったひとつのイベントを解説してたらもうこんな長文に・・・。続きはまた今度にしよう。
次回は、複数のノルマを達成したらイベント発生とか、一定数のノルマに達したらイベント発生とか、その辺を探求していく予定です。



web拍手 by FC2
posted by KS(Koumei Satou) at 22:52 | Comment(0) | UE4 | このブログの読者になる | 更新情報をチェックする

2017年10月22日

完全自己完結が究極の理想

久々にUE4に関するネタを書こうと思います。
UE4とは何ぞやという所から説明しだすと長くなるので割愛させていただきますが、まあ今回はそれなりにUE4をいじった経験がある人向けの記事になると思うので、別にいいよねって事で。
とりあえず分からない方はまず過去記事とかを参照していただくとよいです。

UE4、あるいはUnityなどのゲームエンジン開発ツールは、サードパーティによるアセット販売も特徴のひとつです。
アセットとは、他のツールにおけるプラグインとかに相当するもので、新たな機能を加えるもの、一から作ると面倒なブループリント機能が既に出来あがった状態のもの、マップ上に配置する各モデルやキャラクター、アニメーションなど様々あり、そういった本来自分で用意しなければならないものを、アセットを購入することでフルスクラッチする手間を省く事が可能になっています。
特にマップ上に配置する背景やオブジェクト作成、アニメーション作成は凄く手間なので、アセットを購入すればそれを配置、あるいは多少修正するだけで済んでしまうので大変お手軽です。
プロの現場が製品版でこれを使うことは中々の手抜きですが、プロトタイプ作成や、個人での開発では大いに助かるので有難いですね。まあ金に物を言わせれば、の話ですが(爆

で、そんなUE4のアセットの中でも私が凄く気になってたものがあって、「Mesh Tool」というコードプラグインです。
ks_meshtool1.jpg

UE4では、中に取り込んだプロップモデル(メッシュ)は基本いじることが出来ず、せいぜい拡大縮小するかマテルアルを変えるかくらいしかできません。UE4やUnityは別にCGモデリングソフトではないので、メッシュをいじりたければ最初からモデリングソフトで作成するか、既存のメッシュなら一旦エクスポートして他のソフトでいじって再びインポートする必要があります。

別のアセットでSUPER GRIDというのがあり、これはBOXのメッシュを簡単に変形させることで基本的なマップの大枠を作成する事が可能になっていて、メッシュをいじれない不満をある程度解消する事は出来ましたが、まだまだ出来ることは少ないです。

で、Mesh Toolです。要はそのものズバリ、メッシュをUE4上で直接いじっちゃおう、というプラグインです。
これ、発売になる前から気になってて、ようやく最近リリースされたのですが、50ドル近くするお値段にちょっと躊躇。でも人柱になる覚悟で買っちゃいました。
ということで、今回はこのメッシュツールを使ってみた感想とか書いてみます。
ちなみにこの記事を書いている時点でのツールのバージョンは1.0.9です。UE4のバージョンは4.17。


メッシュツールのプラグインを有効にすると、画面左側にあるモードの中にMeshToolのアイコンが入ります。マップ上にある任意のメッシュを選択している状態でここをクリックすると、すぐに編集モードに入ります。お手軽です。
注意しなければならないのは、これはマップ上に配置されたメッシュをいじるのではなく、コンテンツ上にあるメッシュ自体を直接いじってしまうという点です。そのため、このままいじってしまうと、オリジナルのメッシュデータを変形させてしまう事になるので、まずは右上にあるプラスボタン(一番左)をクリックして、メッシュをコピーします。これ、つい忘れがちになるので要注意ですね。
ちなみにあくまでスタテックメッシュをいじるだけなのでスケルタルメッシュには対応してないので注意。これは作者本人に対し結構多く質問が飛び交っていました。将来的には対応しようとは考えてるとかないとか。

あとは、上のアイコンで編集するモードを選びます。だいたいアイコンの形状で分かると思いますけど、QuadモードでFace(面)を選択できます。
ks_meshtool2.jpg

後は通常のUE4の編集に準じているため、やり方はほぼ同じです。そのまま移動させれば、面が移動して隣接する面も追随します。ALTでコピー、Shiftで一旦エッジで切って移動させることが出来ます。これはモデリングソフトでの押し出し機能に相当するもので大変便利。

なおInsetという機能があり、選択した面の内側に沿って、あらたに面を作成します。幅は横の入力欄で変更可能。あとはそれを拡大縮小して大きさを変更することももちろんできます。
Extrudeは、選択面を基点にして入っている数値分の大きさで複製される機能。要は押し出しと同じ。連続で押し出し面を生成したい場合は便利な機能です。
ks_meshtool3.jpg

Flattenは、複数選択した面の位置を揃える機能。一番最初に選択した面に対して他が揃います。最後選択に切り替えることも可能。

当然モードを変えれば、頂点、エッジでの編集も可能です。Shift+Altで範囲選択して移動修正も簡単に出来ます。
なお、デフォだとエッジの表示がグレーで見えにくいため、下の方にあるDisplay OptionでEdgeの項目のカラーをもっと分かりやすい色に変えておくとよいと思います。

Edgeモードでは、Turnでエッジの向きを逆転、Bridgeで2つ選択したエッジ間に面を作成することが可能。
Splitでもエッジを作成するけど、これはちょっと法則が良く分かりませんでした。

Vertex(頂点モード)では、Create Faceで複数選択した頂点の中に面を生成することが可能。穴が開いてしまった個所などをこれで埋めることが出来ます。これはいい。
ただ、物によってはこちらの意図しない形で埋まる場合もあるので注意。基本的には3点の三角形埋めでやると間違いがないです。
頂点モードは長さの伸縮やちょっとした形状変更には大変便利ですね。ただ、形が崩れる恐れがあるので、やるときは慎重に。ちょっとクリック選択しづらいのは玉にキズ。範囲選択が無難。
ks_meshtool4.jpg

Objectの欄にあるFlipALLというボタンを押すと、面を全反転させることが出来ます。使いどころが難しい機能ですが、色々いじくった結果、中に必要ない面(ゴミ)が出来た際に、それを消すときに一旦これにしとくと作業がしやすいです。終わったらもう一度反転させればOK。


ちなみに、既存のアセットのメッシュをいじくる時、Objectの欄にあるAuto UVの欄にチェックが入っていると、UVがずれまくる恐れがあります。これはメッシュを変形しても、UVの位置を保とうとする機能で、土やコンクリといったどこに貼っても構わないようなマテリアルなら、UVが変形に合わせて伸縮しないというメリットがありますが、形状に合わせて作ってある決め打ちのマテリアルだと、まあまずズレます。この場合はこのチェックを切って、変形に合わせてUVが伸縮するようにしておけば問題ないです。
ただまあ、流石に面をInsetするとどうしても崩れてしまいがちですけど・・・。

あと、変形させた後はコリジョンも編集しなければなりません。既に単純コリジョンがある場合、メッシュをいじってるだけでコリジョンは元の大きさのままなので。コリジョンは普通にメッシュエディタ上で編集できるから問題ないですけど、面倒ならObject欄にあるSet Use Complex As Simpleボタンを押すと、複雑コリジョンに再設定してくれます。まあでも単純コリジョンあるならそっち使った方が良いですけどね。


ざっと現状分かっているものだけ簡単に解説しましたけど、これだけでも相当いじれます。
ちなみに、ある程度いじった後でそのままビルドしてしまうと、大概レンダリング結果がおかしなことになりがちです。
ks_meshtool5.jpg

あまり形状を変化させず、ちょっと長さを変えただけとか、面を一部割っただけとか程度なら影響はそういう事は起きにくいですが、大幅に形状を変更させた場合は、真っ黒に表示されるなど、色々おかしなことになります。
どうもObjectの欄にあるAuto Generate Lightmap UVという項目にチェックを入れとかないとこれが起きる感じ。
本当にそれが関係してるかどうかは正直まだ謎ですが、修正する前にここのチェックは入れといた方が無難かも。

また、ビルドする前に同じくObjectの欄にあるRecompute Normalと、Build Mesh Distance Fieldsのボタンは押しておいた方が良さげです。(念のためBuild And Sync Lightmap UVのボタンも押しておくと良いかも)
こうしておくと、ビルド後、または再び編集してビルドしなおしてもレンダ結果はマトモになりました。
逆にこれを怠って一度でもビルドしてしまうと、後でいくらこれらのボタンを押しても、そのメッシュは正しくレンダされなくなってしまいました。
他にやるべき設定があるとか、個体差がある案件かもしれないのですが一応私はこれで解決。

ただ、あまりにもいびつに形状を変形させると、これらの処置をしてもレンダ結果が腐りがちだったので、一部のメッシュを大きく突起させるとか、そういう無茶な改造はやらない方が良さげ。単純に分けろよって事ですかね。


また、Face(面)編集モードで、Slab Transformという箇所をクリックするとSlabモードに入り、形状の変形作業がよりシンプルになって非常にやりやすいです。しかも、この時にマウスの右クリックを押しながら左クリックをすると、グリッドが表示され、その場でBOXを生み出すことが出来、簡単にポリゴンを追加させることが出来ます。グリッドの大きさはObjectの欄にあるGrid Optionで変更可能。
これはかなり強力で、Super Gridのような使い方が出来るため、慣れれば簡単に基礎構造を作れそうですね。
ks_meshtool6.jpg

ただ、これは私の環境だけなのかどうかわかりませんが、このモードで変形、あるいはポリゴンを追加すると、ビルドでUVがオーバーラップしてます、という警告が出て、やっぱりレンダ結果がおかしなことになります。
これは前述した解決策を施してもダメで、この機能を使うと確実にUVが壊れるので、現状はあまり使い物にならない印象です。
ただ、何故か大丈夫な時もあったりしてなんだか挙動が不安定な感もあり、バグなのかどうなのかが不明ですけど、まだまだUV周りが怪しいのは確かって感じはするので、アップデートでの修正に期待したいところです。まあ、ここでゴチャゴチャ編集したら、やっぱUV崩れがちなので仕方ない感もありますが。

そのため、現状では、Super Gridみたいな使い方は残念ながら出来ませんでしたが、ちょっとメッシュの形状を変形させたい、要らない部分を消したい、といった要望には十分応えられるので、それはかなり大きいです。
例えば、このベンチもうちょっと幅が長かったら・・・とか、横に出てるコードが邪魔なんだよなあ、とか、そういうアセットでのメッシュのちょっとした変形には大いに役立ちそうです。
以前までなら、そんなちょっとしたことでも一旦エクスポートして別ソフトで編集するしかなかったので、その手間が省けるだけでも凄く大きいです。
選択(Select)方法にもLinkとかCoplanerとか幾つかあるので、要らない部分を一括選択して削除、なんてなことが簡単に出来るので、その点も優秀です。


あと、個人的にこれはデカイ、と思った機能は、テクスチャ編集。選択した面のテクスチャを、移動、拡大、回転など色々微調整が可能なのが凄い。変形してズレてしまった修正はもちろん、既存以外のマテリアルを適応した際に、どうしても一部合わない箇所があるからごまかしたい、向きが逆になってしまってる、みたいなときに滅茶苦茶便利です。
ks_meshtool7.jpg

Texture Mapの欄で色々いじれますが、テクスチャのPanの欄でなぜかVの移動値がデフォで0になってていくら移動させても動かないので注意。ここに数値を入れればもちろん移動可能。
素晴らしい機能ですが、惜しむらくはFitの機能が、いくら複数選択しても個々の面でFitするだけで、その選択面全体でFitしないのが残念。これがあると相当に便利だったんですけどね。

更に凄いのが、選択した面に対して、別のマテリアルを適応させてしまうことが出来る点。メッシュの一部分だけ材質を変えたいとか、そんな時に効果絶大。やり方は、適応したいマテリアルをコンテンツフォルダ上で選択しておいて、変えたいメッシュの面を選択後、Faceの欄にあるAssign Materialのボタンを押すだけ。これで選択しておいたマテリアルが面に上書きされます。
ks_meshtool8.jpg

ただひとつ注意点があって、すでにメッシュの方が複数のマテリアルを使用していた場合、この機能を使うと、全然別の面が切り替わってしまって一瞬アレ?ってなります。
これ、使用マテリアルが増えたことでエレメントの順番がずれてしまうために起きる現象です。直すのは簡単で、上書き自体はうまくいってて適応されたエレメントの順番が違うだけなので、メッシュ側の設定で、正しい順番でマテリアルを入れ替えるだけです。
これちょっとバグっぽい感もあるので修正希望です。まあ現状でも全く問題なく使えてますが。


UV周りでまだちょっと不安な点が多く、正しい挙動をしてるのかどうか微妙、アイコンがみんな英文ばかりでちょっと直感的じゃないなど、まだまだ不満はありますが、かなり強力なツールであることは間違いないです。モデルは全部フルスクラッチするよ、みたいな人には関係ない話でしょうが、私みたいにレベルデザインメインの人間にはいちいち他ソフトを起動させる手間が減って大変ありがたいです。
流石に現状ではこれがモデリングソフトの代わりにはなりえず、微調整や編集程度の使い方に留まりますが、大体その使い方がメインになるでしょうからそういう意味では現状でも相当使いものになりそうです。
ただ、前述したUVの問題がクリアできれば、モデリングも相当現実味を帯びては来ますが。

まだいじったばかりで分からないことも多く、使いこなせばもっと複雑なことも出きるでしょうけど、それは今後の話として、少なくともこれでかなりUE4がいじりやすくなるかなあと期待できます。
作者本人が散々参考動画を上げているので、これでどれだけ凄いか確認しましょう。使い方の参考にもなると思います。相当早回しですけどね。(一応チュートリアル動画も上がってます)
Mesh Toolはマーケットプレイスで49.99ドルで販売中です。
ks_meshtool9.jpg

まああとの大きな問題は、ブループリントとアニメーションだね。
うぐっ・・・頭痛い。




web拍手 by FC2
posted by KS(Koumei Satou) at 21:42 | Comment(0) | UE4 | このブログの読者になる | 更新情報をチェックする

2017年05月21日

設計図は簡潔にまとめましょう

先週に引き続き連続になってしまいますが、レベルデザインツールのUE4に関しての話題を書こうかと思います。
UE4ってなんぞ?と言う方は前回の記事を参照していただくとして、今回はその中の目玉機能、ブループリントについて、触ってみた所感とかを書いてみます。
ks_ue4_02_1.jpg

前回も軽く話したとおり、UE4では直接プログラミングを書くことなく、ゲーム的制御を構築することが出来る「ビジュアルプログラミング」の機能を搭載しており、フローチャートを書く感覚でゲームを作ることが可能です。それがブループリントと呼ばれる物です。
一部のフローをまかなうといった事に留まらず、全てこのブループリントを使って作ることが可能なので、スクリプトを組む必要はありません。なので、プログラミングの知識が無くとも、ゲームを作成することが可能なのです。

ええ、表向きは・・・・・。


とりあえず何かやって試してみましょう。
UE4ではツールを立ち上げた段階で既に簡単なフィールドと、一人称視点なら銃を持った状態のプレイヤー、三人称視点ならマネキンモデルが既に動かせる状態で始まるので、この辺の複雑な制御は作る事無く始めることが出来ます。
なので、まずはフィールドに何かゲーム的な制御のオブジェクトを配置してみましょうか。
となると、まあ私的に思いつくのはドアの開閉ですかね。
ドア制御はとにかくよく使いますからね、特にFPSでは。

ちなみに、かつて私がよく触っていたソースエンジンのHammerEditorでは、Func_Doorという物が用意されていて、これを該当するオブジェクトに割り当てるだけでドアの開閉を可能に出来るお手軽仕様でした。
HammerEditorでは、こうしたゲーム上でよく使われるであろう制御(回転、スライド、パス移動など)が既に用意されていて、それを割り当てて行くことで動的オブジェクトを簡単に制御できたのです。
ks_ue4_hm_1.jpg

さて、UE4では当然それをブループリントでやるわけですが。
凄く簡単な方法としてシーケンサを使うという手段もあるのですが、とりあえず今回はそれはおいておくとして。
StarterContentフォルダの中にドアのメッシュ(プロップ)があるのでそれを配置します。ちなみにメッシュというのは、まあ要約するとフィールド上に配置可能なモデルデータという事です。
ks_ue4_02_2.jpg

ちなみにこれから動かそうとするメッシュには、プロパティ(詳細)の可動性の設定をムーバブルにしとかないと動きません。これを良く失念して「あれ?動かないぞ?」ってなります。
ちなみにこうしたフォールド上のオブジェクトをUE4では通称アクターと呼んでいます。


準備が出来たので、いよいよブループリント。上のメニューにあるブループリントから、レベルブループリントを選択、するとブループリントが開き、この中でノードと呼ばれる物を組み上げていくことでプログラムを書いていきます。
ks_ue4_02_3.jpg

とはいえ、まずどうしたらいいのかサッパリわかりません(爆)
HammerEditorと違い、ドア制御専用のノードとか用意されてないですからね。
とりあえず最初から配置されている赤いノード(Begin Play)がスタートになるので、ここの後に繋げていきます。
Begin Playはゲームが始まったと同時に命令を伝えるノードです。本当はドアに近づいたら開くとかしたいけど、まあまずは動きを確認したいので。

で、どういたらいいかというと、タイムラインノードというのを使うようです。
画面右クリックでリストが出るので、そこでtimeとか打ち込めばタイムラインが出てくるので、選択します。
ks_ue4_02_4.jpg

タイムラインは、中でグラフを書いて、その動きを別の所に伝える働きをします。要するに、0から100になったグラフを書いたら、それをしかるべき所に繋げてドアに指定すれば、その数値の移動をドアがやってくれるようになる、という事のようです。
なんかもうこの時点で、ん、どういうこと?・・ってなりそうだけどまあ気を取り直してやってみます。

タイムラインノードをダブルクリックするとグラフが出るので、そこでFloatのグラフを新規作成します。
ドアを90度回転させたいので、グラフの開始地点を0にし、3秒の地点に90と指定します。これで3秒かけて0から90という数値移動をすることになります。この段階では、まだ単純に数字の変化だけです。
ks_ue4_02_5.jpg

というわけで次にこれを回転という移動方法に変換しなければなりません。そこで必要になるのがMake Rotator。
これをタイムラインと繋げることで、グラフ数値を回転移動に変換します。
タイムラインには緑のFloatグラフ出力ピンが出来てるので、それをZ軸に繋げます。
ks_ue4_02_6.jpg

勿論これで終わりじゃありません。タイムラインはあくまで数値を出してるだけなので、これをドアに伝える橋渡し的なノードが必要です。
これは色々と種類が用意されてるみたいですが、ここはとりあえずSetActorRotationというノードを用意します。
まあ要するに、任意のアクターに回転移動をセットしまっせ、という事でしょうねこれ。
ks_ue4_02_7.jpg

これを、タイムラインのUpdateの出力ピンと繋げます。あと、回転に変換した数値も伝えなくちゃ行けないので、NewRotationの所にMake Rotatorを繋げます。

あとは、この一連の流れを「どの」アクターに適応するか指定しなくちゃいけません。ここ重要。というわけで、アウトライナ上から該当するドアのアクタを直接ブループリントにドラッグアンドドロップして持ってきます。
あとは、SetActorRotationのTargetと繋げれば完成!
ks_ue4_02_8.jpg
最後に左上にあるコンパイルボタンを忘れずに押して起きます(そうしないと動きません)

さてプレビューボタンを押して確かめてみましょう。
ks_ue4_02_9.jpg


あれ・・・・?

なんか変な位置から始まって反対方向に曲がってますけど?


これ、どうやらSetActorRotationがドアの初期状態からタイムラインの移動を適応してるせいで起きてる現象っぽい。
実はドアを90度回転させた状態で配置してたんですよね。
しかしSetActorRotationはそんなの無視してアクタの初期状態(回転させる前の位置)から開始してしまうので、90度ずれた状態で回転していたってわけ。
じゃあどうするのか?っていったら、タイムラインの数値を、ドアの回転させた分を乗せてしまえばいい、てことで、
ks_ue4_02_10.jpg
ドアを-90度回転して配置していたので、タイムライン上で、0秒の所を-90とし、逆に3秒後を0とします。これでズレが治るはず。

これでやっと意図した動きに。長かった・・・。
というか、それくらいそっちで補完してくれよって正直思うんだけども・・・。
ks_ue4_02_11.jpg


なんかイキナリつまづいたけども、じゃあ今度はスライド式のドアの時はどうするのか?っていう。
やることは大体一緒です。
ks_ue4_02_12.jpg

スライド移動の場合はxyzのベクトル移動になるので、タイムラインでは、Vectorという3軸グラフで指定します。
X軸を0-100と指定すれば、X方向に100m動いてくれるはず。
今度はアクタは回転とかさせずにそのまま配置(笑
ks_ue4_02_13.jpg
架け橋として今度はSetActorLocationを用意して、同じように繋げます。
さあ、今度は素直にちゃんとうまくいってくれるかな?


ks_ue4_02_14.jpg

・・・あ、ずれた。(でしょうね!)


これまたSetActorLocationが、今度はxyzの初期位置で始めてしまうために起きてる現象。要するに、座標0,0,0の位置に持って行ってしまってるわけで。その座標がドアの置いた位置より前にあるので、ずれてしまった、というわけで・・・。

いい加減にしてくれませんか(爆


勿論これを直すのも、タイムラインでずれた数値を乗せてしまえば治るわけだけど、もしドアの位置を移動させたとしたら、タイムラインの数値も変えなきゃならなくなるのは至極面倒。
だがそこは大丈夫、ドアの現在位置を取得して、そこから始められるようにする簡単な方法が用意されています。
これを理解すれば同じ失敗は繰り返さなくて済みそうです。

位置を取得するGetActorLocationにVectorの変数を繋げ、(出力ピンで右クリックして変数に昇格を選択すれば作成されて出てくる)それをタイムラインの前に繋げる。
出来たVectorの変数をゲットで配置し、それをVector+Vectorの乗算ノードに繋げ、されにそれをタイムラインとSetActorLocationの間に割り込むように繋げる。
そしてGetActorLocationに該当するドアと繋げればよし。
ks_ue4_02_15.jpg

これで、ずれることなくドアが開閉するようになるんですよ!
おお、なるほど!








・・・・・って、こんなん分かるかい!!


変数とか出てきた時点でもう素人は「は?」ってなるし、そもそも何故こういう組み方をすれば動くようになるのか、ぱっと見サッパリ分かりません。
詳しく見ていけばそりゃ理解できるようにはなるんでしょう。でも、たかだかドアをスライドさせるような単純な動きをさせるだけでこの複雑な構造になってしまうのは入門的に正直どうかと思ってしまいます。
たとえ理解できたとしても、こういう組み方による解決法を自力で思いつける気が全くしません(爆

要するに、実際プログラムを組んでドアを動かすとなったら、裏ではこういう事をやってるんですよ、って事なんだけども、レベルデザインツールでは、そういった事を意識させないで組むことが出来るようになるのが最終的な理想です。
そういう意味では、ブループリントはあまりに自由に組めることを優先しすぎたあまり、プログラムチックに寄りすぎており、未だ素人が理解しづらいものになっています。

本来なら、HammerEditorのように、素人が理解しやすいような、明快に用途が判別できるノードを別途用意すべきでしょう。
上でやったような一連のドア開閉のブループリントを1個のノードにまとめてしまって、ドア特化の物を用意するなど、もっと単純化することは可能なはず。


というわけで、知識のない人間がブループリントを組む場合、結構なイバラの道なのは確かです。これは残念。
ですが、ある程度分かってくれば、だんだんやれる事が増えてきます。大体単純な動的制御なら普通に出来るようになります。ただ現状、理数系向けの概念なので、文系な人間にはどうしても理解が追いつかない感は否めませんが・・・。
前述したシーケンサも使うことでもっと複雑な動きも出来ますが、まあこれはこれで難点も多いので、それについてはいずれ。
これでゲームを完成させるのは難しいかもだけど、「なんかゲームぽい」ものは簡単に出来るようになるはず。後は自分の努力と、UE4側のビギナーサポートがしっかりすれば完璧でしょう。


今回はこの辺で。次回この話題を上げるのはいつになるか分からない不定期シリーズになると思いますが、またいずれこのネタは出していきたい所存です。

まあそういうわけで、とりあえずUE4はレゴ基本セットみたいな、ビギナー用基本ノードセットを早急に用意しなさい。
さあ、早く早く。




web拍手 by FC2
posted by KS(Koumei Satou) at 22:50 | Comment(0) | TrackBack(0) | UE4 | このブログの読者になる | 更新情報をチェックする