↑画像はにぎやかし。記事とは関係ありません。
xmlの<ａｎｉｍａｔｉｏｎ>で描画のレンジをもうける
先日inomatyさんから、近づくまで３Dオブジェクトを描画させないようにすることで、メモリの消費が抑えられないかとのアイデアをいただきました。
教えていただいたFlightGearの本家サイトのwiki（http：//wiki.flightgear.org/Howto:Modeling_Ground_Signs_with_Blender#Customizing_object.27s_attributes_into_Flightgear_using_XML）には、なんでもかんでも描画することでGPUパワーをそがないよう、近いときだけ描画させるプログラムの例が紹介されていました。
そこで、これを自作の寺院の建物にあてはめ、inomatyさんの提案にもとづいて遠くからでも見えていなくてはならない屋根や壁は残し、小さいが複雑な構造でメモリを喰い多数ある組物に摘要することにしました。
注）通常は、メモリの節約のため、組物には３Dモデルの使用を控え、もっぱら画像でことたれりとし た簡略 版の寺院を、FlightGearでは使うつもりにしていますが、ここでは３D化した組物をもつ寺院で試 しました。とはいっても、複雑な組物の３D化はごく一部にとどめ、ここでも簡略化のため平面の組み合 わせを用い擬似３Dですませています。
とりあえずは、組物の多い三重塔（薬師寺東塔）をとりあげ、実際には塔の３Dモデルから組物と手すりを一括して別のｋｕｍｉｍｏｎｏ.acとし、件のプログラムをxmlファイルに記述しました。内容は下記に記します。
結果は、特段の変化も感じることなく、FlightGearにて飛行でき、三重塔の組物や手すりが描画されていることを確認しました。ただ、組物や手すりがどのタイミングで描画されているかはわからず、早くから描画されていることだけは確かでした。
塔一つでは違いがわかるまではいかないだろうと考え、次は自作した寺院で適用できるものはすべて使って何か違いがないか確かめることにしました。ちなみに適用前に一度、また適用後にFlightGearを起動してみましたが、数量的に比較する方法がなくあくまでも感覚的になるものの大きな違いは感じられませんでした。多少前者の方が画面が止まる回数が多い気がするのは、多分に期待が反映しているのでしょう。
FlightGearの画面が止まるというのは、すでに古くなった性能の劣るノートパソコンでFlightGearを動かした場合、描画が追いつかず、しばし画面の動きが止まりかくっとした感じになることを言っています。
適用後と簡略版ともくらべてみましたが、これも感覚的なもので、わずかにまだ簡略版の方が画面の止まるのが短いかなというくらいのものでした。もっと寺院、３Dオブジェクトを増やせば違いが明確になってくるかもしれませんが。
ひとつ気になるのは、先ほどはタイミングといいましたが、どこまで近づけば描画されるのかについては、１５００m、しかもデフォルトとされていました。とてもそんなに近くないと思います。
今回、奈良への旅は関空から。その際画面が止まる瞬間が多いのは、離陸後と大阪市内に近づいたとき、そして生駒山を越えるときでした。咲洲庁舎が描画されるのは１０kmくらいに近づいたころでしょうか？ 薬師寺などのある西ノ京から生駒山までは８kmくらい？ ひょっとすると生駒越えの際の画面の乱れは、このときに東塔などの組物が描画されているのかもしれません。否、それだと咲洲庁舎が描画されるのとあまりかわらないので、組物だけでなく塔自体、建物自体の描画かもしれません。
となると、プログラムを書き間違っているのか、それともデフォルトは、１５００mではないにしてもFlightGearでの咲洲庁舎など他の３Dオブジェクトの描画と同じになっているのでは？ 先のwikiでは、この距離をカスタマイズできるような記述が見られますが。
【参考】xmlの記述
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<path>YKS-toutou-kumimono.ac</path>
<animation>
<type>range</type>
<object-name>kumimono</object-name>
<min-m>0</min-m>
<max-property>/sim/rendering/static-lod/detailed</max-property>
</animation>
</PropertyList>