2019年06月29日

松山空港: シーナリー進捗状況17

こんにちは。

今回は、3月に制作が完了したグランドポリゴンについてのお話です。
こんな感じなんです。
rjom16_b.jpg


rjom16_a.jpg


グランドポリゴンに関しては、ひそかに問題が多く潜んでいます。どういった点で問題があるのか、それは互換性です。
私はFSX専用のシーナリー作成を進めています。従ってPrepar3D系列には互換性を意図的に持たせるつもりはありません。しかしながら私が主に使用しているシミュレータはPrepar3d v4。私的に、Prepar3D用に変換をしなければなりません。しかしながら私のサイトで配布しているもののすべてが、著作権およびサポートの都合上、無断で改変することを禁止しています。

これらの制約がありますので、意地悪してFSX以外のFSX系列のシミュレータに互換性をあえて持たせないようにする必要もないと思うんです。(なにせ縮小傾向にあるFSXのコミュニティを盛り上げるために、松山のシーナリーを制作しているわけですし。ちなみにFSX系列以外のシミュレータには流用できないようにしようと考えてます。すいませんw)

しかしながら、最近のP3Dは、FSXからどんどん離れていく傾向にあります。これはプレイヤー側が感じることはほとんどないと思いますが、今回、開発者側になってかなり強く感じるようになりました。まあ普通に考えてみれば、PBRや影なんかのグラフィック面や64bit化などのソフトウェアの面でも、FSXよりPrepar3Dのほうが圧倒的に良いわけですし、技術的にも新しいです。そうなるとやはり、いつまでも古い技術を使っているわけにはいかないという流れだと思います。
この流れは止めることはできないと思います。仕方のないことですから。いつかは、という感じはします。このままではLMにとっても、開発者側にとっても、そしてプレイヤーにとっても不利益になってしまいます。どこかでFSXを切り捨てなければならないときがきっと来るはずです。

よってPrepar3DのSDKを使うとうまくいくのに、FSXのSDKを使うとうまくいかないということが多々あります。さらに、Prepar3DのSDKを使って制作された成果物は、EULA上、再配布できないという規定になっていたはずです。またPrepar3DのSDK(特にv4.4のもの)を使うと、FSXでは使えなくなります。

Ground Polyについての手法には以下のようなやり方があります。さてどんな問題があるか、それぞれ見てみます。

@Model Converter X の Ground Poly Wizardを使用する (FSXでエクスポート)
一般的なグランドポリゴンの制作方法です。Arnoさんが開発された素晴らしいソフトです。私はこれなしでは制作できません(笑)
FSXのBGLコンパイラを使用しますので、FSXでは全く問題なく動作します。(ポリゴンをオーバーレイした誘導路・滑走路のすべての照明は消えてしまいますので再配置が必要です。)
問題はPrepar3Dです。まずレイヤーを16より上にしないと機体の影が表示されません。かといって32以上になるとまた変えたりとまあ困った困った(笑)

さらに、これは私固有の問題ですが、Prepar3D v4においてBGLライトの誘導路灯と誘導路縁の灯火が埋もれて見えない状態になります。

rjom16_5.jpg
Spotビューで、地面に張り付いてみると見えるんですけどね。

ほかの方のシーナリーを見るとそんなことにはなっていないようなので、私が何か間違った作業をしているのか、何かを設定し忘れているのか なのですが、まったく答えが見つからない状態です。

そもそもなんですが、ある時期からPrepar3D v4は、Ground Poly Wizard等を使ってレイヤリングしながら配置していく方法を推奨していないんです。MCX内にある"Z Bias"というパラメータを0, -1, -2, ...と並べていく方法が公式のやり方です。
現状では、レイヤリングによるグランドポリゴンにも対応できているとのことですが、いずれかは対応しなくなっていくものと思われます。
では、MCXで"Z Bias"を0, -1, -2, ... にすればと考えましたが、FSXのXtoMDLを使用した場合、負の値は保存されません。
Prepar3D v4(.4)用のXtoMDLを使用し、Prepar3D v4のBGLコンパイラを使用する必要があります。これでは上記制約に違反してしまいます。またFSXを切り捨ててしまっている状態にもなってしまうのです。

