いままで3Dオブジェクトをひとつも作ってきませんでした。ハンドリングの仕方はいちおう身につけているのですが、じつはいま用いてるトラック作製用のPCは、123doがまともに動いてくれないのですよ。たぶんビデオチップと合ってないんだと思います。ノートなので、これはどうしようもなくて。

そのため3Dオブジェクトを作るには、全面的に作製環境を移行する必要があります。今日あたりからそれに着手するところ。ノーマルのwin98なので、こっちはこっちで心配なんだけど。

ぼちぼちやってゆきましょう。

さきほどからtso(track side object)作製へ向けて、環境移行を行っています。いくつか気づいたこと。

・新環境では、win98のせいなのか、ビデオチップのせいなのか、3DOEDの描画速度が格段に上がっているのに気が付きました。感覚的には数倍速い。これは強力な武器になりえます。
・こまったことは、色調がメチャメチャなこと。これ、モニターが悪いと思う。1995年のものです。リフレッシュレートも75hzが最高。いまどきネーよ、こんなの。結局、テクスチャに関してはノートPCで確認するしかないようですね。LANでつなげるしかないのかな。これはスタンドアロンにしておきたかったんだけど。
・いちおうメタセコイアも問題なく使えそうですね。よかった。


・・・さきほど、旧プロジェクトの鈴鹿を走ってみました。一段落付いたな、と思えたからです。私自身が鈴鹿を作ることを決意してからは、一度も走っていませんでした。走るのが恐かったという気持ちもありますし、旧プロジェクトの出来不出来に左右されたくなかったということもあります。また、旧プロジェクト断念を決定した最終責任者は私自身です。そういう意味で、あらたに私自身が作り始めることに、はたして意味があるのだろうか、ということがずっと引っ掛かっていました。

さきほど旧鈴鹿を走ってみて、いま私が作ることに意味があると確信できました。私は私のクオリティで行けばいいのだと思うことが出来たわけです。私自身の3DCGの取り扱い方の習熟や、F1 2001からのGPSデータの抽出など、タイミング的にも今しかなかったと思います。私自身がイニシアティブを取ったとしても１年前なら、第３評価版のようなものはできなかったと思います。

テスターの方々、今後もよろしくおつきあいのほどを。

なにが「あ」かというと、なんだかんだと身の回りをひっくりかえしていたら、あーた、2000年の鈴鹿グランプリのビデオが出て来ちゃいましたよ。これのことすっかり忘れてた。

いままで苦労して空撮やら地図やら写真やらから読みとってイメージを作っていった西コースの地形なんかが、俯瞰視点からのカメラで一目瞭然。あたーーっ。この一ヶ月はなんだったの？（そこまでいかないけど）

もしかすると、バンクをもう少し見直すかも知れません。とくに１・２コーナーはもう少し強いバンクがあるかも。いつでも直せるエレポンさん、ありがとう（また言ってる）

てなわけで、各コーナーのうち足りなそうだなっちゅうところに10cmほどバンクを注入しました。でもね、走ってみるとあんまり変わってないのです。まあ、こんなものかなと。

しばらく高低差、バンク角から離れよう。

各ウォールに貼り付けるmipの作り方の覚え書き

基本文献
http://www.geocities.co.jp/Playtown-Darts/8998/
by umrk
「カーテクスチャの軽量化について」以下各文

ツールと手順
・グラフィックツール（photoshop,paintshop pro etc）で元画を描く。
・サイズは縦横が２の階乗になっていること。128×64、256×256など）
・編集は24bit色で行い、その後減色（4bitか16bitへ）
・私は4bitへの減色をpadieを使っています。
・透過色がある場合は元画に使われない色を使う。私、フェンスの透過部分にピンク色を使ってみたんですけど、透過の抜けが悪くてうっすらと赤く色が出ちゃいました。そのため、元画に比較的近いけれど使われないという微妙な色を使いました。
↓
・winmip2
・編集・減色済みのbmpを開く。
・透過させたい部分がある時は、uをポチッとしてIに変える（4bitの場合）。→typeが1に変わる
・ドロップダウンリストのbmpをmipに変更。
・sub-Imはとくにいじらず。

・typeの説明
0   4bit   透過色なし
1   4bit　１色透過色
2   4bit　4bit透過
3  16bit　透過色なし
4  16bit　１色透過
5  16bit　4bit透過

・Mappの説明
0　縦横にリピート
1　センターライン方向に対し90度方向にリピート
2　センターライン方向に沿ってリピート
3　リピートなし

そしてmipで保存。
↓
・texにて、どのウォールに貼るべきかを指定→コンパイル。
・リピート設定をした場合、何メートルごとのリピートかをこのtexにて設定可能。

その他詳細は、umrkさんの文章を参照のこと。

