月曜日の朝

前回に引き続き、ポーズ中に画面に文字を表示するようにした。
ヒエラルキーウィンドウで右クリック→UI→Textを挿入。
アイテムオブジェクトで試作したものと同じようなスクリプトを作り、Textにアタッチ。
スクリプトの内容はおよそ下記の通り。

• タグから管理者用オブジェクトを見つける。
• 管理者用オブジェクトから管理者用スクリプトを取得
• 管理者用スクリプトの一時停止フラグを参照
• 一時停止用中は文字列をPAUSEに変更する。
• 一時停止解除中は文字列を空白に変更する。

UI挿入時にCanvasとその子オブジェクトであるTextの他にEventSystemというオブジェクトが追加される。
EventSystemではInputManagerで初期に定義されているボタンの名前(”Submit”など)を使用している。今のプロジェクトではボタンの名前を全て作り直しており、一致するボタンの名前が無いためエラーとなった。EventSystemは今のところ必要無いので無効にしておく。これを上手く使うとメニュー画面の入力操作などの実装の手間を省けるのかもしれないが。 最終的にはメニュー画面を表示したいので、文字列一つを変更するだけでなくまだまだ追加する要素がある。そもそも何を表示するか決まっていない。とりあえず所持しているアイテムの個数でも表示すればいいのだろうか。

ゲーム中にいわゆるメニュー画面を表示することを考えて、ポーズ機能を作り始めてみた。
スクリプトの制御でtransformを直接変えたりしている場合は「一時停止フラグが立っていたら何もせずにreturnさせる」などでこれを停止させれば良いはず。
RigidBody を使っている場合は、一時停止フラグが立っている間Is Kinematicをtrueにすればよいと思ったが、これだけでは停止直前に働いていた慣性が失われてしまう。
そこで、停止時にRigidbody.Velocityの値をVector3変数にコピーしておき、一時停止の解除時にコピーした値をRigidbody.Velocityに戻す方法を試してみた。

フラグの管理はシーン管理者のブール変数で行う。
停止の管理が必要なオブジェクトは、シーン開始時にシーン管理者のタグから管理者のインスタンスを取得しており、停止フラグを参照できるようにした。負荷を軽くするため、停止と再開の処理は一時停止管理用のフラグが変わるときにのみ行う事にした。
各オブジェクトは、シーン管理者の停止フラグがtrueになったら、velocityの保存、IsKinematicフラグをtrueにするなどの処理を行ってから自身の停止フラグをtrueにする。
逆にシーン管理者の停止フラグがfalseになった場合は、IsKinematicフラグをfalseにし、保存したvelocityを取り出して自身の停止フラグをfalseにする。

後々アニメーションなどを追加するともっと考える事が増えるかもしれない。

前回、視線の先にあるアイテムを消すところまで実装したのでその先の処理を少しだけ追加。

シーン管理用のオブジェクトを追加。このオブジェクトはアイテム取得や管理以外に様々な管理を行う予定。Scene Masterのタグをつける。
シーンに配置されているアイテムはシーン開始時にタグを使ってシーン管理者を見つけ、Get Component関数でシーン管理者用のスクリプトを取得。アイテムがプレイヤーに拾われた際にシーン管理者のアイテム取得用の関数を呼び出す。拾われたアイテムのオブジェクトは破棄され、シーン管理者が管理しているアイテムの所持数を増やす。

一週間の進捗がこれだけではあまりに少ない。もっとメリハリ付けて作業を進めないといけないはずだが。
どうしても週末で気が緩むとだらだらと過ごしてしまいがちだ。週一のブログ更新とそのネタのための作業を何とかやってはいるが。

前回Physics.Raycastで一定距離のアイテム(などの対象物)に視線が当たっているかどうかを判定するようにした。
この時、レイが衝突した対象物に関する情報がRaycastHit変数に渡されている。
(RaycastHit名).collider.SendMessage((送るメッセージ)) で対象物の関数などを呼び出せる。この時呼び出される関数はpublicである必要は無い。
アイテム側にオブジェクトの破棄などの関数を作って呼び出すと、見た目上はアイテムを拾ったように見える。後で所持品に追加などの処理を追加していけばよい。

コントローラの入力スクリプトはプレイヤーとなるオブジェクトにアタッチしていたが、入力用のオブジェクトを独立させる事にした。
プレイヤーはコントローラで動かす頻度が高い対象ではあるが、いわゆるポーズ画面とかメニュー画面と呼ばれるものを呼び出しているときはコントローラが動かすものはプレイヤーではない。カーソルだったりスライダーだったりと、同じボタンでも状況によって動かす対象を変える必要がある。

一人称視点でアイテムを拾えるようにするため、レイヤーマスクとレイキャストを使うことにしたので覚書を書いておく。以前も使ったことがあるけど、しばらく触らないとすぐに忘れてしまう。