とりあえずBGLライトの埋もれを防ぐような設定も探し当てました。はじめてのシーナリー作成ということで、この設定を見つけるのに何週間かかかりました^^; 本当に泣きそうでした(笑)

まずグランドポリゴンに問題があるのか、BGLライトに問題があるのかを切り分けるのに一週間、グランドポリゴンに焦点を当てて二週間、そしてBGLライトの調整を再考したところなんとかうまくやることができました。
マニアックなので記事にはする予定はないのですが、ご希望があれば、調査メモを元に記事にしますね。


APrepar3D v4.4のBGLコンパイラを使用する
当然のごとく、MCXのGround Poly Wizardを使用したとしても、BGLライト(誘導路などの照明)が戻ってきます。しかしながらFSXには使えません(やってみたら起動時にそこそこのエラーが吐かれる上、GPも表示されませんでした笑)
Prepar3D v4系のBGLコンパイラを使用するなら、一層のこと新基準のZ Biasを負にとっていく方法でやるほうが長い目で見てもよさそうな感じがします。
またこの場合、Development release版のMCXを使う必要があります。ちなみに現在(2019/4/13)では、Ground Poly WizardでGroup Polygon(500mなど)にすると私の場合、謎のタイルが大量に出現し、ちらつきます。そうなった場合は、Group PolygonをDisableにしましょう。Stable版ではそのようなことにならないので、FSX用にはそちらでコンパイルしています。まあ、Stable版でもOptionでコンパイラやらXtoMDLのパスをP3Dv4のものにすり替えてしまえばいいだけの話なんですけどね。
MCXはStable版とDevelopment Release版を、目的によって使い分けることが多々あります。

追記:もしかするとP3Dv4.4のGP Wizardを使用すると、こちらもこの後説明するC同様に、影が出なくなるかもしれません。(いま念のためもう一度確認してみたら影が出ませんでした。出ていると勝手に勘違いしていたかもしれません。なのでP3Dv4で何も問題ないわけではありません。もちろん対処法はCに記載の方法でOKです。)したがってPrepar3D v4では地面、すなわちグランドポリゴンという概念はなくなり、SimObjectとしてグランドポリゴンも扱い始めているのではと考えています。Z Biasを負にとる(公式の方法)でやるとどうなるか確認したところです。だからBGLライトが埋まって見えないわけです...


Bテクノブレイン方式のグランドポリゴン作成に従う
これは以前、空港の灯火の話 で次回お話するということで終わっていたやつです。TBの作品を見てもらえればわかるのですが、各空港とも、グランドの上に少し透明の面が入っているのがお分かりになると思います。TB作品は基本的に、まずADE等を使って"デフォルトの地面"...例えばアスファルトやコンクリートを引きます。それではデフォルトのファシリティデータを弄っただけでとてもリアルとは言えない状況ですので、そこに半透過テクスチャをかぶせているのだと思います。
その空港の灯火の話で、グランドポリゴンの面をかぶせると、FSXでは滑走路照明が消失すると書きました。(P3Dでは消失しないんですけどね)このように、完全な面ではなく、透過テクスチャをかぶせているから、TBのシーナリーは滑走路照明が消えていないのではないでしょうか。ADE等で確認すると、TB製品ではファシリティデータの中に滑走路の照明が残っているんです。

実際に那覇空港(那覇が一番わかりやすいです)に行ってみると、
rjom16_1.jpg
まず地面をよく見ると見覚えのあるデフォルトの地面が下にあるのがわかります。

rjom16_3.jpg
おじさんの足を見れば一目瞭然。足が何かに埋まっています。これがTBがデフォルトの地面の上にかぶせたリアリティをあげるためのレイヤーです。半透過テクスチャで、少し色味を調整したり、模様を変えたり、汚しを入れたり、いろいろな線を描いたりしているのです。TBに聞いたわけではないので100%あっている自身はありませんが(笑)
しかしながらなんでもいいわけでもなく、上の写真のように影が二重に表示されてしまったり、そもそも足が埋まっているのも少しばかり不自然です(大型機からみる分には問題ないと思います。問題は小型機です。)。特に大阪伊丹空港のシーナリーでは、一部分で機体のタキシーライトが地面に反映されなったり、滑走路を高速で離陸するときに、半透過の重ねられたレイヤーが剥がれて、もとの地面が露出することが多々あります。しかし東京羽田や関空では問題なくうまくいっている感じがするので、細かな調整が大事だということです。

