// ----- >>* Initialize Division *<< //
// TimeLine:220513
// NOTE:
// ----- >>* Header Division *<< //
TITLE:
ＵＥ５始めました。
Written by ＢｌｕｅＣａｔ
// ----- >>* Body Division *<< //
//[Body]
２２０５１３
UnrealEngine を始める。
かつてはＣＧのモデリングをするのにソフトを買っていた。
当時もフリー／シェアソフトがなかったわけではないが彼我の差は歴然で、相応の使いやすさや能力を求める場合、ホビーユースであっても有料アプリケーションを購入しなければ満足な３Ｄモデルを作ることは困難だった。
幸い、僕が２０代の頃には、かなり廉価のモデリング／レンダリングソフトが存在していて、１万円未満でエントリークラスを購入することができた。
ちなみに１５歳の頃、三角関数も理解していないのにワイヤフレームの３ＤＣＧを描画するプログラムの本を購入し、三角関数の図説や式を無視してプログラムを完成させ、モデリングしていたことがある。
ワイヤフレームなので「頂点と頂点を指定して線を結ぶ」のが基本動作になる。
それぞれの頂点（原則は始点と終点の二点）についてカメラからの相対座標を算出し（傾きやあおりが発生する）、ビューポート（２次元）の投影座標を算出して、その始点と終点に直線を描画するのである。
ＢＡＳＩＣなので、データはプログラム内部に Data 構文で記録するのが標準だったが、ＦＤ ── ああ懐かしののフロッピーディスク（それも５インチだった） ── に直接読み書きするためのサブルーチンを書こうかどうしようかと、悩んでいるうちに興味が別の方向に向かってしまった。
また当時のコンピュータは非力で（僕の持っているマシンは８ｂｉｔだった）ＲＡＭにも限界があった。
（基本が６４０ｋｂで、コマンドにより拡張して１２８０ｋｂだったか。忘れてしまった）
そもそも１６ｂｉｔマシンだって相当に非力だったし、５０ＭＢだか１００ＭＢのＨＤＤというものがようやくリリースされた、なんて話題になったくらいで、そのＨＤＤが実に１００万円近くして（ムリィ……）と絶望する学生時代だった。
ためにたかだか１００×１００×１０程度の３次元配列変数領域を確保しようとしてもＢＡＳＩＣでは適わず、機械語とのハイブリッドで（あるいは機械語オンリーで）メモリ領域を使うしかなかった。
僕は機械語が苦手だったので、ＢＡＳＩＣでグラフィックビューポートを配列変数代わりに利用し、その上からテキストを上書きすることでユーザビューポートからはマスクする手法を考えた。
８ｂｉｔの基本描画は８色（拡張しても２５６色だったか）なので、コンピュータ三原色のそれぞれをひとつのビットとして扱ったり、あるいは０〜７までのレジスタを持つ配列変数として利用しようと思ったのだ。
（ちなみに致命的な処理速度の問題が発生し、この手法は封印された）
＜＜＜
【Grossary】
※謎の単語が多すぎて、多分説明する意味は ── 理解しようとする読者もいないと思うので ── ないと思うが。
○ ワイヤフレーム。
頂点（バーテクス）と辺（エッジ）のみで、基本的には隠線処理（見えない領域のエッジなどを非表示にすること）もなく演算描画される３ＤＣＧの形態。
○ ＢＡＳＩＣ
まぁ、そういうコンピュータ言語がかつてあってだな……。え、今もあるの？
○ ビューポート
当時のＢＡＳＩＣ搭載の国産ＰＣの多くは、ディスプレイに対しアスキー文字列を表示するための「テキストビューポート」と、ドット単位でグラフィックを表示するための「グラフィックビューポート」をメモリ上に仮想領域として用意しており、実際の描画についてはテキストが上位層に表示される仕様だった。
これは文字をグラフィックとして扱うと、ＣＰＵの負荷が高くなり、メモリも大幅に消費するため、基本的にはテキストベースでプログラムを組むことが望ましかったのだ。
テキストそのものは（全角文字を使わない限り）ドットが多少荒くても判別可能だし、ＲＯＭに書き込んでおけばメモリ領域やＣＰＵを（つまりはコンピュータのポテンシャルリソースを）さほど消費しなかったのだろう。
ちなみに当時、僕の使っている環境では、テキストビューポートが８０×２５の領域だったのに対し、グラフィックビューポートは６８０×４８０だった。
制御の範囲が異なる分がシステム負荷になるため、編み出された手法だと思われる。
ちなみに現在のコンピュータにはそうした「テキスト専用グラフィックメモリ領域」というのは存在しない。
サイズどころかフォント種類までかなり自由に変更できるようになったのは、テキストを画像として扱うようになったから、である。
○ ビューポートマスク
グラフィックを書いた上から黒豆腐テキスト（■←これ）を表示させれば、必ず「アスキー文字テキストがグラフィックの上に表示される」という仕様上、下にあるグラフィックを隠す（マスクする）ことが可能だった。
○ 配列変数
当時その気になれば１０次元以上の配列変数を確保することも可能だったが、１０万の変数領域すら確保できないのだから使い道は限られていた。
＜＜＜
未だに高機能で高額なソフトは存在しているが、時代の趨勢か、サブスクリプションの形態を取るものが多い。
僕のように「３ヶ月くらいはほとんど何もしないけれど、盛り上がったときは１週間くらい寝食を忘れて使うことがある」という人間にとっては非常に無駄なシステムである。
だからサブスクリプション形式のアプリケーションは（ＡＴＯＫを例外として）使わないことにしている。
それに今は、フリーソフトもそれなりに高機能になってきた。
モデリングとレンダリングだけならＢｌｅｎｄｅｒで事足りそうなのだが、どうせだから統合開発環境であるところの UnrealEngine を試してみよう、基本無料だし、という軽いノリで使ってみることにした。
もちろん、インストールしたところでさっぱりワケが分からないのだが、英語でしか詳細なテキストナレッジが存在していないＢｌｅｎｄｅｒでは、言語の壁で行き詰まるだろうと思ったのである。ただでさえ専門用語が多いのだからなおさらに。
UnrealEngine はアプリケーションとして考えれば巨大だが、統合開発環境と考えればそれは無視してかまわない問題だ。
日本語の情報も豊富で、開発元（Epic Games）が情報をリリースしているから間違いがないし、ユーザは世界にごまんといるし、無料リソースも膨大で、アップデートも細かくされている。
なにせ企業がゲーム開発に使っているものと同じなのだから当然だろう。
にもかかわらず、収益を生まないならば無料で使える ── 1Mil.US$以上の粗利になったら５％のロイヤリティを支払う義務が発生する ── のなら、それを使わない手はない。たとえその独学の道が険しかろうと。
＞＞＞
以前はＭＯＤＯというソフトを使っていたのだが、かなり高額なサブスクリプションソフトになっていたので諦めた。
（モデリングが非常に柔軟であり、レンダリングも自然で美しかったため、少々残念ではあるが）
今、有償ソフトを買うなら、Forum8 の Shade3D に返り咲く感じだろうか。
サブスクリプション形式だけれどエントリークラスはホビーユースにも優しい価格だし、日本のメーカが開発しているソフトである。なによりゲームと同様、良いものを作るメーカにお金を払うことは ── 中古コンテンツにお金を払うこととは異なり ── その業界を維持することそのものになるからだ。
なんでもタダがいい、安ければいいなんて、僕は思わない。
釣った魚に餌をやらないどころか、釣る魚に餌を付けないような連中が多いのは考えものだ。
餌をあげなかった魚は死ぬのだから、餌をあげない自慢は、餌をあげる自慢 ── 「高い餌を買いました！」というコンテンツが、ときどきＷｅｂ有名人（たとえば Youtuber）によって作られている（そしてそれなりに人気がある）ようだが、本当に下品だと思う ── よりさらに下品である。
（余談だが、中古コンテンツのブローカやユーザ間売買が、サブスクリプション形式を浸透させる土台になっている側面は少なからずあるだろう。これらは本来、マーケットにおける「人間を信頼する」という善良な前提が衰退しつつあることを示す、忌むべきありようだ）
とはいえとりあえず、UnrealEngine である。
1,000,000 US$ を越える粗利を生んで、EpicGames に５％のロイヤリティを払おう！（前提条件が僕には不可能だが）
// ----- >>* Junction Division *<< //
［ＮＥＸＵＳ］
～ Junction Box ～
[ Traffics ]
// ----- >>* Tag Division *<< //
[Engineer]
：工場長：青猫α：青猫β：黒猫：
[InterMethod]
-Algorithm-Diary-Ecology-Love-Mechanics-Memory-Technology-
[Module]
-Condencer-Connector-Convertor-Generator-Transistor-
[Object]
-Computer-Koban-Memory-Tool-
// ----- >>* Categorize Division *<< //
[Cat-Ego-Lies]
：工場長の設計室：ひとになったゆめをみる：
//EOF