• Physics.Raycastによって得られる情報はRaycastHit構造体で受け取る。
• Debug.DrawRay を使うとScene画面で確認できる光線を表示する。
  引数は 開始位置、向きと長さ、色、消えるまでの時間、カメラから隠れた線を描画するかどうか。
• レイヤーマスクを指定するとビットが1のレイヤーに対してのみ判定を行う。
  ビットのシフト演算や反転などを使うとコードが分かりやすくなる。
• DrawRay は方向も長さも一つのベクトルで指定するのに対し、Raycast はベクトルで方向、float変数で最大距離を指定する。

とりあえずProBuilderで適当にアイテムっぽいものを作って床に置き、レイを飛ばすスクリプトをプレイヤーのカメラにアタッチ。近づいて視線を向ける事でレイが当たっている事を確認できた。
上記でレイが当たるオブジェクトはアイテム用のレイヤーでマスクされている。
RaycastHit を使いアイテムにアタッチされているはずのコンポーネントを取得しメソッドを呼び出す、という流れでアイテムに何らかの操作ができるはず。

とは言ったものの全然進んでいない…。週末にまとまった時間があっても疲れていることを自分への言い訳にしている気がする。もっとモチベーションを高めるにはどうしたらいいのだろうか。
作品を作ることが面白すぎて止め時が分からない、という状態になるにはどうすればいいのか。それとも作品を作るのは楽しいというより苦しいけどやる、というものなのか。単純に作品をつくるという事に自分は向いていないのか。
…という事を考えるのもブログのネタになりそうではある。

ProBuilder のごく基本的なところを触ってみた。
アクションゲームのプラットフォームのようなものとか簡単な構造の建物なら習熟が浅くても作れそうだし、UV編集も何となくイメージは分かった気がする。雰囲気を出せるかはマテリアルとライティングそれぞれの調整のセンスに依存しそうだ。テクスチャに使う絵をまともに用意するとなるとそれだけでかなりの負荷が予想される。センスやらクォリティやらは後回しにして、まずは小さく作って動かす方が先だろうか。

特に斬新なアイデアがあるわけでもないので、既存の作品の劣化コピーにしかならない気がする…というと作っている身としてもモチベーションを保ちづらくなるが。どういう目的で何が作りたいのか分からなくなってきた。これではいつものパターンだ。
時間の使い方はまだまだ改善の余地がある気がするけど、仕事で疲れて帰ってきてから作業をするというのもなかなか骨が折れる…。週末は週末で息抜きしたいし。
しかし、世間で個人製作している人たちはその中で頑張っているわけだ。情熱とか覚悟とかが違うのかもしれない。ハングリー精神というやつだろうか。

あまり卑屈になっても仕方ないので次を考えよう。
アイテムを拾う機能の実装とか、会話の実装とか、メニュー画面の実装とか、簡単なプロトタイプで良いから作ってみることにしよう。

Pro Builderを使う前に基本を学んでおこうと思い、Unity Japanが公開しているチュートリアル動画を見た。

紹介している機能をキーワードで極々簡単にメモすると、

• 基本図形の作成
• 面の押し出しと拡大縮小
• エッジの面取り
• 頂点の結合と分割
• ノーマル反転
• ポリゴン分割
• Pro Gridsを併用して下絵からのシェープ作成
• マテリアルとカラーの設定
• UV EditorでのUVマップ編集
• Poly Brushを使ってふくらみや凹凸を直観的に調整

といったところだろうか。

それにしても動画で学べるのは便利だ。

CGに関してざっと調べた事をメモ。

Unityのレンダリングの3つの要素についてマニュアルを見るとおよそ以下の事が書いてある。

• マテリアル：テクスチャ参照、タイリング、カラーなどの情報を含む。サーフェスのレンダリングを定義する。
• シェーダー：ライティングとマテリアル設定に基づきピクセルの色を決定する。
• テクスチャ：ビットマップ画像。

テクスチャ定義で表面の色や模様は決まるが、立体感や質感を表現するにはそこからさらに光の反射などを計算する必要があり、それを行うのがシェーダーということだろうか。

言い換えると、美術室なんかに置いてあるデッサン練習用の石膏像などは絵を描く人のシェーダーとしての感覚を磨くもので、テクスチャはどの面も真っ白な画像が貼られているという事か。真っ白で模様が無いので、立体感を出すための陰影をとらえやすいのだろう。

これらをひとまとめにしたのがマテリアルなのだろうか？カラーというのがいまいひとつピンと来ない。

ジオメトリというのは平面や立体の形状を表現するデータ一式の事らしい。

立体物の形状を平面に変換するのがUV変換。地球儀を平面の地図に変換したものなどを思い浮かべるといいようだ。または立体物に貼ってあるシールをはがすような感じ。UVというのは単純にXYZに対するもう一つの軸としてUVWのうちUとVを呼んでいるだけの事らしい。

UnityではProBuilderを使用して立体形状を作ることができるので、この使い方を学んでみようかな。今まではメタセコイアやBlenderを少し触ったことがあったが、外部ツールを使わずに完結するほうが手軽な気がする。