RSCでも指摘がありましたけど、第三評価版は、ポリゴンの数が多すぎますね。調子に乗ってドテを作りすぎました。

げんに私の作製環境（1Ghz前後）では、シケイン部分が相当にキツいです。これでは20台のマシンがこのあたりに集まった場合、レースにならないかも知れない。これはまずい。

原点に帰りましょう。リアルであることは大目標ではあるけれど、これは飾り物ではなく、ゲームなのだということ。レースをしていて楽しい状態に出来なければ、作っている意味はないのだと。

第三評価版のドテは、将来、大胆に削減する可能性大です。変わりにtsoで地形を作りましょう。そういう意味では現第三評価版は貴重かも知れませんよ（笑）。

今日明日あたりで、tso作製の方法論を確定させてしまいたいと思っています。いま試行錯誤しているところ。

おおざっぱな流れは、
・メタセコイアで基本ポリゴン作製。
・dxf出力
↓
・123doで読み込み
・スケール調整、テクスチャ設定
・ase出力
↓
・ase23doで3doに変換。
↓
・bmpをmipに変換（winmip2）
↓
・位置設定（tsoファイル）
・コンパイル


ってことになります。
問題はメタセコイアと123doの連携。どうもdxfで出力する時に、左右反転と、どこかの軸を入れ替えないといけないみたいなんです。それがどこなのか分からなくて。いま簡単なポリゴンを使って検証しているところです。

しかしノートPCで123doを使っていると、恐怖のブルースクリーンになるのですよ。XPですよ。２ヶ月起動しっぱなしでも落ちないのに。ビデオチップが合わないと「致命的」だそうな。こわ。・・・というより、このおかげでtso作製が超めんどう。