この方法は、Grond Poly業界(?)の常連勢ではおそらくもっとも一般的で、安パイな方法とされています。FSXとPrepar3Dの相性がとにかくいいですし。私も次回はこの方法にしようかなと考えています。
似たような方法に、ADEでグランドポリゴンを描くこともできます。これは比較的最近できるようになったことです。詳しくはFlyerのJUNさんのブログを参照してください。ADEではオブジェクトをファシリティデータのBGL内に登録をしてくれたりと、できることが増えつつあり(前からあって気づかなかっただけ?)、ますます便利になっています。


CもはやGround Poly Wizardは使用しない
意外とこれ、当たるんです(笑)そもそのGround Poly Wizardをすると、Prepar3D v4においてBGLで作ったライト(先ほどから要するにエフェクトではないライトといいたいのです)が消えてしまうということが2日ほどの研究でわかりましたので、そもそもGP Wizardを使わずにやろうと考えたのがコレです。
Development Release版のMCXには、Earth Curve Correctionという機能がありますのでこれを利用して、あとは普通にオブジェクト配置をします。Prepar3D 特にv4ですが、GP Wizardを使用しなくても、グランドポリゴンがうまく表示できるようになってきています。

ちらつきやマテリアル競合が少ないんです。(その代償として、逆にGP Wizardを使うほうが、初心者には問題発生の原因になると今回感じました。)

これを利用したものがこの手法です。しかしFSXでは、レイヤリングをしないと一部方向からの視点で、マーキング等が消失し、ある視点にすると戻ってくるという事態が発生します。(P3Dではマーキングの消失は確認されませんでした。)
なおレイヤリングをする場合、Z biasをうまく利用するのですが、この値が0と1や0と3など、レイヤー間の差が十分でないときは一部視点でオブジェクトが消失してしまいます。MCXのGP Wizardを見ていただければわかるように、レイヤリングは4おきの数値を設定します。0, 4, 8, 16,.... のようにです。
さらに0と16のZ biasの差はかなり大きく、浮いているのがはっきりわかります。0と4でも正直ギリです。したがってそもそもレイヤリングを極力少なくできるよう、Sketchupでグループ化しているオブジェクトはできる限り分解しておきます。

rjom16_6.jpg
こんな感じで、Prepar3Dではほぼうまく行っています。

追記:しかし配置の際、0.150mなどかなり高めに配置しない場合、一部分で地面にめり込むことがわかりました。(上の画像では確認できませんが、上の画像のときもめり込んでいる部分がありました。)

0.150m=15cmほどですが、どんなもんかというと、まず旅客機はほとんど問題ありません。問題はジェネアビで、機体がちいさいので、タイヤも小さく、かなりタイヤが埋もれてしまいます。
BGLライトなども0.150mに合わせなければ、不自然になります。
これだと、この手法は100歩譲ってという感じになります。できればこれは避けたいです。

また、Prepar3Dの設定で、SimObjectのShadowをReceiveにいておかないと機体の影がGPに反映されません。要はGP Wizardを使用しなかったばかりに、ただのシーナリーオブジェクトが地面にばらまいてあると思われているんです。(GP Wizardを使用すれば、当該ShadowをReceiveにしていなくても、地面というくくりになるので自機や雲などの影をオンにしている場合は、しっかりと影が映ります。)

rjom16_4.JPG
ここをEnableにする必要があります。なおこのグランドポリゴンのみならず、メインターミナルやそのほかすべてのオブジェクトに、CASTにしている影が反映(Receive)されるためFPSに影響がでる恐れがあります。まあ大体の人が機体の影なんかなくても我慢できる人がほとんどだと思います(笑)

しかしあくまでFSXのSDKを使って出力したBGLのポリゴンですから、制約に違反することはありません。ただFSXと一部環境(ようするにry)でファイルを分けてあります的な感じになってしまいます。

