初めに
この記事は中編にあたる。
この記事では、前編の最後に触れたように、筆者がシティーズ上でのオブジェクトの結合方法を模索する様子や、その結果得られた結合に適した手法について考察していく。
前編を見ていない方は、↑のリンクから是非飛んで見て頂きたい。
参考資料として、「Move Itのすゝめ」「Move Itのもっと！易しいすゝめ」などをご覧いただけると、筆者が泣いて喜ぶだろう。
この記事を一言で言い表すならこうだろうか。
「基礎研究を怠ったり、侮ってはならない」
直面した大きな壁・結合手法の模索
シティーズ上でのオブジェクト結合について
JPMSはモジュールアセットである以上、モジュールをシティーズ上で結合させ、1つにまとめる必要がある。
どのように結合させるのか。
つまるところ、モジュールを全て同じ座標に置くことで結合させられる。
モジュールをすべて同じ場所に置く手法は数多くあるので、順を追って紹介していく。
特にJPMSの結合におススメの手法は3つある。
- 6. スナップ→座標指定による結合（手法4.5.も合わせてみてね）
- 7. 拡大縮小による結合
- 8. スナップによる結合（改）（手法5.も合わせてみてね）
それぞれの良し悪しを判断して、どれか1つだけ覚えて頂ければと思う。
適宜目次から飛んで見て頂きたい。
手法その1、配置した段階で結合
モジュールをすべて同じ場所に置くことだけを考えれば、手法は極めてシンプルだ。
適宜MODを使い、建物の設置判定を無視して、同じ場所にすべてのモジュールを配置すればいい。
確かにこの手法ならば、最速でモジュールを結合させることができる。
しかしこの手法には致命的な弱点がある。
まず、セルにスナップさせることができるアセットは建物のみで、プロップやPOはセルに合わせて配置できない。
これはJPMSの肝である、POに変換されたplateモジュールを、建物モジュールと同じ場所に配置することが難しいことを意味している。
では、すべてのモジュールを建物として設計し、同じ場所に配置した後、plateモジュールやAddSignモジュールなどのPO化したい部分のみをMove Itを使ってPOにすればいいのではないか。
これならば、全てのモジュールの位置は同じ場所になり、結合するはずだ。
これを使えば確かに結合させることができるらしいが、残念ながら、筆者の望む挙動が難しかった。
何故かと言えば、MOD「Move It」と「Procedural Objects」のみならず、シティーズの仕様上どうしても生じてしまう問題があるためだ。
シティーズの仕様上、オブジェクトを選択する際、同一座標にある複数のオブジェクトを分別して選択することができない。
これは「Prop Painter」「Procedural Objects」「Repaint」により各モジュールに編集をする際に、選択したいそれを選べないことを意味する。
同一座標にある複数のオブジェクトの中から、望んだオブジェクトをPO化することは難しく、同様にモジュールの色の変更、表示面の変更なども難しい仕様となっているのだ。
このように、直接結合する手法は、結合後の操作に支障をきたすため、早々に却下された。
一旦別々、後から集める
上記のように、直接結合する手法は、オブジェクト選択の仕様を理由に却下された。
よって、手法の大まかな流れを以下のように決定した。
- 各モジュールをマップ上に一旦置く。
- 各モジュールに必要な変更を施す。
- 各モジュールを移動させ、同じ場所に集める。
一旦モジュールをマップ上に配置し、PO化など必要な変更を済ませてから結合させる手続きを考えた。
以上から結合は、シティーズ上で物体を動かすことを意味するが、このような機能はバニラにはない。
無論、筆者御用達、Move Itの出番である。
手法その2、目測で結合
Move Itを使ってモジュールを移動させることを純粋に目指すのであれば、目測でモジュールを結合させることも選択肢になるだろう。
単一のアセットからモジュールとしてポール看板の開発を方向転換した当時、筆者は、Move Itを使ってユーザーにモジュールを目測で結合してもらうことを考えていた。
しかし実際試してみると、目測で結合させることが想像以上に難しいことに気付かされる。
そもそも、モジュールが大きく表示できるのはカメラMODのおかげであって。
そもそも、Move Itを使ってここまで細かく移動させられるのは完全に知識と技能であって。
MODの知識やMODの技能によってアセットの精度が変わってしまうなど、アセットを作る側として極めて不親切だ。
「これではJPMSが誰でも簡単に使えるアセットにならない。」
そう嘆く筆者は、PO化のジレンマ（詳細は前編へ）以上の大きな壁に再びぶち当たることになった。
筆者の長考が始まった。
手法その3、マージンを持たせた結合
初めは目測での結合が多少失敗してもいいように、ズレを加味した余裕、つまりマージンをモジュールに持たせて設計することにした。
しかし、看板の表示面と枠の部分を分離しなければならない都合、マージンを持たせすぎると枠が太くなり、看板全体が不恰好になる。
そのため、マージンは20センチ持たせるのが限界だった。
ところが、Move Itの方向キーによる詳細な移動（方向キー+alt）による移動幅は12.5cm(1/8m)である。
Move Itが用意する詳細な移動で生じる微細なずれでも、JPMSには致命的であることが分かった。
またこの手法は、根本的にマージンを持たせたとはいえ、最終的にはユーザーに目測で看板を組み合わせてもらうことに何ら変わっていない。
マージンが持たせられず、操作がシビアすぎることから、この手法は断念した。
手法その4、座標指定による結合
次に、座標指定する手法を思い出したので、これが使えるかどうか考えた。
モジュールを全て同じ座標に置けば結合させられる、ということを愚直に考えると、これが “一番正しい手法” だろう。
手順は以下の通りだ。
- 結合させたい物体の1つを選択し、座標を控える。
- 座標を控えた物体以外を1つ選択し、控えた座標を入力し、「実行」を押す。
- 2つが結合する。すべてのモジュールが結合するまで、2,3を繰り返す。
- 結合が完了する。
まず、移動させたい場所の座標をメモする。
全く見当つかない場所に移動させてしまわないように、例えばワールド原点（X＝0,Y=0）や、1つのモジュールのオブジェクト座標を、1つだけメモしておくといい。
そして、合体させたいモジュールの原点座標を、メモに控えておいた座標に書き換えて実行を押すことで、同一の点に移動させることができる。
座標指定移動のメリット
- 操作が既存の方法であること。
- 結合する物体の数、種類が少ない程早い。
- 手順を踏めば、複数のオブジェクトをズレなく配置できる。
- 以後紹介する結合手法と比較して、説明が簡単。
座標指定移動のデメリット
- 1つずつ結合するため、オブジェクトが極めて多い場合には適さないこと。
- 以後紹介する結合手法と比較して、最も手数が多い。
そして、モジュールの数だけ実行作業を繰り返すことで、1つに結合させることができる。
もちろん目測で合わせに行く時とは違い、モジュールがずれることもなければ、操作が一定な為に毎モジュールの移動に要する労力や時間は定量的になる。
一旦配置してから後から結合する為、セルを参照して直接結合させる際にはできなかった、各モジュールの編集もできる。
一見素晴らしい機能に見えるだろう。
そして、座標指定移動が素晴らしいように見せかけて、前編でも堂々と紹介した。
しかし、これはあまり賢い手法ではない。
この手法には2つの大きなデメリットがある。
1つは、モジュールが1つずつしか移動できないことだ。
オブジェクト座標が異なる複数のオブジェクトを選択した場合、それらオブジェクトの中心を基準に移動してしまい、同じ地点に集まらず、つまり結合できない。
そのため、モジュールの数が多ければ多い程、結合処理の面倒くささも比例して増えてゆく。
そしてもう1つ、そもそも座標を控えて書き換えるのが面倒だ。
マップ上に適当に置いたオブジェクトなど、有効数字小数点4ケタで表示されているので見ているだけで憂鬱になってくる。
この対策としては、コピペをしたり、予めワールド原点を控えたりするなど、適宜対応してほしい。
「選択したオブジェクトの座標をコピーする」ような機能が実装されない限り、この機能を使った結合は手間がかかる、という他ないだろう。
手法その5、スナップによる結合
そして、Move Itのスナップ移動を使った結合を考えた。
実はこのスナップ移動の研究こそが本記事の主題であり、JPMSが完成した今なお研究を続けている。（手法その8、スナップによる結合（改）に後述）
スナップは図示をクリックするか、物体をマウスでドラックして移動させる際にAltキーをホールドすることで使用できる。
青く光っているときはスナップがオンになっている。
手順は以下の通りだ。
- 結合させたい物体の1つを選択し、スナップ移動する。
- 同じスナップ地点に物体を1つずつ動かし、結合させる。
- 結合が完了する。
スナップのメリット
- 操作が既存の方法であること。
- 最も単純で、手早く、説明がしやすい手法。
- 結合する物体の数、種類が少ない程早い。
- 一つ一つオブジェクトを結合するため、設定の修正が容易。
- （正しい手順を踏めば）複数の物体をズレなく配置できる。
スナップのデメリット
- 1つずつ結合するため、オブジェクトが極めて多い場合には適さないこと。
- 建物とそれ以外ではスナップの定義が異なるため、これを跨いだ物体の結合にはスナップ機能以外の結合手法を要すること。
- ネットワークが密な場所では、適切なスナップができないこと。
触れこみは「最も単純で、手早く、説明がしやすい手法」だ。
ここで1つ、皆様に謝っておかなければならないことがある。
実は、座標指定移動よりもスナップ移動の方が手続きが簡単なのだ。
ところがそれに反して、前編記事の終わりに「中でも最も説明がしやすい」結合手法として座標指定移動を簡単に紹介したことは、手法その4でも述べた通りだ。
なぜ前編では、座標指定移動を紹介し、スナップ移動を紹介しなかったのか。
それはズバリ、“この手法だけでは”JPMSを結合させられないからである。
一体どういうことなのか。
それはズバリ、”JPMSのすゝめ（前編）を公開した時点において” スナップ機能単体ではJPMSの結合ができないものと考えられていたからである。
結論から言えば、建物オブジェクトはそれ以外のオブジェクトとスナップ位置が異なる。
建物は当然ながら、セル（グリッド）にハマるようにスナップする。
しかし、それ以外の種類のオブジェクトは、セルの角にスナップする仕様となっている。
この仕様により、セルが奇数×奇数、奇数×偶数、偶数×奇数の場合、Frameモジュールとそれ以外のモジュールは、全く見当違いの場所にスナップされ、スナップ移動ではそれ以上近づけられなくなる。
では、偶数×偶数の建物の場合はどうだろうか。
例えば建物モジュールのセルが2×2であれば、道路のセルの角がちょうど建物モジュールの中心と同じ場所になり、建物以外のモジュールと同じ座標にスナップできるのではないか？
…ということを想像した上で、スナップ機能が使えるよう、筆者はJPMS poleへの実装で、edge,frameモジュールは2×2セルで設計し、組み立て済みのchemiに関しては1×1,2×2セルの2つを準備し、公開した。
筆者は、完璧なプランだと自画自賛タイムに入り、悦に浸っていた。
ところがである。
建物とその他のオブジェクトが僅かに、何故かズレている。
それも建物モジュールの前後方向にだけズレている。
筆者は発狂した。
その後、原因究明に向け研究を重ねたが、原点座標がズレている理由ではないことと、偶発的にスナップ位置のズレ幅が変化してしまうことが分かったのみだった。
JPMS公開後、2022年6月26日執筆現在も、このズレの原因は解明できていない。
2022年6月27日、ついにズレの原因を見つけることができた。
これについては、手法その8、スナップ機能その8、スナップ機能（改）について後述する。
長い長い研究の結果、建物と建物以外のスナップ移動による結合は難しいという結論を得た。
しかし、この研究は決して無駄ではなかった。
建物であれば建物同士、建物以外であれば建物以外同士は、スナップ移動を用いることで、座標指定移動よりも素早く結合できることが分かった。
手法その6、スナップ→座標指定による結合
では、手法4と5を合体して考えてみよう。
手順は以下の通りだ。
- 結合させたい物体の内、建物以外のオブジェクト1つを選択し、スナップ移動する。
- 同じスナップ地点に建物以外のオブジェクトを1つずつ動かし、それらすべてが結合するまでスナップ移動を繰り返す。
- 建物のオブジェクトが複数ある場合には、建物以外のオブジェクト同様、スナップ移動によりそれらすべてを結合させる。
- 結合した建物以外（建物）を「座標を指定」機能を使い、これらの座標を控える。
- 建物（建物以外）をすべて選択し、控えた座標を指定して移動させる。
- 結合が完了する。
これが筆者の考える、優れた解の1つである。
スナップ→座標指定のメリット
- 操作が既存の方法であること。
- 結合する物体の数、種類が少ない程早い。
- 一つ一つオブジェクトを結合するため、設定の修正が容易。
- （正しい手順を踏めば）複数の物体をズレなく配置できる。
- 座標指定機能のみ使用する場合と比較して、結合する物体の数が多くても早い。
スナップ→座標指定のデメリット
- 多数の物体の結合であるとき、6,7,8の手法の内では、効率は悪い。
- 2つの技術を横断した手法のため、説明が難しいこと。
- ネットワークが密な場所では、適切なスナップができないこと。
手数が多く、説明が面倒なこと以外は、非常に素晴らしい手法だと筆者は思う。
手早く、簡単に、寸分の狂いなく移動させられる手法だ。
スナップ機能を使い、複数のオブジェクトを同じ座標に予めまとめておくことで、これらを座標指定移動する際に一度に結合させられる。
もっとも、モジュールが建物以外のみの場合、最も簡単な結合手法はスナップ移動だと断言できる。
この手法は、建物との結合を必要とするJPMSにとって致命的な弱点を克服する手法として存在する。
さらなる手法の発見
このような経緯で、JPMSを完璧に結合させられる手法を発見した。
そのため、手法の模索はここで終わっていいものだった。
……終わっていいものだったのだが。
出会いは突然だった。
JPMSを一旦完成させた（と思い込んでいた）筆者は前編の記事を書くことにした。
その際に、Procedural ObjectsやMove It、筆者の紹介をする手前、「Move Itのすゝめ」「Procedural Objectsのすゝめ」といった過去のコラムの内容などを、確認のため一通り読み返すことになった。
確かに文章こそまだ拙いものだったかもしれない。
今になって見返してみれば恥ずかしい箇所も多かった。
けれども、このコラムを書いた意味は確かにあったのだ。
筆者は、モジュールを一切のズレなく配置することができる手法を「思い出した」。
灯台下暗し、とはこのことか。
過去の自分が結合の手法を教えてくれたのである。
少し筆者の思い出話をしよう。
これは自慢だが、筆者は2020年、CSLビルダーズコンテスト様に寄稿したコラムで既にこの機能の一側面について言及していた。
「複数の物体の中心の間隔を計り、その距離を変更する機能」。
それすなわち、複数の物体を選択し、結合ができることを意味していた。
しかし、JPMSの基幹技術であるテクスチャマネジメント機能は当時登場したばかりで、筆者は認知すらしていなかった。
そして当時筆者はアセット制作未経験で、結合によるメリットを見出す知見はもちろんなかった。
そのため、当時の筆者は「この機能、ホントにいるの？」と思いながら、どうやって活用すればいいのか、解説文を必死で考えたことを今も覚えている。
苦肉の策として、正方形に敷設した道路のセグメントを選択して、スタック型ジャンクション作れるのでは？などと提唱したが、今考えれば、有用性はあまりにも欠けていた。
当時有用性を感じなかったからこそ、筆者がその後、この機能を忘れてしまうことになったのだろう。
……今となっては、これほどまでに素晴らしい機能もなかなか無い訳だが。
手法その7、拡大縮小による結合
Twitterで投稿した手法。（動画42秒～）
手順は以下の通り。
- 全部選ぶ。
- 内側に拡大縮小を100回押す。
- 結合が完了する。
拡大縮小のメリット
- 動作がカッコいい。←男の人ってこういうの好きでしょ？
- 結合するものが多ければ多い程、効率的で早い。
- どんなオブジェクトでも結合できる。
- 結合する物体の数、種類がいくらであっても操作が単一。
結合させる物体が数十個以上ある場合には、理論上最速で結合できる。
拡大縮小のデメリット
- 数個の物体の結合であるとき、6,7,8の手法の内、最も効率が悪い。
- 結合前に全ての物体へ設定を反映させておく必要があること。
- キーコンフィグを新規で登録する必要がある。
これが筆者の考える、優れた解の1つである。
この手法の明確なデメリットは、デフォルトではキーコンフィグが登録されていないことだ。
キーコンフィグの登録については、オプション画面のMOD設定から登録していただくことになる。
筆者は、拡大縮小機能にテンキー+/-を割り当てている。
好きなキーを割り当てればいいだろうが、機能の性質上、対になるキーであるといいだろう。
この機能がそもそも見当たらないことは、試してみようという気をなくすことになる。
あるいは、筆者のように機能そのものを忘れがちになってしまうかもしれない。
拡大縮小機能を他に使う場面が少ないという意味でも、機能そのものの課題が目立つ手法だろう。
この手法のメリットは、慣れてしまえば非常に素晴らしい機能・手法であることだ。
上記の手順が非常に簡素なことがわかるかと思うが、手順が非常にシンプルだ。
全てのオブジェクトを選択し、内側に拡大縮小をちょうど100回押すと、すべてが結合する。
ちなみに、内側に拡大縮小を実際に100回押す必要はない。
Altキーをホールドすると、高さ移動（PgUp/PgDn）や方向キーによる移動距離が通常の1/8になる機能は、ご存知の方も多いことだろう。
では、Shiftキーをホールドすることで、逆に高さ移動（PgUp/PgDn）や方向キーによる移動距離が通常の8倍になる機能はご存知だろうか。
実はこの関係が、内側に拡大縮小・外側に拡大縮小にも同様に使うことができる。
つまり、内側に拡大縮小を4回押した後、Shiftキーをホールドして内側に拡大縮小を12回押すことで、内側に拡大縮小を100回押したときと同じ動作ができる。(4+12*8=100)
あくまで例え話として、結合させたいオブジェクトの数が仮に1億個だった場合、6,8の手法では、それぞれ座標指定・スナップ機能を使った移動をぴったり1億回行わなければならない。
ところが拡大縮小機能なら、内側に拡大縮小を実質100回、つまり16回押すだけで済むのだ。
どちらがより便利であるかは明白だろう。
しかしこれは、結合させたいオブジェクトが例え2個だったとしても、内側に拡大縮小を実質100回押さねばならない。
このように、逆に効率が悪くなってしまう場合もある。
また、全て選択してから一気に結合させるため、結合させる前に、オブジェクトにする各種設定を予め終わらせなければならない。
メリットもデメリットも個性が強い結合手法である。
これはあくまで余談だが、この機能、操作がかっこよさげじゃないか？（かっこいいと言え）
全て選択してまとめて結合することに、もはや爽快感すら筆者は感じてしまう。
他の手法と比較すると、最もロマンがあると筆者は考える。
手法その8、スナップによる結合（改）
筆者の考える、優れた解の1つである。
手順は以下の通りだ。
- 同じスナップ地点に物体を1つずつ動かし、結合させる。
- 各種物体の向きを整える。
- 結合が完了する。
スナップ（改）のメリット
- 操作が既存の方法であること。
- 最も単純で、手早く、説明がしやすい手法。
- 結合する物体の数、種類が少ない程早い。
- 建物とそれ以外ではスナップの定義が異なるため、
これを跨いだ物体の結合にはスナップ機能以外の結合手法を要すること。予め建物や建物以外のオブジェクトにマージンやオフセットを設けることで、スナップ移動のみで移動が完結すること。
スナップ（改）のデメリット
- 1つずつ結合するため、モジュールが極めて多い場合には適さないこと。
- ネットワークが密な場所では、適切なスナップができないこと。
- 6,7,8の手法で唯一、建物と建物以外のオブジェクトを同じ座標に移動できない場合がある。
スナップ機能については、「手法その5、スナップによる結合」の項を改めて（遡って）見て頂きたい。
この項の最後で、建物のセル（グリッド）を偶数×偶数にすることで建物以外のオブジェクトとスナップ位置が同じになるのではないか、そう仮説を立てて実行し、無事筆者は発狂した。
ここで状況をまとめておく。
建物を偶数×偶数セルにする発見をした段階で、1辺に奇数セルを含む建物のような見当違いの場所にスナップされることは無くなり、かなり近しい場所にはスナップできるようになっていた。
50センチ単位の大きなズレを数センチ以内に縮めることができた。
そして、筆者はこのズレ幅が4センチであることを突き止め、予め4センチ中心をずらしたアセットを用意した。
すると練習環境では、plateモジュールがEdgeモジュールにぴったりとハマり、ついにスナップ機能を使って “見かけ上は” モジュールの結合に成功した。
しかし、この研究をもとにアセットを制作し、既に公開したJPMS poleの更新に向け準備していた最中のこと。
最終確認として本番環境で試してみたところ、不具合が起きる。
時と場合によって、建物と建物以外のオブジェクトのズレ幅がまちまちらしい結果が得られたのだ。
ほぼズレが生じない場合もあれば、見当違いの場所、それも、奇数セルを持つ建物モジュールだったころ以上の誤差が生じてしまうこともあった。
これはなぜなのかと、スナップ機能の検証に多くの時間を費やした。
そして初歩的な原因が発覚した。
画像は、2×2セルの建物を10度ずつ回転させ、10度隣の建物と最も近い場所にスナップさせた際のスナップ機能の挙動を調べたものだ。
スナップ位置が円形にズレることがお分かりいただけるだろうか。
長きにわたった検証の結果、建物の向きが道路に垂直または平行でない場合、建物のスナップ位置は、建物が道路と接続する辺の中心点を基準に、円形にズレることが分かった。
ここで「手法その5、スナップによる結合」の項の画像を再掲する。
この画像で示したスナップ位置は、実は建物の向きが道路に垂直、あるいは平行だった時の場合に限られていることが新たに分かった。
つまり、スナップ機能を使い、建物と建物以外のオブジェクトを最も近い位置にスナップさせるためには、建物の向きが道路に垂直か平行でなければならないのである。
前段階で「4センチ」という具体的な誤差が生じたかは不明だが、ある程度推測は付く。
建物の向きが道路に垂直でない場合、垂直からおよそ0.4度向きがズレた場合にズレが4センチ生じることが分かっている。
おそらく検証の途中で、目測で垂直を確認し、これを垂直として扱ったのではないだろうか。
練習環境では問題が発生しなかったのに、本番環境では何故かズレたことも、推測と合致する。
設置する際の目測での角度が練習環境からさらにコンマ何度かズレたからだろう。
かくして7月5日、JPMS_poleのアップデートを実施した。
建物モジュールを道路に面して設置するよう、仕様を変更した。
というようなクソ長い経緯をもって確立されたのが、スナップ結合（改）である。
結合手順の覚えやすさ、結合の手早さが他の手法に比べてぶっちぎりでいいことは変わらず。
それでいて、建物と建物以外のオブジェクトを跨いだ結合が条件付きで可能だと確認できた。
また検証途中だが、ズレは全くないか、許容できる程度の誤差しかない。
（ズレの要因がスナップ機能にない可能性を視野に、結論は差し控えさせていただく）
そのため、この手法の大きなデメリットは、もはやこれしか残されていない。
「6,7,8の手法で唯一、建物と建物以外のオブジェクトを同じ座標に移動できない場合がある。」
スナップ機能（改）の項で述べた通り、スナップ機能のみによって結合できるのは、基本的に結合させたいオブジェクトが建物でない時だ。
その例外として、結合させたい建物が偶数×偶数セルである場合は条件付きで可能となっている。
筆者が実施したアップデートにより、JPMSでもスナップ機能が使えるようになったが、その他の建物でも同様に、スナップ機能のみで複数のオブジェクトが結合できるとは限らない、と把握してほしい。
2つのデメリットに総じて言えることは、JPMS poleではスナップ機能のみを使った結合への対策ができているものの、その他の建物と建物以外の結合で使えない可能性があることだ。
スナップ機能は万能ではない、これだけ覚えていただければいいだろう。
いっちゃん楽でいっちゃん覚えやすい機能なので、まぁ、この手法でいいと思うよ。筆者は。
手法その9、スナップ→矢印キーによる結合
現在研究中です。
おススメの結合手法の比較
- 6. スナップ→座標指定による結合
- 7. 拡大縮小による結合
- 8. スナップによる結合（改）
以上3つの手法について、まとめとして比較しておく。
結合手法まとめ
簡便さ
正確さ
N個の物体の
結合にかかる時間(N≧2,a>2,b>2)
速度について
JPMSに
JPMS以外に
機能説明の難しさ
おすすめの運用方法
スナップ機能
一番簡単
現在調査中
(遅くとも)(N-1)秒
b>N≧2で最も早い。
実際にはほとんどN<bのため、
実用上で最も早い。
使える
使えない場合がある
比較的簡単
基本的にこれを使って結合するといい。スナップできない場合でも、その他手法と併用して解決するといいだろう。
座標指定機能
そこそこ面倒
ズレは全くない
(慣れ参考)a(N-1)秒
(a=10秒程度と推定)
a(N-1)<bでない場合は常に最も遅い。
使える
使える
最も簡単
JPMS以外にスナップできない場合に併用する選択肢となる。拡大縮小機能に慣れるまではこれを使おう。
拡大縮小機能
慣れるまで面倒
ズレは全くない
(慣れ参考)b秒
(b=6秒程度と推定)
N>bで最も早い。
理論上、最も時間短縮効率が高い。
使える
使える
最も難しい
スナップ機能と比較して、結合手法の併用がないので、これ一つを覚えればいいメリットがある。あとロマンがある
結合させること、その展望
上記では、主にJPMSの結合を前提に話を繰り広げていった。
ではJPMS以外の、広く全般に結合を行うメリットを上げていこう。
まず初めに、モジュール化が容易になることだ。これは説明不要か。
次はPO化のジレンマを解消できることだ。これも説明した通りだ。
それ以外で2つ、アセットを頒布する際のアセット制作側からのメリットを挙げておこう。
（ここでの「頒布」とは、クラウドにアセットの構成要素を全て公開し、第三者がダウンロードできるようにすることを指す）
1つは、アセットの一部だけを頒布できるようになること、もう1つは、配布する部分のテクスチャマップの構成を極めて簡易にできることが挙げられる。
アセットの一部が頒布できる、というのは、翻せばアセットの一部を頒布せず、残した部分を保護できるという意味だ。
アセットクリエイターが、自分の公開したアセットのリペイント品が作られることを望んでいたとしても、完全なコピー品が作られることを望んではいないだろう。
アセットの一部分のみを頒布し、ユーザーに結合してもらうことで、アセットの多様性とオリジナルの同一性が同時に担保されることを期待する。
もう1つ、配布する部分のテクスチャマップの構成を極めて簡易にできるというのは、”1つの存在”を構成するアセットが複数あることで、テクスチャマップの割り当てを自由に分配できるという意味だ。
アセットの構造が複雑であればあるほど、テクスチャマップも相応に複雑になっていくものだ。
例えオリジナルの作者Aが制作したアセットを頒布したとしても、高度なディフューズマップの変更方法に、コピーする側の理解が及ばない。
そのため、オリジナルの作者はコピーする側やユーザーに向けた、より詳細な解説・マニュアル作成に労力を割かなければならない。
そこで、オリジナルの作者が設計段階でアセットを分割し、コピーする側やユーザーに対して与える側のアセット、あるいはそのテクスチャマップをなるべく簡易にするのはどうだろうか。
書き換える余地のある部分のみを切り離し、融通することで、オリジナルの作者側やコピーする側を含めユーザー全員がより直感的にリペイント・テクスチャマネジメントができる環境を期待する。
懸念はアセット配置数が倍量以上に多くなってしまう点が挙げられるが、Prop Anarchyによって、プロップの配置数制限を突破できるようになったことで解消できるかもしれない。
このような背景は、モジュール化推進への追い風と言えるだろう。
3D編集ソフトが使えなくとも、画像編集ソフトは使えるアセット制作未経験の方。
ボーダーは下げておいた。
JPMSという環境は作っておいたので、是非アセット制作に挑戦してみてはいかがだろう。
右も左もわからないなら、いずれ公開される後編記事を是非読んでいただきたい。
画像編集ソフト「GIMP」を使い、大体全部説明する予定だ。
終わりに
筆者はモデリングが秀でているわけでも、テクスチャリングが秀でているわけでもない。
現状はずぶの素人である。
ただ、物の変化につぶさに気付いて、暇を見つけてはそれを探求することが好きなだけだ。
アセットクリエイターとしての自覚がおありの方。
是非この技術を使って、あなたのアセットに活かしてほしい。
そして改めて、JPMSをどうぞよろしく頼む。
後編に続く。
【あとがき】
結局恥ずかしいから誰も見ないような場所に書くのだけれど。
この研究、結構しょうもないところでミスしてたり、研究内容が破綻してたりする。
基礎研究は大事よ。
内容を突き詰めて、精査して、再現性の確認をするの。
そうしてるから、筆者の寄稿したコラムの内容が突然降ってくるようなことがあるのだ。
逆に内容を突き詰めないから、今までの研究が台無しになるのだ。
1つの研究が終わるまで3ヶ月以上もかかってしまうのだ。
ただそれだけのこと。
2022年7月9日 初稿
コメント