参考になるか解かりませんが＾＾；
メタセコイアで裏表の面を調整し、３Dstudio,４点出力、左右、面反転で保存（メタセコイアでもう一度開く時は、左右反転で開く）。　それを取り込む訳ですが...私の環境では、１２３doで始めにサンプルのbox.3dpを開きそこにimport。でbox部分を削除して保存。でもう一度box.3dpを開き、add another projectで先ほど保存した所へ。　これで何とかeditできるような物になる複雑な作業をしてます(T_T  角度については、一度設置して見てからと言う感じで＾＾；３〜４００面前後であれば３doにできる感じですがeditしている内に裏表が解からなくなり簡単な物でテクスチャーでうまく見せる方が良い気がします＾＾；
 

▼ udonnさん

貴重な情報ありがとうございます。123doがモデリングしやすいものであれば、こういう苦労をしなくていいんですけどね。座標を数値で指定して頂点をずらしたりしてエディットなんて・・・

メタセコイアのモデリング力にたよるとすると、こういう方法しかありませんね。あとはクリッピングが心配ですが。

udonnさんもがんばってください。

udonnさんの情報のお陰で、いちぶ実験を省くことが出来ました。あらためてありがとです。

でね、画像が立体交差ですよ、あーた。面倒なのでガードレールのmipを貼り付けてます。しかもスケールがめちゃくちゃ。でもね、狙ったところに狙った角度に収まってくれたのは成果ですし、何よりもtsoが置けたことをまずは収穫としたい。一歩一歩です。

そして何よりもメタセコイアとの連携がちゃんとできたこと。皆さんが思っている以上に、わたしは嬉しいのですよ、ほんと。

やっぱりウォールと重なっている部分はクリッピング現象が置きますね。そうじゃないところは安定してるんだけど。

マニュアルにtsoの設定を書きましたよね。あのなかに一部間違いらしき部分がありましたので、ここで訂正しておきます。

１行目の

# Trackside 'Sets': 4

ここね、私のマニュアルの説明では、オブジェクトの総数を書き込むと書いたのですが、違っているようなのです。eguzoさんが指摘してくれて、で、私自身が今回確かめてみて、はっきりしました。

この１行目には
Set List部分のオブジェクトの数だけ書く。つまり走行可能な部分に置くオブジェクトの数ですね。これを書くのだというのが正解のようです。infield objectとoutfield objectの数は含めない、ということ。

なぜこんな間違いをしたかというと、
http://home.online.no/~bi-knu/editing/trk23dow/tso.htm
ここの例を参考にして、マニュアルを書いたからなんですね。ここのtsoの記述がどうも間違っているらしい。

というわけで、ここではeguzoさんにありがとうを言っておきます。皆さんにお世話になっています。いずれマニュアル本文も直さなきゃね（時間がない〜）

あら、大変。
こんなに大きかったのね（笑）

ちょっとずつ、作り込み。
とりあえず、最小のポリゴン構成でやってみましょう。あとはテクスチャでごまかすか。スケールを算出しないといけないな。

dirtの属性を与えたウォールにテクスチャを貼る場合、mipのmapp設定を2（センターラインと平行にリピート）にしていると、テクスチャが不可解な振る舞いをします。以下は某所にて検証してみたものを書いたものです。昨日はほとんどこのことをやってました。私も勉強になった。

結論から言いますと、どうなってるのか分からん、ということです（笑）

−−−−−−−−−−
実験してみました。

mip設定
type 0
mapp 2

tex設定
6 0 0 10.0 10.0 sand


そうすると画像のようになりました。
見たところ、センターラインから10m部分まで、「あ」が貼られているようです（ただし「あ」が鏡像になってますね）。

ここで仮説が浮かび上がりますね。
mapp2の場合、texの横方向（センターラインに直角方向）の数値10mというのは、センターラインからの幅になると。その幅には、テクスチャが一杯に貼られるのだ、っちゅうことですね。そしてそれを超える部分は、mipのごく一部が短冊形に貼られるのだと。

そうするとtex設定で横方向の数値をいじるとある程度はコントロールできるものの、センターラインからの距離になるため、ねらい打ちが出来ない。

いやねらい打ちの方法はあるか。
貼られるべきウォールの左端と右端のセンターラインからの距離と、texの横の値が分かれば、ねらい打ちできますね。センターラインから狙ったウォールの場所までは空白にすればいい。割合で計算上何pix当てるべきかでてくる。


もう少し追求してみます。横方向を20mにするとどうなるか。

> もう少し追求してみます。横方向を20mにするとどうなるか。

あれ？
横方向の設定20mにしたら、文字が全然見えなくなってしまいました。どうしちゃったんだろう。

それとさっき気づくべきだったんだけど、貼られているのはコースの左側だけですね。うむむ？

今度は5mにしてやってみます。

texの横方向の値を5mにしてやってみました。

さらに分からなくなってしまった。

3doedの画像を見ると横方向が5mごとにリピートしています。UV値があるのか、あるいはmipの設定を無視しているのか、よくわかりません。

ところが、GPL内では、画像のようにヘアピン奥のダートですけど、前２列分の「あ」がありませんよね。たしかに「あ」が描かれている部分の幅は5mになっているようですけど。

しかもセンターラインから5m幅でもないわけで、つまり先に述べた仮説は、はずれということになります。

わからなくなっちゃいました。どういうルールで描画される場所と、されない場所の違いがでてくるのか。

結局mipのmapp設定を0にしないと、ねらい打ちできないのかな。すんません。いまのところ、お手上げ。

−−−−−−−−−−−−−−

以上が、某所にて書いたものです。情報の共有という点から表にも載せておきます。あまり役に立たない情報ですけど、dirt部分のテクスチャの注意点にはなると思います。

立体交差自体はいい感じになってきてます。やっぱりテクスチャがいいと結構ごまかせるんですね。

そりゃそうと、やっぱりクリッピングが直りません。リファレンスをいじったり、ポリゴンが重ならないようにしてるんだけど。・・・こんな具合に問題が起きるわけですわ。

最終的には問題の場所を削除して、tsoで作ってしまえばいいんですけど、もう少しじたばたしてみないと思います。どんな条件でこうなるのかが分からないと、別のケースで知恵になりませんからね。でも条件が割り出せるだろうか。

誰か、教えて（笑）

クリッピング出現条件究明のための作業仮説。

・tsoファイル中のreferenceに問題がある。立体交差以降二つ目のセクションぐらいまでは、立体交差が劣後、それ以降は優先していることから推測。
↓
referenceをいじって確認。

・オブジェクトの大きさ。二つ以上のセクションにまたがるオブジェクトはクリッピングが起こりやすいとの記述あり。
↓
小さなオブジェクトと置き換えて確認。

・現在tsoファイルのinfieldの部に置いているが、set listに置くべきかも。tsoが部を分けている意味が分からなかったが、もしかすると描画の優先順位をつけるための部なのかも。そう考えると納得が行く。
↓
set listに移してコンパイルして確認。

上記の作業仮説はすべてハズレでした。・・・痛い。

ただ、クリッピングが出現する条件は分かりました。オブジェクトが、手前のトラック部分と奥のトラック部分にサンドイッチされた瞬間に盛大なクリッピングが生じるようです。最初はどこかのセクションがトリガーになっているのかと思ってたんだけど、違いました。track--tso--trackという関係がよろしくなかったようで。

で、RSCで解決方法を見つけました。ただ、意味がよく分からん。かのGuru氏のお答えです。

> i thought you'd get problems with that when i first saw it bill  this is a tricky one to explain (and i don't really understand it myself!) but you need to get rid of track->infield3do->track clipping. this is done firstly by cutting your object into convex pieces. once that is done you need to reduce fb distances as much as possible so the track won't be seen 'through' the infield3do. once that's done you might need to get rid of some walls (or make the reverse side of them transparent), and fiddle the infield/outfield references so gpl draws the infield3do from extra/fewer track sections. it's very complicated, and papy should really apologise for the crappiness  (i heard even they had problems getting objects to not-clip in this way, and they understand the algorithms for visibility!!)