(追記の件があったので、これも没になりましたが、もしBGLライトの設定が見いだせてなかったら、P3Dはこの0.150の高めのグランドポリゴンになっていましたw)


ちなみにFSXとP3Dでは、透過テクスチャを持つオブジェクトは、なぜかGP Wizardを使用すると正しく機能しません。詳しく言うと透過処理が全くうまくいきません。
よって夜間、滑走路に照明を入れたい場合は、GP Wizardを使用せず、このCのやり方に従うのがいいです。
fsx_rjom_ground_picture2.jpg
このライトもGP Wizardは使用していません。テクスチャのSource, Destination Blendが全く機能しなくなります(Source Blend = One, Destination Blend = Zero のみ機能します。)。

それ以外でも、アルファチャンネルは昼間のDiffuse Textureからしかとってこれないということもわかりました。夜間と昼間テクスチャでそれぞれアルファチャンネル変えたとしても、シム上では夜間もアルファチャンネルのみは昼間テクスチャ、すなわちDiffuse Textureのアルファチャンネルを使用してしまいます。

よってBGLライト類では、昼間と夜間でアルファチャンネルも表示させるテクスチャ自体も変えたいことがあるとは思いますが、この場合は、透過処理させる場所を黒にして、MCXやGmax上で Source Blend = One, Destination Blend = Oneにしてアルファチャンネルは持たせないようにします。そうすると黒の部分だけ透過されますし、昼間夜間で画像を切り替えることも可能です。黒を基準に透過させますので、アルファチャンネルは不要となり、昼夜で思わぬ透過処理が入ることはありません。
上の写真でも四角いテクスチャの真ん中を明るくして回りを黒にし、そこを透過させる設定にしており、GP Wizardを使用するとこれらが表示されなくなってしまいます。

なお下手にAlpha Test Level を128以上にするとそもそものオブジェクトが消失するので、一般的な透過テクスチャは64~100で十分と感じました。
海外フォーラムでは結構128が勧められているですけどね(笑)

そもそも@では私が何かやらかしているからBGLライトが埋もれて消えてしまうのであって、非常に悔しいところであります。原因が分かったら追記します。

追記:↑原因は調査中ですが、なんとか普通にGround Poly Wizardを使った場合でも埋もれない設定を見つけましたので、応急処置はできていますので、ご安心を。
本当に、つくる空港毎で色んな固有問題が発生するんでしょうね。シーナリー作成、大変ですが解決したときは本当に嬉しいです。ご機嫌になります(笑)

以上、最近の研究報告でした!
それではまた。
posted by RUTE at 12:00| Comment(0) | シーナリー制作日記

2019年06月08日

松山空港: シーナリー進捗状況16

こんにちは。

(3月の最後の書いた記事なので、時系列が矛盾してる場合があります。すいませんw)
お伝えしました通り、3月の初めにグランドポリゴンが完成したので、ここ最近は空港の小物類を作成していました。
これが結構めんどくさい...(笑)
一度作ってしまえば、次回作以降は少し楽になるのでしょうけど。写真を加工して流用してしまったりと、結構さぼりました。

まずはライトからです。
rjom178.JPG
こういった設備は、いくつも配置する必要があるので、FPSへの影響を最小限にとどめなければなりません。

しかしながらグラフィックボード付きのPCなんか、15万もあれば(15万もあれば?)そこそこいいのが買える時代になりましたし、FPSって最近はほとんど気にしていないように感じます。

そして今後のことを考えれば、性能は指数的によくなっていくわけですし、できる限りリアルにモデリングするのが良いと思うのですが...かといって私のPCはというとザ・ミドルスペックという感じで、やりすぎるのはよくないのと、ほとんどの方が「フライト中照明はそんな見ねえよ」という感じだと思うので、FPSを考えつつ考えすぎずで作っていました。

これが結構難しいんですよ。この塩梅が(笑)

前回の誘導路灯の作成で、ハローパネルを作ったときに、透過テクスチャの技を覚えたのでそれをふんだんに利用しています。
テクノブレインの作品なんかを見てテクニックを盗むわけですが、この透過テクスチャ、本当にFPSへの影響が少ないのでしょうか。。。

