そうだ Unity、行こう。
『Unity Editer 2021.3.15f1』では、物理エンジン（作業環境のCPUやメモリ）の耐久性や演算能力の試験を兼ねて、オブジェクトを連続して並べて、全体感を掴んで自由にカメラで周れるまでで満足していた。今回、あらたにバージョンが更新された機会と米国の景気後退懸念後の金融の世界市場と自身の資産の安定化に因んで、趣味とは何だったのかを思い出すための学習を体験する。
2024年5月4日
球体を転がせれる。オブジェクトの構造や対応付けに必要な作業、カメラワークと被写体との位置関係を把握することができた。『Unity Editer 2022.3.26f1』にてバグに気が付いたけど、オブジェクトに対して属性を持たせたあと、その属性が保管されてあるファイル（データや処理などが含まれる名前空間）のパスが変更されるようなこと（フォルダに移動など）が生じると、処理の対応付けにエラーが生じるのである。ファイルパス（ルート）を自動で書き換える処理が欠落しているか、誤謬があると思われる。Unity Editerのデバグは誰かの仕事のはずなので、スルーすることにした。
2024年5月5日
オブジェクトの名前とは別に、『Visual Script』などにて処理を施すために、プログラムの管理上の識別子を定義しなければならず、名称としては「Tag（タグ）」で統一されている。判定のための監視がともなう処理は、「On Trigger Event」という命名規則などで、ある程度の可読性はある。対象が単一なのか複数なのかの区別にて複数形の「s」付き名目もあれば、とりあえずでお馴染みの「1」「2」「3」等、そして仮称や残骸に見受けられる名目なども混在していた。ビューでの直感的操作によるオブジェクトへのテクスチャの適応において、処理の結果が得られないことから、別途、画像に属性などの加工や修正が必要かなと誤解してから試行錯誤したが、単に対象として選択できてなかっただけであった。オブジェクトをデータとして直接した状態で、試みると適応された。上図の通り、不自然さのある満遍の金光沢から金箔柄に変更した。物理演算の処理で性能不足が原因（遅延やスタック）かもしれず、テクスチャだけでなく、処理の内容や状況によっては、たまに対象を抽出することに失敗することがある。
球体を転がせれることだけでは「楽しさ」は少ない。障壁を設置することで、やり直しのペナルティを免れるために緊張感が生まれた。ついでに、物理としての矛盾を取り除くこととしては、球体が転がる方向と同期する何かしらの力学があるのを表現で可視化されていると良くなると思った。例えば、カラメワークで傾きを演出して工夫するか、一面の床と壁のオブジェクトも傾けるか、ヒトなどの生命体が押しているか、ヒトなどの生命体が球体の上で走っている、という表現である。それよりも、パチンコ玉やビー玉を彷彿とさせる単なる球体から「金の玉」のように扱えることが、「楽しさ」を理解した上で演出するためのヒントになりそうだと思った。あと、咄嗟に「ボーリングでよくね？」という発想の思考回路を転換できることを期待する。
2024年5月6日
Unityエディタのバージョンと、おそらく描画（レンダリング）の様式としてのファイル形式、アセットのフォーマットに整合性がないと、ダミーとしてレイアウトを並べるだけになってしまう。また、ビューからオブジェクトを除去できなくなってしまうという不可解なバグに遭遇した。これらは根本的にシステム構成要素として扱われており、機能を実現するためのプログラムと結合性の高いオブジェクトとして生成されているのかもしれないが、モジュールとして低品質なものもあると心得た。コンストラクタからインスタンスを生成するだけの処理が書き連ねてあるコードで、設計に考慮が足りず、よくある欠陥の結果として知られている現象だと内部構造の予測は簡単だった。楽しさどころではなく、物足りなさを感じて意欲が低下したが、ビルド（単一のファイルとして出力）に必要な機能を取り揃えれて、初めてのビルドには成功した。描画（レンダリング）の様式の変更や廃止になってしまった機能、また、機能を呼び出すためのユーザーインタフェースの部品の欠落など、欠陥となりえる原因が一つでも生じていると、ビルド後の単体ファイルの画面にて、完全停止になってしまう可能性が非常に高いことがわかった。
使い捨てのようなkeyの属性と対になるvalueの値が付帯したモジュールを複製しながら配置も行なった。そして、物理はあるが視認性のない壁、言わば透明の壁を用いて、終了のイベントを設置した。
2024年5月7日
ビルド後の画面の構成要素として「文字」情報を表示させるための機能は『TextMeshPro』という標準のアセットに担わせるのが通例のようだった。実行環境のプラットフォームに依存しない軽量の単一のファイルとして実行させるために、「文字」とその体裁については、別途の記号としてデータの生成が必要になる。つまり、文字コードとして対応付けの処理が完了した文字群のファイルに、もし、脱字のようなことがあった場合、使用できるはずだった文字が実は定義されてない文字コードとして、プログラムに識別されずに、プログラムのエラー（システムエラー）として扱われてしまう。それは、処理の中断をまねき画面の停止を意味する。おそらく、識別時の制御の処理がなければ、文字コードがそのまま表示されてしまうのだろう。理解できると些細なことではあるが、UTF-8や対処法から勉強しなければならない人にとっては閾が高いと思った。たぶん、これの解決は仕事であるが、一回だけでも日本語と常用漢字も含めてパッケージとして環境構築用のファイルに整えておくことが望ましい。
素材として複製用のオブジェクト、いわゆるモジュールの名前と、それの動作に四苦八苦した。
試してみたが、やはり、日本語の表示では、エラー（文字化け）になってしまう。前回の学習で原因を予想できる。また、対処法も浮かぶので今のところだと問題はない。
アセットが含めている一部のコンポーネントに関数の未定義などのエラーが生じると、全てのコンパイルに失敗してしまう。部分的にコンポーネントもバージョンとして更新が可能ならば最新にできる仕様だが、そのインストールを取り消すことはできないので、最悪の場合としてはそのファイルプロジェクトが全て台無しになることを知れた。ダウングレードで解決できるかもしれないが、先に進めることを優先する。台無しになった大半を放棄してから、未確認だった機能だけで作成した。
構成要素の用語としてステージやワールドではなくて『Scene（シーン）』という単位で管理することになる。オブジェクトに制御を用いて、扉の開閉などの仕方よりは、この『Scene（シーン）』の切り替えにおける挙動を確認できたことが良かった。パフォーマンスに影響があると思っていたけど、ビルドに費やされた時間は、もっぱら約20分で、今後は、冗長性も考慮したデザインが必要である。特に考えてないとワンシーンワールド（≒オープンワールド）になる。あと、今回に限らず、キーボードでの操作に嫌気がするから、別のデバイス（一般的なゲームコントローラーなど）での制御も学んでおこうと思った。
2024年5月8日
アセットの種類には、単純にマニュアルとして文書（説明書）のみもある。モデルとしてオブジェクトに適応されていた視覚効果に、描画（レンダリング）の様式の不一致がある場合は、ピンク色で表示されてしまう。単純に視覚上のエラーとしての表現である。付帯しているデータの型違いや、その視覚効果を提供するコンポーネントの欠如が原因に思われる。元のコンポーネントが旧式であったり、その元を探して特定するのが難儀であるため、体験は損なわれるが正常に表示できる別のテクスチャに変更することで困難を凌げれる。ちなみに、オブジェクトの種属として『モデル』は読み取り専用のデータということで、画像と拡張子の問題として透過可能なpng形式や透過の効果を持たないjpg形式と同様であった。
プログラム言語のC#でスクリプトを記述してから、スクリプトファイル（拡張子cs）を作成した。しかし、初めてのUnityスクリプトで、コンパイルエラーやスクリプトエラーに遭遇した。Unity環境下では、スクリプトファイル（拡張子cs）はシステムの構成要素の一部として扱われるため、それらの定義は、スクリプトファイルでも直ぐにコンパイルに使用されて、クラスや関数など（変数等）が登録されてしまう。この性質を素早く理解できたので、コンパイルエラーの原因を特定（デバグ）するのに、さほど時間はかからなかった。具体的には、同じファイル名のクラスとして既に定義およびコンパイル済みなのが、原因だと考えれた。テストも兼ねて新規での作成を優先するための対処を行なって、実装と動作に成功した。
被写体や環境を撮影するカメラへの視覚効果を用いて雰囲気を演出することが重要だと再認した。また、それを盛り上げるように音源を用いること。
思いついたので作成してみたけど、個人的に観てるだけの分には、こちらの方が面白く感じる。しかし、楽しくはないからこそ雰囲気が重要なのかな。
2024年5月9日
手法として定まっている方法のため、環境を整えることに注力した。カメラやシーンへの視覚効果を適応させる方法において、特定のコンポーネントの有無で管理体系が異なる。視覚効果として不自然さのない表現を志すべきだと悟れた。なお、鏡面（リフレクション）の表現を実現するための機能は、想像通りの凄まじい物理演算（論理の矛盾によるメモリリークと同様）に制御を要求するため、頻度などで抑制が必要である。
あまり重要ではない項目と内容は試さずに、雰囲気の演出を再学習した。試験として日本語の文字の生成と表示に成功した。ボーリングのモデルもあったので、並べたが「ボーリングでよくね？」という発想の思考回路を転換できるどころか、偶然にも開発者達と同じ発想だった。次々に期待しよう。
2024年5月10日
演出も兼ねた基礎と基本の再演習になった。シーンの厳密な撮影をしたかったので、調整用の機能を簡易に実装（プログラム言語C#でスクリプトにロジックを記述）した。
その他から『Skybox（スカイボックス）』という環境の背景の変更方法を学んだ。また、シーンへのオブジェクトの並べ方としてグリッドレイアウトを実現する場合は、ツールとして専用のアセットを使用すべきだと知れた。光源の有無によって、煌びやかに滑らかさなどの違いが生じることもわかった。目的や意図に沿ったデザインを目指すべきだけど、全てが理想として具現化するわけでもなさそうで、種類としても豊富になっている。羽でも伸ばした感覚で、ゆっくり探ろうと思う。
ポリゴン数などのデータ量を可視化するパフォーマンスのための専用のツールもある。3Dオブジェクトに関する処理や手法の最適化も仕事だと思うのだけど、今回から「楽しさ」を追求したいので、スルーしておくことにした。画面の構成要素をx, y, z座標として据えて夥しい量の点などで接合するだけの処理から、角度の表現も含めて効率よく効果的に重々しい描画の連続を原理や論理から考えるべきではない。物理演算や処理性能は半導体などに頼って、続きを模索しよう。
2024年5月11日
『Skybox（スカイボックス）』に使用する画像の画質が荒い（色情報の散乱）場合、さらに均一化されてしまって視認性が悪く疲労感も蓄積しやすくなるので、実践の段階でもグラデーションのような既に均一化されている画像を使用することにした。また、アセットとして専用のツールを導入してからグリッドレイアウトを実践した。ツールの実用性として多少の難がともなうこともあるが、多種多様のあるポリモーフィズムだと思って、過ごすことに（スルー）した。
ところが、ツールなのかコンポーネントなのかモジュールなのか標準化の指標がないのか、疎結合になっておらず、必ず手順書が必要の様子に思えてしまった。次第に最適化のためにも部分の抽出による合理化を求められる。隅々まで互換性に配慮して検証することも仕事だと思うけど、あくまでもアセットは観賞用のサンプルという位置付けにしておく。
違和感を取り除くため全面の色調の偏差を意識してから整えた。冷静に客観視すると墓場に見受けれるけど、楽しさを実感するためのヒントを得たと思った。何よりも気になっていたことを実験できて充実感はあった。ベクトルの扱い方に追加の制御が必要に思えて仕方なかったが、やはりこれ（この謎）が視認性や操作性を低下させ、折角の「楽しさ」を削いでいると思う。『1.41の錯覚』か『1.41の悪夢』か『1.41の蜃気楼』という記憶に留めて備忘録にしてみる。何かしらの不必要な傾き加減についての謎は、地球の地軸とまでは言えないが『バベルの塔』や『ピサの斜塔』を彷彿とさせるようだった。なぜ、善良なる管理者の注意義務、善管注意義務が生じて必要になってしまうのかを思い出すことにも繋がった。
2024年5月12日
『Unity Editer』のバージョンによって、『Terrain（テレイン、地形）』の描き方も含めてデータや機能としての扱い方が変更されているようだった。単なる3Dオブジェクトから変形や機能を用いた工夫と工面で「地形」に見立てていたが、専用のオブジェクトとして確立を果たした一方で、移行にともなった文明的な犠牲が生じるようでもある。とはいえ、x, y座標だけによる描画と制御から、奥行きや厚み等の表現としてz座標も描画や制御の対象に加えて、常軌を逸脱するかの如くの連続処理が齎してくれた視覚としての体験は、素晴らしかった。「ライブラリだけでなくボキャブラリーも用いてシチュエーションをエンジニアリング」しているような感覚は、全て朧げだと思うけど、表現の幅を広げるためにもボケない程度に「朧げ」を体験したい人には勧めたい。また、BiosからOSまで、日本語の文字コードに対応済み（依存しない）なのに、どこまでも追いかけられているような追体験を思い出したい人にも勧めれる。そして、しばらくは細部への繊細なこだわりをなしにして、「楽しさ」を秘めたものを見つけようと思えた。
2024年5月13日
創業者達のソフトウェアとしての開発の方針や産業の簡易的な歴史を読み漁った。設計の思想としてUnityだけで完成させることを前提にしておくことが望ましいのかもしれない。面と面が接する際の処理について、主に受動的もしくは能動的に判定するかの二種類を知れた。光学を学ぶためではないが、専門用語として『レイキャスト』というビームと同様の仕掛けもある。最適化のため、接する面の判定が必要にならないオブジェクトは、張りぼてのように構築すべきことを再学習した。処理の回数に着目して、接する面の判定を工夫から工面する必要がある。『レイキャスト』を使用する際に、あのビームが永遠に存在しつづけている状態で積み重なってしまうと、鏡面（リフレクション）の表現を実現するための機能と同種の制御や抑制が必要になってしまうと思った。というわけで、視覚上の表現のために、粒子に見立てて超極小で丸い形状のオブジェクトを極端に並べて、水による「波」や「水しぶき」などを生み出すことは控えておこう。さて、ワンシーンワールド（≒オープンワールド）になるが、総合芸術として完成度（完全性）の高い作品に学ぶことは重要だと思った。準備はしているが、疲労感が凄まじく、それでも「楽しさ」を秘めたものに魅了されて超スローモションでも進めていくことにした。しかし、高次元の直交座標系にて、『1.41の錯覚』か『1.41の悪夢』か『1.41の蜃気楼』として備忘したことを思い出してしまった。もはや、あるのではなく、悪夢になる。
2024年5月14日
備忘の『1.41の錯覚』について、補正もしくは修正するための方法を見出せた。
カメラの被写体にとっての垂直や平行なのか、高度な座標系として正しい水平や平行なのか、斜辺や入射角を考慮してから作業すべきだと学べた。オブジェクト『モデル』のデータとしての内部構造について、管理体系に標準的な法則性を持たせれても統一性は乏しい。今後の懸念事項としては、画面と画像の解像度の問題と同様に、おそらくオブジェクト『モデル』をどれ程のポリゴン数で構築したのかによって、互換性を保てても何かしらの微差や誤差を生じさせる原因になってしまうのかもしれない。ファイルパス（ルート）の走査の手法は、他に幾多もあると思うが、平行のオブジェクトを用いて地形に見立てて、テクスチャを変更するだけでも探すのに苦労した。険しくも長くもなると思いながら、全容のために最適化の作業を促されて、ワンシーンワールド（≒オープンワールド）になる。
2024年5月15日
基本のみを反復して、瞑想したつもりで自身の記憶に留めた脳みそを洗浄（ロンダリング）してから回復した。3Dオブジェクトの形状を形成すること。何層（厳密には現時点で約32層）にも及ぶ多面の構造に重力としての表現の制御が加えれること。接する面と面の判定も用いて、確率を加味して舞台などの演出を表現から創世することも体験できる。月並みの表現を月面に向けるようにするのではなく、月面や惑星とは別の何に向けるかという着眼点に切り替えれた。目的もなく別の何を作業とともに探究してしまうと、無駄が膨大に蓄積されてしまうので、データの保存（ステートフル）等の実装は、さておきにしておく。いつまでも現物なくして表現の制御に時間を費やすのは、不味いということは熟知している。
2024年5月16日
個々人（民衆）の総資産額によって、価値観の変容や、価値の形成に分岐や亀裂が生じると思うけど、思想から設計の意図を汲み取って、Unityだけで忠実に再現して完成を目指すことにした。ユーティリティの道具（Console, Timeline, Cinemachine, etc）を再度にわたって揃え、秘境を巡るように詳細を観察する。
台本（シナリオ）がなくても、正規表現で共通項を汲み取るように『プレハブ（prefabs）』の材料と機能などから識字のテーマとプランを連想できた。
2024年5月17日
作業として『リギング（Rigging）』等を再確認した。動作の確認ができたので、問題なしだと思った。視野を広げるため、豊富になった素材を一覧として眺めることにした。
2024年5月18日
豊富になった素材を一覧として眺めて、演習も兼ねて『氷山の一角』を思い出せた。内生（≒内省）を通して、『氷山』を生み出すのは自分かもしれないと黄昏た。素材のテーマから『ローマは一日にしてならず（イタリアの歴史）』になっており『北欧神話（ゲルマンの信仰）』などへと続けられていた。過去にて、欧州諸国の各人に学ばせてもらったことの本領が活かされたと思った。順序として内容の定義から始めるべきかもしれない。作業の画面では、ありのままの凄まじい『氷山』の表現になり始めてて、微笑んだ。やはり、『波』の表現などは、物理演算としての資源（リソース）を消耗しやすい。まるで、排他的経済水域の資源のように扱い始めた自覚が芽生えたので、以降は多種多様性のスルーにした。
2024年5月19日
3Dオブジェクトを積み上げて『雪だるま』に見立てた。プログラム言語で自動化しやすいように配列等の規則性も持たせているが、ランダムの楽しさを未だに発見できておらず、意外にも長期間の時間が必要に思えた。
進捗を進めて、面積の規模を拡大するためにも、まるで巨人の所業のように描いた。
2024年5月20日
不要になったファイルを削除してから、整理整頓を込めて新しいCG（コンピュータグラフィックス）として移設した。
カメラが被写体から遠方だと、 ドットで描画されてしまうが、細部にまで注視させると、緻密さを確認できる。常軌を脱する数でも、まだ、性能を引き出せれると思った。
『氷山』と『火山』の模型のように地形を形成してから、再現性も高めれた。
2024年5月21日（火曜日：Tuesday）
テクスチャも何層にも及ばせることが可能である。描画の処理を実行させる環境（プラットフォーム）に依存してしまうが、描画の手法や方式が異なることによる画質の劣化を懸念しておく。光源（エフェクト）を用いて、画質の劣化を誤魔化すのも一つの手法だと悟った。
プログラム言語の王道『デザインパターン（Design Patterns）』を習得してから、テンプレートメソッドパターンに擬えて、『九つの世界』を選択した。そこからの今後を考察したいと思ってしまった。歴史の面として抽出する方法から、再び同種の手法などによって考察や比喩が並んでいた。醍醐味の奥深さはあるが目的を定めるべきだと思い、営利、学習、意欲……単語を並べても並べても進捗が捗らなくなってしまった。というわけで、容量としての限界を目処に、疲れない程度にコールバック関数と戻り値（返り値）に見立てた曜日なども計画に定義して進めることにした。それにより、ファイルの名前を汎用的『The_Nine_Worlds_ver.0.0.1』に定めれた。以後の作業の内容も思い浮かぶ。
年代および政治（体制）としての核になる層群的な視点を明らかにすべきこと。
歴史と伝統による構築されてしまった多面的な観点（譜も含む）で、幾多の面まで描くべきか。
全て（9つの世界）を含めてしまうことが、実は間違いだらけになってしまう可能性など。
明日から、的確に抽出するためにも識字にも注力しようと思った。明日は、水曜日（Wednesday）になる！
2024年5月22日（水曜日：Wednesday）
計画として水曜日を迎えた。記号や文字がなく識字等として発展する以前の管理体系（民族の信仰系）を礎にテレイン（舞台に見立てた地形など）を構築するのにも、時間を要する。『時間』という単語や単位に込められた全ての意味や要素を咀嚼すべきではないと思うと、スルーになった。CG（コンピュータグラフィックス）で「何に楽しさ」を宿せれて、「ムービ（映像）」もしくは「ゲーム（玩具）」の面にすべきかを考えて気長に続けていくことにした。量産された多種多様の材料（マテリアル：テクスチャ）が混沌と秩序を物語る。
2024年5月23日（木曜日：Thursday）
構築のしやすさを優先して、テレイン（地形）を5枚だけ並べた。また、照明とカメラの角度を調整した。そして、『曜日』の管理体系を見習って、それぞれ、『---Enviroment---, Tuesday, Wednesday, Thursday, Friday, Saturday』に命名した。暗黒から華麗に始めれた。近視眼では始めれないことは悟った。配列の操作と同様に再配置を前提にして、繋ぎ目等の物理や地理などの視覚的な矛盾は、『セイヨウトネリコ：ユグドラシル（世界樹）』を模範したい。
歴史と伝統による構築されてしまった多面的な観点（譜も含む）で、幾多の面まで描くべきか。
これらの面の描き方を現代の資本主義の観点で用いると、『アース神族の国アースガルズ』もしくは『巨人の国ヨトゥンヘイム』などは、AppleやMicrosoft、Unityという会社の製品が該当してしまうのではないかと心配になった。立場の異なる人からの視点だと、産業や製品の構造を露骨に表現した結果になってしまい、醍醐味を感じられないと思った。『人間の国ミズガルズ』については、13世紀の人々でも化学や物理や地理の難問を解決できないとも思うし、現代社会の市井に当て込むことは無謀でもある。現実も見据えて『妖精の国アールヴヘイム』と『黒い妖精の国スヴァルトアールヴァヘイム』を両軸に仮設していこうと決めた。「全員、妖精（エルフなど）で秘境（ひきょう）を見れる！」
ようやく発想として「ボーリングでよくね？」から切り替えれた。物語れる新しい妖精『ロキ』を追加できる。スーパークラス、コンストラクタに見立てた『妖精』から複製したインスタンスが『ロキ（トリックスター）』という最初を定義できる。カメラの被写体として別の妖精か、『ロキ（トリックスター）』にするかは、未定だけど、派生させて展開することが可能になった。
2024年5月24日（金曜日：Friday）
識字を整理して、作成すべき要素や要件を見出せた。全面の形状や色調を揃えて、雰囲気を保ちながら、昆虫、動植物、人間、道具、機械ではなく『妖精』として絶景のある秘境を巡れるようにすること。一貫性のある体験の構築に臨む。展望として「ビリヤード」も思い浮かんだけど、それとは異なる楽しさを求めたい。『どんな道でも進んで行かなければ山にたどり着かない』というノルウェーのことわざを覚えた。
2024年5月25日（土曜日：Saturday）
今後の懸念事項としては、画面と画像の解像度の問題と同様に、おそらくオブジェクト『モデル』をどれ程のポリゴン数で構築したのかによって、互換性を保てても何かしらの微差や誤差を生じさせる原因になってしまうのかもしれない。
Unity, Unreal Engine, Blender, Studio等の主に3Dオブジェクト（ポリゴン）の密度や座標の解釈と解析において、誤差が生じること。それは、『積算』全般に誤解や誤謬などの影響を与える。しばらくは、氷の結晶や化学薬品の『ホウ砂』などと同様にスルーして、人形ではなく砂の土偶の構築から、再び始めるので、再構築することにした。
象形から偶像に向けるための、基本を作った。すでに細かすぎるけど、緻密に練り上げていく。
螺旋の構造を再構築できた。制御に困難があるけど、緻密に練り上げれる。なお、惑星（太陽）からの照射などの表現において、そのオブジェクトを設置した座標の限界点が極端に延長されるような場合は、有効になり得る総ポリゴン数が広範囲に及んでしまい、ビルドに要する時間やデータの容量に影響を与えてしまう可能性も考慮できた。しかし、スルーにした。
2024年5月26日（日曜日：Sunday）
まず、変動率は数量によって異なり、分散や分布が激しく、渦のような軌道になった。さらに、細かすぎに加えて素早すぎて、正確に捉えることに困難さがあった。螺旋から完全性のある周回（軌道の繋ぎ目を感じさせない）の制御に成功した。まるで、惑星の公転のようだった。
総数の制御と規則性（収縮、膨張など）を与えれることによって、結晶や循環や発生（分離）等、『爆発』『砂塵』『波（水）の軌道』などの表現に展開が可能になった。光を注ぎ、被写体を黄金色に輝かせれると、『黄昏』が生まれるのかもしれないと悟った。
細くも太くも木枯らしのように巻き上げれる『妖精』のオブジェクトモデルが誕生した。形状の形に集約と形成させると、変化の処理に莫大な物理演算が費やされるようだった。変化までも実装する場合の兼ね合いを考えるのは、遷移で誤魔化せると思ってスルーした。まるで、生物が生きてるかのように振る舞い、安定感のある心臓の鼓動（リズム感）で、躍動感を体験できることに楽しさがある。表層の具体として、粒の構成要素数を莫大に調整しつつ、それらの粒をテクスチャに切り替えると、不思議な景観になるのだと思うのだけど、全面のデザイン（雰囲気）も考慮すると、なかなか気が進まない。
2024年5月27日（月曜日：Monday）
Visual Effect Graph(VFG)の前身のシステム（Particle System）を理解してから、それらの結集と更なる制御を加えれる新しいシステムを試した。煙（気体）などの表現だけでも、簡易的に作成できるけど、それに伴う処理において、性能や時間を要する。ダイナミック（複雑多岐）なエフェクトの自然さ（変化の連続）のためには、Visual Effect Graph(VFG)を使用すべきだが、シンプル（単純明確）なエフェクトの連続は、前身のシステムを継続して使用すべきだとわかった。Visual Effect Graph(ビジュアルエフェクトグラフ)と、それの前身のシステム（パーティクル）とで、同じ表現でも、処理に関して圧倒的に重量か軽量かの差異を生じる。今後の分岐点も見出すとすれば、作業の内容と実行してもらう物理エンジンの性能によってしまうが、Visual Effect Graph(VFG)も活用するのが得策に思う。どちらにも醍醐味があった。
全面に対して物理的なエフェクトの影響が及ぶ範囲に、これらのエフェクト（粒の多いオブジェクツ）も反応して、エフェクティブに稼働する。全面と個体との影響の可否を制御しなければならない。これらを忘れることなく、表層の具体について検討に進むことにした。
わかりやすいとは、素晴らしいだった。最上位の構築で積算を誤ると、1000年も掛かるところだった。
2024年5月28日（火曜日：Tuesday）
表層の具体と構築方法について、『地図』の作図や再編、記号学の利便性、変化と遷移の表現などで活路を見出せた。
まるで、蝶々のようだった。形状を同質で合成させる準備は、できていたのだが、豪華な火炎の翼としての形状を授けられた。制御系多次元連想配列の最高峰に思えた。
水面の表現の動作を確認した。リフレクション（鏡面反射）の表現は、雰囲気として必要性を考慮すべきかなと思った。
2024年5月29日（水曜日：Wednesday）
解像度の収縮も一貫性を求めるために、各種のオブジェクトのx, y, z座標と、最大の高さについて、工面を施した。オブジェクトが個別の文明的な発展を遂げる要因も見出せた。秘境に成り得るミニチュアの礎は、脈々と整った。
偶然の産物として、景観から巨人の像の印象を覗けれた。楽しさを作り出すためのヒントになりそうだと思った。そろそろ、面として扱うエレメンツ（elements）も整理しておく。
『妖精の国アールヴヘイム』と『黒い妖精の国スヴァルトアールヴァヘイム』を両軸に仮設していこうと決めた。
アース系統の最上位の集合体：アースガルズ
ヴァン系統の最上位の集合体：ヴァナヘイム（ヴァナランド）
妖精の集合体：アールヴヘイム
人間の集合体：ミズガルズ
巨人の集合体：ヨトゥンヘイム（ウートガルズ）
黒い妖精の集合体：スヴァルトアールヴァヘイム（≒小人の集合体：ニザヴェッリル）
霧の集合体：ニヴルヘイム
炎の集合体：ムースペッルスヘイム
死者の集合体：ニヴルヘイム
時間の経過と複数人による再利用の重ね合いで生じてしまった位置関係等の矛盾については、参考に留めて再編するしかない。既に2軸に分岐してしまった集合体（同一の可能性）もあるため、補完に向けて集合体の解釈と解析を進めていこうと思った。なお、『力学的エネルギー』『力学的エネルギー保存の法則』や『粒』や『自然現象』などの説明や論理を表現するまでが、長すぎる。オーロラ（北極光）で万能的に狐火（プラズマ）でいこうと決めた。
2024年5月30日（木曜日：Thursday）
カメラを自動的に旋回させて、速度感や仕上がりを想定できた。
被写体の大まかな四方を自動的に旋回させて、さらに、自動的に四方のみの切り替えの制御も網出せた。網羅性のある旋回の制御として着々と整えれたので、大成功である。
Visual Effect Graph(VFG)のファイルをエクスポートしてから、他のプロジェクトファイルとの連携性を確認した。既存の同名のファイルに対して、制御がなく強制的に上書きになった。スルーしたけど気をつけようと思った。ついでに、視覚効果のあるカメラを自動的に切り替えて、試験のように動作と耐久を確認した。インタラクティブも含めて他にもサンプルとして作成しておくべきことがあるので、体感や感覚を優先しようと思った。
2024年5月31日（金曜日：Friday）
試しにと思って、入力系と操作系のスクリプトの移植を行なった。不足していた入力系のコンポーネントをインストールして、無事に動作した。入力系のインターフェースとコンポーネントについて、詳細はスルーした。
2024年6月1日（土曜日：Saturday）
入力系のインターフェースとして、ドライバのような拡張版のコンポーネントからの参照方法も学んだ。自動的にカメラを追跡させた場合と、カメラを固定させた場合とで、操作の演算にカメラの位置関係上の加わり方が影響を及ぼすことがわかった。カメラの視点に合わせて、操作の演算も式として工夫や工面などの考慮が必要だけど、のめり込むことではないので、しばらくはスルーにした。
1枚目の地形（テレイン）と2枚目の地形（テレイン）との繋ぎ目を恐る恐る被写体に跨がせた。繋ぎ目に挟まることはなかったが、地形と被写体の大きさ次第では、溝になり挟まることもある。カメラと被写体との距離や、その角度に伴う操作の重要性を窺うことになったが、先述の通りのめり込むことではない。
段差を用いて階段を用意した。それでも難があったので、被写体の跳躍力を向上させて、実験してみると、スケーリングが奇妙になっていたことがわかる。ポリゴン数と重力の表現と制御について、照準と焦点の見方を正すのと同様に、解釈を改めて考察すべきだと思った。変動の事柄や影響において、妙に納得できてしまった。
数学的な関数で全てを描くのは現実的ではないので、『モデル』を構成している『メッシュ』から法線のデータをVFX Graph（Visual Effect Graph）で再利用するために、『ポイントキャッシュ』というデータに変換して、合成してみた。光の粒子（イルミネーション）などで、再利用性はあった。『メッシュ』の精度によって、再現性にばらつきが見られたが、変換の仕方や再構築の手段も含めて検証が必要になった。綺麗だけど、運の良さもいることがわかった。
2024年6月2日（日曜日：Sunday）
人形（成人の等身大）を基準に置き換えて見ると、スケールの基準を考えれた。
地面との接する面の繊細な制御などは、しばらくはスルーしておいて、テレイン（地形）の寸法の目安を見出せた。
2024年6月3日（月曜日：Monday）
シーンの遷移において、簡易的なユーザーインタフェースを用意してから同期と非同期の制御を試した。同期によるシーンの遷移でもプロセスとして『ローディング』の表示を準備しておくべきだと悟った。次のシーンでの容量によって、読み込み速度が変動すると思うが、おそらく、容量次第では、大差ない。動作環境に依存性があるので、スルーした。オープニングのシーンも含めて、ワンシーンワールド（≒オープンワールド）に突き進むことになるが、管理体系の骨格を意識させるための工夫や工面も考えることにした。
一部のアセットでも、全てを使用すると容量が大きくなる。そのため、使用する部品のみに限ることにした。その一過で、『Speed Tree』というサードパティ製品から統合された機能と、それらから『ローポリ（ローポリゴン）』というジャンルのルーツを知れた。オブジェクトに対して『LOD（Level of Detail）』という専用のグルーピングから個別化（マテリアル）で、ブラシとしてのファイルを追加できたが、厚みの制御を加える必要があった。とりあえずは、スルーにしておく。
難儀だったが、アセットから、単体に必要な『Shader』とテクスチャの抽出と移植に成功した。残骸が与えた悪影響を学んで、ファイル管理（バックアップ）のタイミングを悟った。テレイン（地形）に利用するブラシについて、それに過不足の構成要素があった場合などでの使用は、付帯すべきデータが未定義の状態で拡散されてしまうのだと予測できた。つまり、あまり重大なバグではないが、接し面の判定やパフォーマンスに悪影響を与える可能性が高い。また、『Shader』も多種類に派生しているが、デザインも考慮して他種の多用は避けるべきだと思った。以後は無難にスルーすることにした。
2024年6月4日（火曜日：Tuesday）
テレイン（地形）にテクスチャを合成した。テクスチャの解像度の高さと繋ぎ目の自然さにより、違和感が少ない。派生種の多い『Shader』に強依存するよりかは、加工済みによるテクスチャで統一を目指すことを決めた。極端な作り方の例を挙げると、『樹木』や『Speed Tree』という専用のオブジェクトやツールは未使用で、テレインの造形で補える。一旦は、テクスチャの合成による仕上がりを確認できた。また、『気体（雲など）』と『液体（水など）』や『光（粒子）』などの表現においても分岐点を発見できたので、あまり心配することではなくなり、安心した。ただ、被写体が移動可能な『階段』の用意については、しばらくはスルーしておく。
遠方の背景や、それの『雲（ボルメティック・クラウド）』、そして、全面に及ぶ『霧（フォグ）』の濃度などの設定と制御を試みた。雰囲気と体験を構成する要であるけど、全面に及ぶため描画の速度によっては、シーンとして分割すべきだと悟った。カメラと被写体の位置関係も顧みて、部分のみの適応で最適化を試みる必要があるけど、『階段』と同様に、しばらくはスルーにする。
しばらくはスルーにしたけど、正方形の隆起を編み出して縮尺を変更することで『階段』の試作品を創造できた。拡大させると『ピラミッド』にできる。複製と配置に難儀を伴うが、螺旋の階段が脳裏に浮かび、意義はあるのかなと疑問に思った。
しばらくはスルーのはずだったけど、『ローカル・ヴォルメティック・フォグ』という局所のみに『気体（霧など）』を配置する専用のオブジェクトで、再学習した。また、パーティクルシステムによる雪の表現ではなく、VFX（ビジュアルエフェクトグラフ）による『吹雪』を作成した。既に繊細だけど、遠方のカメラからだと、差異が明確にならない。
『風』の機能で木や葉っぱを揺らせたので、一応に試してみた。不要かもしれないが、微笑みを誘えるなら、活用したい。テレイン（地形）を盛り立てれる部品は、一通り揃えたと思うので、デザインの発見と操作の実装に注力することにした。
以前に覚えた『ダッジ』という移動方法について、横軸に対して基準の重力を加算と減算することで実装してみた。移動に関して、単純な座標の転移は、壁などのオブジェクトをすり抜けてしまう。追加の制御が必要になることで、前者の方法が推奨されている。この制御方法ならノンストレスで快適さがあると思う。インタフェースからの値の取得と判定式および条件分岐をスイッチ（Swtich）文で柔軟に定義しようと思ったが、前方移動時と後方移動時での制御も、たぶん容易いので、今回はスルーすることにした。満足できた。
2024年6月5日（水曜日：Wednesday）
『リギング』という手法でモーション（アニメーション）のデータを作成しようと思ったが、規格が揃わないのか、『ボーン（形態の骨格）』も不完全で既に残骸になったのかなどの詳細は不明だが、とにかく『リギング』での不手際が多くなった。冷静に客観視すると、プロトタイプだとしても妥当性のある被写体のモデルを選定すべきだと思った。あらかじめモーションも備えられて、ボーンも安定していると思える被写体のモデルを入手してから、別途の汎用的なモーションに変更してみた。無事に動作した。モーションを最初から作成するのではなく、安定版のモデルのためのモーションを修正することで、ゆっくりと上達していこうと思った。
2024年6月6日（木曜日：Thursday）
安定している『ボーン』と『リグ』から関連と関係式を学んだ。『リグ』というのは、あくまでも、『ボーン』に対して、移動や変形（回転、角度の調整など）の指示を担う基点だとわかった。アニメーションのフレームのキーと同質である。この仕組みを利用して、既にアニメーション（モーション）として作成されたファイルから、『ボーン』の規格と規則性のある『リグ』に従って大量のキーが登録されていることを伺える。つまり、部分的な修正の作業にしても、『リグ』とモーションの生成に使用した同じ機能（ツールやコンポーネント）を用いて、厳密に『ボーン』の規格も揃えておかなければ作業は困難を極める。単純に考えると、オブジェクトの基点としてx, y, z(0, 0, 0)からx, y, z(10, 10, 4)へ直行（直線の軌道）で移動させるベクトル（ベクター）だけだと、アニメーション（モーション）のフレームのキーは二つあれば事足りる。滑らかさのために『リグ』を用いてモーションを生成させた機能によっては、アニメーションのキーとして、x, y, z(0, 0, 0)からx, y, z(10, 10, 4)までの間（プロセスとインターバル）も大量に登録されることになる。『モデル』の『ボーン』の規格と、大きさ（サイズ）によって、『リグ』の基点や内容も変動の幅が生じてしまうことをある程度は解消するためにも、最善のツールやソフトウェアを見つけるまでは、スルーすることにした。
難解だったけど『アニメーション（モーション）』ファイルの移植が偶発的に成功した。インプット系インターフェースから、modifier（キー入力の組み合わせ）とバーチャルカメラの制御も実装していたので、追加でアニメーション（モーション）の制御も実装してから、操作性を確かめてみた。改善する余地はあるが、概ね良好だった。質量（≒体積）と重力と加速度について、事前に実験（シミュレーション）しておくべきだったと思える程の難儀をまたしても迎えたので、それを予定に繰り下げた。
2024年6月7日（金曜日：Friday）
被写体を行動させるための専用のコンポーネント（Character Controller）と、物質との衝突を前提とする通常の重力表現のコンポーネント（Rigidbody + Collider）がある。それに伴って、『メッシュ』の重心（基準座標）について、一概に統一されてはおらず、場合によっては『接し面』などの計算に大誤差（表層とメッシュの位置情報の不一致など）が生じることを知れた。どちらを使い分けるかの見極めに時間を要した。実行環境の物理エンジン（CPU, GPUなど）によっては、『メッシュ』をColliderとして利用することで、繊細な接し面の判定を実現できると思ったけれど、やはり制限や制約が設けられていた。体感としては、後者の方が爽快さがあった。いつかは、繊細な接し面でも、標準になる日が訪れると思うが、現時点のところ長考が必要になった。
2024年6月8日（土曜日：Saturday）
カメラと被写体との角度関係と、地面や斜面との接し面および被写体の傾斜への移動（斜行）や跳躍の制御は、論理としても超難解すぎたけど、実装できた。完全には論理を理解できなかったが、大きな収穫と能力獲得に思えた。また、進捗が捗る成果でもある。更なる精密さを求めつつ最適化に向けて、忘れないうちに合理化を目的にした再実装を急ぐのではなく、デザインに集中することにした。
2024年6月9日（日曜日：Sunday）
実験も兼ねて、プロシージャル（システム）モデリングを学んだ。簡素に言い替えるとデザインのためのフレームワークである。螺旋状の『階段』も、従来通りの『建物』として捉えて立方体から成形した。また、シェーダーグラフ（視覚効果）を作成してから、デザインの作業をするための基本を思い出せた。芸術も加わり、考慮すべきことが増えたが、コンセプトワークやキービジュアルの設計を活かそうと思えた。「楽しさ」もあるので、しばらくは急いで進めることではなく、道具（ツール）や材料などの収集や一覧を優先する。
2024年6月10日（月曜日：Monday）
『建物』に仕立てれた構造的なオブジェクトを『プレハブ（Prefab）』に登録してから、パッケージのエクスポートとインポートで複製した。『人形（キャラクター）』が利用可能な『階段』を螺旋の形状として連続的に成形するにしても、工夫と工面が必要になった。それらを連続して配置するためにも、テレイン（地形）の樹木を修正すべきになったが、その仕方を知れて修正できた。そして、追々、段々になってしまったが、コンポーネントとして幾つかの不備があった機能を補えた。全容の完全性が高まりつつあるが、デザインの検討と並行してスルーしていたことも補完することにした。
移動に関する実装で、全てを完全に理解したわけではなかったけど、理解のために補足すべきこととして、ベクトルの扱い方で、やはり、基準として用いた物とは、戦車とその戦車の大砲の向け方であった。また、標準的に定義されている関数の実行として得られる結果について、「何を対象として算術したのか」という見方で冷静に把握する必要があった。大体の命名規則などからでは推測すらできない仕様である。ある程度のイベントなどのタイミングや頻度、呼び出し方法も学んだ。代入される浮動小数点の値や、それを参照する式によって、可読性が損われる。とはいえ、目的としては「滑らかさ」を実現するための値として多用されている。常に数値などの監視を司るメディエーターパターンによる処理を利用することも多いので、異常に閾が高くなっていた。その他、定数を連続して格納するための型定義（列挙型）もあるが、配列と同様に内容としては重複することでもあるので、スルーした。論理が超難解になってしまう原因としては、『Quaternion（四元数）』という『回転』を表現した数値だった。これが既に『直感的に理解することは困難』として評価されている。初見での直感的でも理解できたのは、四次元か五次元の式や管理軸のことかなと思う程度で、予測としては的中していたので一安心できた。おそらくになるが、的を射るためだと思う。恰も呪文や魔法を詠唱するようだったと悟れた。
光源と色と反射光については、「なぜ、現実的に投影されるのか」という原理を再学習した。また、その一過で、非金属での明るさの度合いや、『グレイカード』という指標も再学習した。そして、『被写界深度』などを流し読みした。幾つかの案を考察するために、『モニュメント』を作成しながらテクスチャや光源等のブレンドも検証することにした。念頭に置くこととしては「楽しさ」が伴う『道』を用意することが前提でもある。
2024年6月11日（火曜日：Tuesday）
余談になってしまうが、Unityの2Dに関する物理演算（2D 物理エンジン）は、『Box2D』である。3Dに関する物理演算（3D 物理エンジン）は、『Nvidia PhysX』である。コンポーネントとして、『Character Controller』と、『Rigidbody + collider』のどちらとも、3Dに関する物理演算なので、『Nvidia PhysX』を使用していることになる。ネットワーク（通信）と連携・連動させることも可能になっており、その場合、主に『Netcode for GameObjects』をコンポーネントとして使用することになる。ところで、複雑多岐にも及ぶ『Quaternion（四元数）』による管理体系（≒組織）が生じていることを顧みれた。しかし、疲労感も蓄積されて進捗としては捗らないので、その他全般はスルーにした。
アイスランドに『ハットルグリムス教会』という建物があるらしいけど、正規分布曲線のグラフを適応させたかのような構造を見習って、あの『氷山』にドア（入口）を付けるだけで良いのかもしれないと思ってしまった。真面目に考えず、地理学も参考に、決めづらいなら間に定めて中間的な表現である。テーマと場所からは逸らさず、写真などから『トゥファの丘』等も参考にしてみる。エジプトなどの建造物は、このテーマだと要らなくなるので、作らないようにする。根本的にマテリアル（材料）が北欧にある物かもしれない。
2024年6月12日（水曜日：Wednesday）
プロシージャルシステムから標準として提供されることになった機能の応用法を見出すために、内装と外観の構造を区別（区分け）してみた。外観の地形を内装に用いた地形やオブジェクトにラップ（wrap）することで、構造体を簡素に表現できる。まさに、光源（ライト）が必要になる。遊び心で『洞窟』や『塔』などを作成する場合は、この閃きを用いてみようと思った。あまりにも巨大で複雑すぎると文明的な疑問が生じてしまうだろうけど、あくまでも『ゲーム（玩具）』という体裁も忘れずに、デザインや操作性の実装などに反映すべきだと悟れた。更なる「楽しさ」の奥深さなどが見つかるまでは、素材や道具（ツールなど）を模索する。不確かで不確実性もあるが、実験や試験のために並べただけだけど、雰囲気が伴って、横軸から行動すると、不思議な体験として生まれ変わるかもしれないと期待もしている。
2024年6月13日（木曜日：Thursday）
幾つかのプロシージャルシステムを試してはいるが、互換性はあっても、残骸と言っても過言ではなく、形骸化していた。代替の機能は標準的に揃っているのを確認できたので、特には問題はない。とはいえ、同様の状態が続くなら、早めにスルーして次々を試すことにした。また、別途の手法や手段を見つけるしかないと悟れた。
2024年6月14日（金曜日：Friday）
唯一と言っても過言ではないぐらい安定しているプロシージャルシステムを見つけれた。複数の『アバター（キャラクター）』の制作（生成および作成）に役立てれる。駒も揃えることもできそうだ。だが、再び難儀が付き纏うけれど、完成に向けて、進捗が捗った。
2024年6月15日（土曜日：Saturday）
『アバター（キャラクター）』からテクスチャ（画像）としての分離と生成、再結合による作成、および、標準的な『ボーン』と『リグ』の規格に揃えれる形態に全てを変換（コンバート、シリアライズ）できた。これらの変換と結合の繰り返しが超難儀だったけど、成功した。汎用のパッケージとして、複製もできた。また、汎用のアニメーション（モーション）も動作することを確認できた。完成に向けて、一旦は『デザイン』と『実装』から離れて、『積算』で計画する。
違和感のない自然な速度で、差し支えもなく直行した場合（等速直線運動）における経過の時間を測定した。概ねでの作業量（工数）を見積もれた。息抜きがてらの尺稼ぎも必要だけど、「楽しさ」を学ぶために、別の資料で探求することにした。
予想どおり、オブジェクトのサイズが巨大すぎたことに気がつかされた。かつての残骸から再学習できたけど、オーロラに縋るように、現代版の最新のコンテントになれば良いなと祈る。
2024年6月16日（日曜日：Sunday）
被写体にVFX（ビジュアルエフェクトグラフ）を重ねて、移動させたり、汎用的なモーションの動作が可動しても特には問題ないと学べた。それらに、接し面のロジックを実装する場合は、工面が必要になるかもしれない。とはいえ、小道具として、とても役に立ちそうだった。また、なるべく、一個の『コライダー』を収縮させたり、ブーメランのように扱おうと思った。そして、別の資料を参考にするにしてもテーマから逸れないように、『音楽』も含めて、検討を始めれた。
2024年6月17日（月曜日：Monday）
44100Hzおよび48000Hzの音源が業務として活用されていることを知れた。それを使用するのには理由があると思うのだけど、おそらく何かしらの評価基準と適合して、標準になっていると考えれる。音や音楽の適合性や整合性について、評価指標に当て込むことを目的に細かく裁断するようなことはせずに、スルーにした。とりあえずでも、デザインも煮詰まり、定まってきたので、オープニングの作成を目的に的を定めようと思った。一旦は、それだけのための音楽を用意するとともに、文字の装飾も準備することにした。
2024年6月18日（火曜日：Tuesday）
オープニングのデモとして、楽曲と文字の装飾による演出の準備ができた。『アバター（キャラクター）』のモーションも新しい動作へと柔軟に切り替えれた。この種類の『モデル』にて、近距離撮影で口パクは可能かの是非も見定める必要はあるが、『シーン』の『レベル』のデザインも忘れずに、今後の計画の詳細を煮詰めることにした。「具体的に楽しさとは」を追求してから、定める時が来てしまった。
2024年6月19日（水曜日：Wednesday）
改めてモーションやエフェクトの使い方を一覧として眺めた。ユーザーインタフェースの呼び出し方や演出の方法も含めて、振る舞いの定義も考えた。デベロッパーツールとしてではなく、あくまでもゲーム（玩具）として考慮しなければならないことを再学習したが、更に調べることにした。上級者向けの実装方法について、経緯は不明瞭だが、納得できることがあって、悟れた。ステータスコードの制御として、何を用いるかが未定であり、スルーできないのである。
2024年6月20日（木曜日：Thursday）
モーションの制御について、基準のアニメーションに『レイヤー』を重ねて、別のアニメーションの一部のみを合成させる『マスク』を適応させた。無事に動作したが、超難儀にも『ボーン』と『リグ』を標準規格に変換できていたことに加えて、さらに基準となる座標等のプロパティの設定すら難儀でも揃えれることが条件だった。部分的に修正が必要に思えた箇所のみ、補正を掛けれたので、この応用で、複合しながらモーションの組み合わせを生成できる。
2024年6月21日（金曜日：Friday）
被写体の素体と画像（テクスチャ）も含めて、モーションや動作の制御として試験のために複製しまくったファイル（Unity C#プログラム等）から、必要なファイルのみをエクスポートして、新しい試験台（別のプロジェクトファイル）に移管させた。被写体の一部として球体を挟み、壁まで加重して当てる処理を追加したが、UnityのC#プログラムとして、名前空間（namespace）に関する難儀が生じる。グローバル変数として扱うべきなのか、ステートフルに実装すべきかなのだが、しばらくは構造の理解のため、検証も含めてデバグに勤しむことにした。
2024年6月22日（土曜日：Saturday）
被写体の位置情報を参照するにしても、冗長的な制御になってしまうことを避けるために、そのオブジェクトと、それのコンポーネントを参照したが、参照頻度の考慮や可読性の観点から最適解に見当が付いた。また、『メッシュ（法線のデータ）』が不要な場合、それを無効にしても差し支えなく、VFX（ビジュアルエフェクトグラフ）を挟み込んで試した。重力表現と制御も含めて、この手段には、まったく、問題はなかった。満足したが、繊細な制御が必要になるので、一応として最適解による合理化を目的に再実装を目論むが、スローですることにした。
モーションの組み合わせが生じる場合での制御の実装として最適解を試した。別のファイルとして実装していた機能との結合になるが、無事に動作している。とりあえずのサンプルのモーションでも角度の調整が必要になるので、被写体の角度として安定しているモーションを見つけておくか、『マスク』による組み合わせで作成しておくべきだったが、それでも険しい山を乗り越えれた状況だと思って、色々を悟れた。
画面にエフェクトが散らつく原因は、すぐに特定できた。被写体の一部として絶対位置座標とともに運んでもらった個別のオブジェクトの絶対位置を固定するために、被写体から分離（絶対位置座標の参照渡し、再結合）等の制御を実装した。言わずと知られる「そこだけ」を実現するための実装方法でもある。それに加えて、部分的な接し面の制御も実装した。おそらく、難儀だと思われる。
2024年6月23日（日曜日：Sunday）
特定の入力を受け付けた後に、呼び出すべきインタフェースの形状や形態は、平面（2D）ではなく、継続して多面体（3D）であるべきだった。ユーザーインタフェースの呼び出し方の工程よりも、ポジションの工程について、検討した。また、平面の層を用いるべきなのかと思ってしまったが、やはり、注視させるべきダイナミックなコンテンツ（3D オブジェクト）のためには、ダイナミックなユーザーインターフェースが必要だった。識字や選択に注視させるには、平面が最適だけど、この場面（ダイナミック）では、別途に開発すべきに至り、悟った。平面（2D オブジェクト）としてのインジケーターの表現を必ずしも使用しなければならないのではなく、注視させるべきダイナミックなコンテンツのための視認性の良いユーザーインタフェースの最適解を見つけて制御として実装すべきなのである。というわけで、しばらくは、それのために注力することにした。
UI（ユーザーインタフェース）も3Dオブジェクトとして同化させてみた。カメラワークも駆使して、画面の中心から注視すべきこととして目的から逸らさないような配慮のある挙動を設計しようと思った。
視覚要素として視認の邪魔にならない表示を考えてみた結果、被写体の後方の地面を対象に、追従型の立方体でインジケーターを表現および制御として実装してみることにした。
2024年6月24日（月曜日：Monday）
3Dのユーザーインタフェースを被写体の後方の地面と同様の座標を頼りに、被写体や被写体以外とも被らない配置としてだけの工面を施した。この場面だと実装することはなく、カメラワークとして追従型になっているのが功を奏した。より複雑にも自然さのあるナビゲーション（モーダルウィンドウ）のためには、検知と対象となりえる座標の参照渡しや部品の転換（転送）が必要になるが、一先ずはでも進捗として捗ったので状況は最良である。バロメーターのように表層の装飾による工夫なども忘れずに、再度、3Dに関するデザインの全般を俯瞰することにした。
なお、環境光による視認性の悪化や劣化を確認できてしまった。環境光の影響を遮断してみると、もはや平面と同質になってしまう。また、カメラの切り替えのタイミングで、再描画の処理を伺わせる。回転が生じる際の度数としての影響も考えられるが、それよりも光源もレイヤー（多層）で分割することにした。
環境光による影響を遮断してから、別途の専用の光源を当て込み、違和感を取り除けれた。この作業がなければ、環境光が届かない場所などで、3Dのユーザーインタフェースも暗闇に包まれたり、著しく光源の影響を受ける場面が生じてしまうのだった。デザインによる調整もしやすくなり、特には問題は無くなった。応用としての雑記ではあるが、光源のノイズを増やすか減らすか、それに加えて色調で平均化を重ねるかによって、画風として『セルルック（アニメ調）』や『墨絵』などにも展開が可能である。対象を『音源』に絞れば波長としての滑らかさに繋がるのだと思えた。しかし、必然的であるが、今回は神秘的で美しさのある描画（≒世界観）を維持しなければならない。
変動することがあり、それを推し量るためのインジケータを用いて、直感的に進行できることに「楽しさ」を宿せるのだと思ったが、その「変動することとは何か」で、金融の世界市場での歴史的な株価の変動を当て込むと不思議な体験へと繋げれるのかも知れないと思ってしまった。
2024年6月25日（火曜日：Tuesday）
重力の表現として、慣性の法則（慣性系）が永続化してしまった。うろ覚えになってきたが重力の表現の対象もレイヤー（多層）で分割できたため、『Environment』という名前で定めた空間のレイヤー（多層）で管理すべきことを学んだはずだが、各種のコンポーネントが保持している値や、コールバック関数とその引数による戻り値などの参照について、一覧で眺めながら検証してみた。非推奨の方法や手段などを知れたが、主には体積や密度に関する構造上の過ちが生じてしまい、追加の制御が必要になってしまう理由を悟れた。やはり、『厚み』に関する制御から目的とは異なる展開へと発展してしまうので、スルーにした。非慣性系への制御の実装として正しい方法を探ることになった。『Environment』を頼りに、各種をめぐる。
2024年6月26日（水曜日：Wednesday）
超複雑多岐で、調べても根本的に不備がともなう様子に見受けられた。仕方がないので、絶対位置座標系と相対位置座標系、および、環境全域に及ぶ物理特性の管理体系と孤立の物理特性、コールバックによる算術として座標値の増減幅の有無等の内部処理を基準にして整理してみた。もはやプラットフォームで制御すべき内容に転じてきたが、「何が楽しいのか」から逸れることなく、目的を忘れずに進めることにした。
一応としてスコープ（≒クロージャー）から参照渡しに必要な定義を確認できた。また、非慣性系の制御として実験してみたかったことを実装してみた。繋ぎ目の違和感が全くない。この手法が正しいと思えて悟れた。かつてから、『シーン』と、その次の『シーン』を継なぐための伝統的手法であったが、現在では、『テレイン（地形、台座）』から、隣接の『テレイン』へ渡せれる。まるで、惑星を自転させているようだった。カメラと被写体の操作性が良く、繋ぎ目で自然さのある非慣性系の制御による実装で、快適な「楽しさ」の表現を見つけれた。ダイナミックに『テレイン（地形、台座）』を遷移させたが、正面から体験できた爽快さは、素晴らしかった。
2024年6月27日（木曜日：Thursday）
カメラと被写体に、景観を巡らせれる爽快感のある制御としての礎は揃えれた。
次に、光源となる照明による照射の種類や範囲の定め方を手段として一覧で確認するため、環境光（名称としては『ディレクショナルライト』）などは、全て遮断した。再学習になってしまったが、この手段のほうが、明度に纏わる管理体系が露出になって、わかりやすかった。何故、VFXは、光っているのかということも悟れた。
全面に及ぶ『霧（フォグ）』の濃度とは、環境光（主にはディレクショナルライト）などによる輝度のようなものでもあり、『ローカル・ヴォルメティック・フォグ』とは、それらによる視覚上の輝度を部分的に歪めるオブジェクトのようだった。いわゆる、陽炎や蜃気楼を表現することに近い気もした。とりあえずでも、制御の対象として捉えるべきことを知れたので、そろそろ、諸々をスルーにした。ダイナミックで爽快さのある操作性を具現化できたことで満足だったが、被写体の格好もダイナミックにすべきだと気がついた。
2024年6月28日（金曜日：Friday）
被写体以外のオブジェクトのサイズが小さい場合や高度による確認が必要な場合などのために、カメラの高度と角度を調整した制御を加えた。これにより、視野を広げれて、視覚の要素を捉えることが可能になる。モードによる遷移を適切に処理できたので、以前より一層としてステータスコードによる管理が重要になった。このケースだと、然程の処理ではないが、何故、困難さが伴ってしまうのかの原因を特定できたところで、既に、難儀になっている自覚が芽生えた。忘れてた『Quaternion』や旋回という動作を感じれた。
総合的に「楽しさ」を見つけれた。それは、高みの見物のように「俯瞰景で範囲を定めて、その周辺の一帯を文字通りのフレアに包む」だった。北欧神話に登場する『ヴェズルフェルニル』という鷹を理解できた気もした。まるで鷹のようなカメラワークにも「楽しさ」がある。
2024年6月29日（土曜日：Saturday）
3Dにおけるユーザーインタフェースとしてルーレット（≒カルーセル）を用いた場合、側面の使用方法を多角的に揃えるべきだと悟れた。また、回転（『Quaternion』の式）が、どのように反映されるのかを視覚的に捉えれた。上方のカメラワークから視認すべきか、被写体と近接のカメラワークで視認すべきかの状況によっては、従来のカルーセルが役に立つと思えた。
「楽しさ」は無かったのと、テーマから逸れそうになったので、スルーにした。テーマから逸れない範囲で、客観的に別の手法やフレームワークを見学しようと思った。
2024年6月30日（日曜日：Sunday）
『Mecanim』というシステムに関する理解が速かったので、主にカメラワークに関するフレームワークが溢れてしまうことに気がついた。如何にカメラワークが優れていても、制作しなければならない物に着眼した場合、それを支えるプロシージャルシステムの重要性を悟れた。顧みても、カメラワークを起点としたフレームワークを実装していることになっている。『コライダー』に関する制御での感圧は、感覚に繋がるけれど、のめり込むことではないと思った。データとしての保存と読込の規格に適合させるために、幾多の手段と構造を再学習した。一時的にメモリを確保し続ける方法と、個別のデータとして形式を揃えておく方法である。やはり、引き続き、GPUアクセラレーション（ハードウェアアクセラレーション）の活用よりも、素材などを一覧から探るしかないと思った。
2024年7月1日（月曜日：Monday）
幾多のフレームワークを見学してみた。とあるフレームワークで『島遊び』の表現は非推奨だという宣言があった頃と比較しても、矛盾した構造に成り果てたのを認識できた。最果てにたどり着いてしまったのかもしれない。長期に時間を要することとして、別の手法を走査するように模索することにした。
2024年7月2日（火曜日：Tuesday）
制御と実装の実践がともなう学習（主には絶対位置座標および相対位置座標、構成要素と構造による重心の定義式、クロス積およびクォータニオンの対象）は、素早く完了にできた。節目に区切ると終わりである。満足できたが、素材と構造が伴う生成（作成）の仕方について、今後もしばらくは模索していこうと思う。
2024年7月3日（水曜日：Wednesday）
動作の原理と良質な疎結合性のある『モニュメント』として、修正してから複製できた。塗り絵の作業が増えてしまうためか、気が進まなくなることもあるため、すっかり忘却していたが、一時保存も兼ねて美しい構造のオブジェクトを模型に移管した。模型にしては、巨大すぎるが、『スカルプト』方式のテレイン（地形）と組み合わせることで真価を発揮できるかもしれない。
2024年7月4日（木曜日：Thursday）
手戻りを生じなくさせるためにも、3Dにおけるサイコロ型（正六面体）のUI（ユーザーインタフェース）を保管した。画面を占める視覚領域の最適化としては役に立つと思った。
2024年7月5日（金曜日：Friday）
その他の全般から、超越関数の代替や、正規化を避けるべき理由を再学習した。それらに伴い、関数による戻り値のことや、『Vector2』『Vector3』『Vector4』におけるベクトルの正規化の有用性を考えさせられた。扱いやすく覚えやすくするためにも、綺麗に整理すると、UnityのC#では『Vector4』から孤立化（サブクラス、インスタンスなどによる分岐や拡張）したのが『Quaternion』に見受けられた。プログラム言語としての扱い方も重要だと思うが、教養として念頭に置いておくべきことを見出せれる。デンマークは英語圏ではあるが、デンマーク語（ドイツ語も含む）などによる言語の体系が反映されている可能性である。というわけで、デンマークの歴史や言語を教養として学ぶことにした。知らず知らず、デンマーク語のようになっていないか、ということも検証してみようと思った。
2024年7月6日（土曜日：Saturday）
失念を予防するために、コライダーの制御として必要な論理を記録に留めた。また、高度座標系『1.41』についての備忘録の続きとして、カメラの旋回における変動幅と、被写体のモーションの振れ幅を安定化（細分化）させることで解消できる。それを以て、あの『謎』と、視認性や操作性などについては、特に注力しなければならないことはなくなった。それだけでも満足だった。しかし、ステートフルの実装を具現化しても、直向きに追加（生成や作成）するだけにはならない。そのため、テーマから逸れないように、再び、他の3Dレンダリングエンジンとプロシージャルシステムを巡る。
「面白み」については、現実と同様もしくは現実的な投影によって、反比例の如く低下していくことを悟れた。意外にも「楽しさ」が欠如してしまうのと同様の理由が思い浮かぶ。「現実には滅多に無い事と物」や「現実には無い事と物」が続くからこそ「楽しさ」を感じるのだと思い出せた。
2024年7月7日（日曜日：Sunday）
記憶に残してから忘却（圧縮）するにも、綺麗に整理した。あくまでもUnityのC#での扱い方であること。座標や回転などに纏わり、マイナス記号の軸が存在してしまうこと。簡素にすると、『ベクトル4』として定義されている項目があり、代入に用いるために、『Quaternion』で『回転系のベクトル4のデータ』を生成しているのだった。また、標準（惑星）としての『回転』は、対象の重心を起点とした『自転』であった。つまり、普遍的には、角度や回転の制御において、x, y, z, wの四点の型でなければならないわけではない。混沌と混乱を招きやすくなってしまう原因として、スーパークラスなのか、サブクラスなのか、コンストラクタなのか定かではないのに加えて、メソッドのように使われていることもあり、もはや型推論のあるような挙動でもあった。構文によるコンテキストの次第には、thisキーワードなどのプロパティが変動してしまうことが予測できる。
2024年7月8日（月曜日：Monday）
再学習になったが、記憶に残してから忘却（圧縮）するにも、綺麗に整理した。入力系のインターフェースの仕様として、ベクトルの正規化は必要なく、入力のデバイスから『-1, 0, 1』などの値として受け取れる。UnityのC#でも、これらの値などを割り当てるためのシステム（Input System）だった。感圧として使用するためには、細断の処理が必要になるが、『Scale（スケール）』にて設定が可能になっていた。詳細についてはスルーすべきだが、幾つかの難点のため、備忘録に記録する。
このシステムにもnormalizeという用語があるが、『ベクトルの正規化』ということより『入力系のデバイスから受け入れられる標準（基準）の値（主には頻度）』という処理である。この基準値などが、『-1, 0, 1』である。
normalize Vector2という用語などがあるが、『二軸の専用の型に標準の値を代入する』という結果であった。つまり、『ベクトルの正規化』を期待して整数値としての『1』などを得るためではない。UnityのC#でも、ベクトルを正規化するための『Normalize』があるため、紛らわしいことになっていた。例として、基準値の『スケール』を変更してから『ベクトル3』に変換した。その『ベクトル3』の例が『(0.00, 0.00, 0.02)』である。
その基準値の『スケール』には、最小値が存在している様子であり、『0.016』が『0.02』に切り上げられた（上書き）。
入力系のデバイスから小数点以下の数値を受け取れても、その基準値に合わせてから、『スケール』にて調整すべきことが考察できた。
滑らかさを具現化するためには、実装としても他にも方法があるため、おそらく、あくまでも、合成の結果を調整するためのシステムだった（冗長化した）。
2進数、8進数、16進数という段階のように、『レガシー（Legacy）』を感じさせられるが、継承されていた。
この記事が気に入ったらサポートをしてみませんか？