3D制作を補助するProGridsというツールについて、以前はパッケージマネージャでPreview Packageを有効にすればインストールできたが、2020.1からはURLを入力しないとインストールできないようになった。

作業としては進捗といえるほどの進捗が無い…。平日の細切れの時間をもっとうまく使わないと日にちばかりが過ぎていく。今のところ週一のブログ更新ができているだけでも進歩したということにしておく。これもいつまで続くか分からないが。進捗が無い時に黙るよりは進捗が無いと白状するだけまだマシ…でもないか。

歩く際にAdd Force関数を使うようにした。
とりあえず歩くことはできるが、違和感なく快適な操作にするためにはいくつもある項目を調整する必要がありそう。加える力の強さ、プレイヤーの質量、空気との摩擦、床との摩擦など。調整が不十分だと歩き始める際の動きがもっさりし過ぎたり、歩くのを止めても床の上を滑り過ぎたりしてしまう。初期設定のままだと壁(を想定したキューブ)にぶつかった際にひっかかって一歩も動かなかった。壁伝いに歩かせるために壁の摩擦を無くしたが、この方法が妥当なのかいまひとつ確信が持てない。
そもそも人が歩くのと、床の上で箱を引きずったり押したりするのは力の働き方が違うはず。足を負傷している場合は別として、人が歩くときには足を地面や床から浮かせて歩くので、単純に摩擦を調整するだけでは自然な歩行にならないのではないか。動摩擦と静止摩擦は別に設定できるが、調整してもうまくいかない。試行錯誤が足りないのか。
とりあえず歩くときに体が浮き上がらない程度に鉛直上方向の力を加える事にした。

ひとまず歩けるようにしたところで地面をそれっぽい見た目に作りたいと思ったが、グラフィックについても覚えることが多いようだ。今まで適当に作ったビットマップイメージをオブジェクトにアタッチして細かいことは気にしていなかったけど、改めてマニュアルを見ると知らない言葉がいくつもある。

大きく分けてマテリアル、シェーダー、テクスチャの理解が必要。それぞれに設定できる項目が多数あり、CGに疎い自分ではマニュアルを読んでも良く分からない。テクスチャのページなどを読んだ限りでなじみのない単語を列挙すると以下の通り。

• カラーチャンネル
• リアルタイム法線マッピング
• ライトのクッキー
• ライトマップ
• dLDR
• プレコンボリューション(フィルタリングとも言う？)
• リフレクションプローブ
• ライトプローブ
• ポストプロセス処理(プッシュ‐プル拡張？)
• テクスチャストリーミング
• メッシュレンダラー
• ミップマップ
• ミップレベル
• UVマッピング
• ジオメトリ
• ガンマ空間

まぁ、分からないなら調べろという事になるのだろうけど。自分の作品を作る上で本当に全てを理解する事に時間を割く必要があるかも分からない。Unity上で設定を変えたりすると何となく分かるものもあるかもしれない。Unity固有の知識なのかCG全般の知識なのかも自分には判別できない部分がある。

この他に、3D空間を自分の狙い通りの雰囲気にするには環境光や照明の設定も理解する必要があるはず。

細かい設定を全て理解したところで、自分のPCはゲーミングPCではないので、高いスペックを必要としない選択肢に限られるかもしれない。

マニュアルもUnityのバージョン毎にあると今更気付いたが、新しいバージョンのものは邦訳されておらずほとんど英語で書かれているので、余計に敷居を高く感じてしまう。

作りたいものは何だろうと考えるといろいろあるけど、FPSに近いものを作りたいのでとりあえず3D空間を歩き回れるように機能を実装。
既存のFPSコントローラを使うのも一つの手だけど、いまひとつ融通が利かなかったり要らない機能があったりするので(理解不足なだけかもしれないが)、カメラを取り付けたプレイヤー役のオブジェクトを自前のスクリプトで動かすことにする。
過去に何度か同じようなものを作っている気がするが、今度は使いまわせるようにパッケージのインポートなども意識して進めたい。

手っ取り早くカメラを動かすためにtransformの座標に移動用ベクトルを加算して座標を直接書き換える方法で移動を実装したが、壁などの衝突判定を正しく行うにはこの方法では不十分。この方法は短距離のワープを繰り返すようなやり方なので、衝突判定に関係なく障害物にめり込んだり壁を通り抜けたりしてしまう。Rigid bodyの使い方をもっと調べてから改善したい。

今までのように三日坊主で投げ出さないためにどうするべきか考えていたら考えがまとまらなくなったので、結局「とりあえず作る」という今までと変わらないアプローチになった。時間がかかっている割に進んでいない。ただ、今までと違ってブログに書く事にしたのでもう少しましになると思いたい。

まだまだ初歩の初歩的な事しかしていないけど、機能を少しずつ実装なり改善なりしていけば形になるのだろうか。