rjom179.JPG
これは今回作成した、ドリーを引っ張るトーイングトラクターです。調べるとTOYOTAが造っているんだそうです。2TE15という車種名です。
TOYOTAといえば、新しくSUPRAが出るんですよね。BMWのZ4とプラットフォームを共通化するそうです。エコカーエコカーで具合が悪くなりそうなこの時代、スポーツカーを作るにはそうするしかありませんね(^_^;)

で、お得意の脱線が決まったところで。タイヤを見てほいんです。私は円を描いていますが、おそらくTBの作品では真四角になっていると思います。しかしながらTBでも見た目は真ん丸。

これはおそらく透過テクスチャです。タイヤを制作し、外周をアルファチャンネルにしているのだと思います。私もそうしようと思ったのですが、画像処理とポリゴンの計算、どっちが早いのかということを考えてみました。

なんか適当な勘ですが、透過処理のほうが時間がかかるような気もします。
で、ポリゴンは増えますが、円形にしてみました。というのも、最近のゲームでは、モデリングを簡素にするというよりも、テクスチャにこだわっているものが多いように思えます。4Kとか、Full HDとか。そこから推測するに、モデルのポリゴン計算はかなり早くなったのでは?と感じているからです。
それよりもテクスチャのロード数、枚数を減らすほうがFPSに良いと聞きます。そう考えると意外と透過処理もFPS食いの原因になるのではと思いました。

どっちが早いのか、正確に言えば「今のPCではあまり違わない」が正解の感じもしますが、とりあえずそこまで無理に透過させない作戦で行ってみました。失敗したら修正します。
よく調べたらやはりこの点については、派閥に分かれる系の話題みたいです(笑) 情報系こういう流儀分裂問題が多すぎます(笑)

rjom180.JPG
これは車種調べが大変でした。おそらくいすゞのFORWARDの2003年式です。2003年ながらいまだに羽田でも見かけます。
とにかくこういうのは、テクスチャ作成がくそめんどくさいです(笑)
私はテクスチャ作成がへたくそなので、時間がかかります。上のトーイングトラクターの2TE15は、テクスチャを作るだけで休日丸2日消えました(笑)

このパッセンジャーステップに関してはそれ以上かかっています(^^;)本当に作成していて思うのは、シーナリー作成ってこんなに大変だったんだということです。フリーの方もみんな有料化すればいいのに、と思います(笑)
ほんと、これ10万くらいは欲しいですよ、いただけるなら(笑)

みなさんも、やってみてください。一人でやるのは超大変です。著作権とかがありますから、ネットの画像を拾ったりして使えないんですから。オールハンドメイドです。ですからというわけではありませんが、「あんまリアルじゃねえな」とか心のなかで呟くのはほんとにやめてください(笑)フリじゃねーから!
そういうこと思う人には、私の松山はお渡ししませんので、どうぞMSFGへ(^_^;)

あとはドーリーですね。
rjom181.JPG
おそらく花岡車輌という会社が制作しています。右はANAが、真ん中は主にJALが使用しているようです。左は右の色を白に換えただけのオリジナルです。

rjom182.JPG
最後はLD3コンテナです。右端は、羽田で787に積まれているのをよく見ます。
コンテナは大体メーカーが主要諸元を発行してくれていますから、基本はその寸法に従えばいいので、少し楽になります。
それでもテクスチャ作成や、そもそものメーカーの特定なんかが大変です。主要諸元もなかったら...ぞっとしますね(笑)

まだまだ空港には、たくさんのはたらくくるまがあります。まあ、必要そうなものをとりあえず即席で作った感じです。今後バリエーションを増やしていけたらと思います。

この後は、これらを配置すればとりあえずグランドポリゴン関係は完了です。そうしたら、航空貨物棟とかですかね。
グランドポリゴンまで完成したらもう一度テストです。すでに何名かの方にお願いをしています。よろしくお願いします!
予定より少し押している感もありますが...頑張ります。

新元号 令和まであと少しですね。お休みの方、お仕事の方それぞれいらっしゃると思いますが、素敵なGWをお過ごしください!
それではまた。
posted by RUTE at 09:00| Comment(2) | シーナリー制作日記