意訳。
・まずオブジェクトを凸面状の断片に切断する。
・fbディスタンスを、オブジェクトを通してトラックが透けて見えないところまで短くする。
・そしたらいくつかのウォールを取り除く。あるいは反対サイドにウォールを作る。
・referenceをいじって、オブジェクトがうまく描画されるように加減。

日本語に訳しても分からん。
ただpapyの開発陣も悩ませるものだそうで。描画のアルゴリズムがよくないみたい。
しかし・・・
凸面状の断片ってなんだ？

クリッピング出現、直前の画像。

※立体交差の向かって右はこんもりした小山がくるため、だいぶ省いてあるのが分かりますね。


クリッピング回避のひとつの方法として、奥のドテ部分をすべてtsoで作ってしまう、という手もあります。そのほうが、軽くなると思うし。でも最後の手段かな、これは。

昨日ここにあげた画像を見ていて気が付いたんですけど、左側の橋脚は後ろが透けてませんね。明らかに橋脚の底の部分が手前のガードレールと後ろの樹木に挟まれているのにクリッピングが起きていない。右の橋脚の底がガードレールに隠れた時に限ってクリッピングが生じる。

昨日の画像で○を書いた部分は、自分でも気が付かなかったんですが、3Dオブジェクトの0基準になっている場所なんですよ。オブジェクトはこの基準点の場所をtsoで指定して、居場所を定めることになっているわけですが、この画像を見る限りクリッピングが起きるかどうかはこの基準点が決め手になっているのではないでしょうか。

そう考えると逆向きから立体交差を見た時にクリッピングが起きないことも説明が出来ます。

ということは、オブジェクトを作る場合、0基準点をオブジェクトの上の方に持ってくれば、手前のガードレールに隠れてしまうことがなくなるわけで、そうすれば「サンドイッチ問題」を回避できる！！

これも仮説に過ぎませんが、やってみる価値はありそう。回避の方法は幾筋もあるんでしょうけど、できれば一番楽でスマートな方法で解決したいです、はい。

くわーーっ。
やっぱりだめだった。オブジェクトの0基準点は関係ないようでした。

あと問題になりそうなのは、セクションとfbぐらいかな。

もう最後の手段に行くべきだろうか。

でもちょっと不思議なのは、はるか先のほうは透けて見えてないこと。可視深度かな、やっぱり。

急転直下、って言うんでしょうね、こういうの。

何をやったかというと、もう半分あきらめてですね、次のセクションのドテ部分を削ってゆこうと着手しはじめたんです。でね、ものは試しと、次のセクションのドテの後ろにある樹木があるでしょ、あれをですね、手前だけコース近くまで引き寄せたんです。右側のドテ部分ね。

そうすると樹木は、立体交差の橋脚に対して裏側を見せることになるでしょ（わかるかな）。いずれ分かるような画像を置きましょ。

そしたら突如、クリッピングが消えちゃったのですよ。ぜんぜんビクともしない。

最初から、あきらめていれば、ヨカッタ。
↑
みなさん、
ここから人生の教訓を引き出したりしないように。

直ったことに興奮して、分析しておくのを忘れました。

改善の直接の原因は、画像に示したように、立体交差の先の右のドテ部分の奥の樹木部分を、手前だけコース近くに引き寄せたことでした。こうすると立体交差は、ドテの裏側と接するようになります。

ドテの表側というのは、草地で斜面になってますけど、厳密に言えば「走行可能なウォール」になります。先に述べたサンドイッチ問題というのは、この走行可能なウォールに、オブジェクトが挟まれた場合に出現するんだと思うんです。サンドイッチ状態になると、描画の優先順位として、オブジェクトよりも走行可能な部分のほうが優先されちゃうんでしょうね。でも後方にある物体のほうが優先されるなんてのは、アルゴリズムに問題がありますよね。

逆に、ウォールの裏側というのは、走行可能な部分ではないので、それと挟まれたとしても別にクリッピングが起きるわけではない。・・・この解決方法はそう考えるべきなんだろうと思いました。

それと、やはり左奥のドテは走行可能な部分であるにもかかわらず、挟まれてもクリッピングが起きてません。これが0基準点がポイントなのではと誤解した原因でしたけど、重要なのは0基準ではなく、この立体交差オブジェクトがinfield objectなんだということです。tsoの設定中の、右手のオブジェクト、ですよね。ということはoutfield objectの場合には、これとは左右反対の現象が起きるのかも知れません。

以上、簡単な分析でした。