BISの公式サイトに製作者が発信するブログ(Developers Blog)というのがあるのですが、その中で自分が気になったものを、つすなわち自分は島作りに興味を持っているので、基本的にその辺に関連する記事について翻訳してお送りします。
　第一弾は、
　ArmA2 Vegetation progress
　http://www.bistudio.com/developers-blog/arma2-vegetation-progress_en.htmlと
　ArmA2 Vegetation progress 2
　http://www.bistudio.com/developers-blog/arma2-vegetation-progress-2_en.html
からです。いずれも古いエントリーですが、ArmA2から植物面で大きな変化がありそうなので、気になって訳してみたのです。

============ 以下、翻訳文 ============

　現在、ArmA2用の木や茂みの最終作業を行っているところです。植物に関する最大の問題は、ゲームパフォーマンスに与える影響でしょう、そう私達はエンジンに対してたくさんの最新技術を、そしてLindaスタジオにおいても開発を行っています。私達はArmed assaultでのパフォーマンス問題についてとても深く分析し、そして私達は次のことを発見しました。それはシーンの最初の20mを描写することが主たる問題となっていることです。それが意味することは、私達はこの木と茂みのサーフェイス(表面)の描写を最適化する必要があり、そしていくつかのシェーダーの効果を高め、ゲームエンジンでこらの件に関して改良した描画技術を開発することです。そのために私達が行ったことは何だと思いますか？
　
　新しい木は、”polyplanes”という枝を置き換えるジオメトリの描写精度を高められるようになります。これによりサーフェイスの描写に使用される負荷を約30%低減しましたが、頂点数は増加してしまいました。植物モデルの頂点の増加と両面ポリゴンの低減を使用するこのエンジンについて、私達がお教えしましょう。
　
新しいシェーダー（3Dオブジェクトに対する質感の計算、処理）
　ArmAの樹木が使用するシェーダーは、テクスチャ（カラーマップ）とノーマルマップを使用し、ふたつのマップは拡散光と環境光を4つのステージに分けて薄めていました。現在、私達が樹木用の特別なシェーダーとして、テクスチャ、ノーマルマップ、そしてマクロマップというものを使うようにしました。このマクロマップとは、RGBのアンビエントライトマップと同じ、アルファチャンネルの中に移植情報を含めたものです。このソリューションは製作者に対し、樹木の見え方の描写コントロール、ひとつのステージに抑制し、以前のものより樹木は美しく映え、そしてシェーダーは素早く描写させます。私達は”プリコンピューテッド・ラディアンス・トランスファー”として知られる技術を使ったシェーダーを開発しました。この技術は2つのステージを必要としますが、これを植物の遠方LODに使いたいと考えています。これら全ての新しい技術は、LindaStudioの変更を要求しました。その例として、樹木においてはマルチUVの生成を可能とし、サードパーティのグラフィックソフト等でライトマップのレンダーができるようにするフォーマットをエクスポートすることです。
　
エンジンの変更
　ArmA2のエンジンは、Zプライミングとして知られる技法を使用することが出来るようになります。これにより、全ての植物は、透明なマスクを使ったシンプルなシェーダーを用いてとても軽快に描写することでしょう。二段階目として、樹木のシェーダーの複合とともにマスクされていないピクセルのみを描写することができます。これにより、描写量の削減をサポートし、将来的にはもっと複雑なシェーダーを使用できるようになるかもしれません。というのは、パフォーマンスの低減は、モデルのサーフェイスとシェーダーの複雑さに依存するからです。
　
　測定の結果によると、小数の面に大きなサーフェイスを使ったLODを使用するよりも、ハイポリの樹木に小さなサーフェイスを使用する方が、しばしばいい結果をもたらすことを知りました。私達は、こういった側面に影響する植物のLODを生成することができるLindaのパラメータを計測するツールを開発しました。
　
　植物の新しいモデルも、バーテックス(頂点)シェーダーがパフォーマンスに与える影響を低減する植物構造の頂点を最適化した改良アルゴリズムに基づいて使用します。
　
植物のビジュアル面
　Armed assaultは、バージョン1.5のスクリプトをベースとした樹木の生成機能を使用しています（OFP:Eが1.0を使用）が、ArmA2では4世代目の生成スクリプトを使用します。これは枝をよりリアルスティックに表現するよう生成し、ジオメトリの描写をもっと効果的に作用させます(ArmAでは、パフォーマンスへ影響を及ぼすので実体のサイズを可能にできませんでした)、またルート(根)システム、葉のカラー化の修正、リアルっぽい密度では唯一の枝別れを、現実世界における植物学をベースとして、樹木のほとんどをコントロールできるようになりました。

　そしてArmA2に関して最後に付け加えますと、特別なジオメトリであるビュー・ジオメトリ、ファイアー・ジオメトリ、衝突ジオメトリを自動で生成するを機能が私達を待っています。今までは常に手動でこれらを作成し、その上、射撃を防ぐものとしては正確ではありませんでし、AIは植物を素通ししてあなたを見つけることもできていました。私は、数週間の速さでこれを解決するだろうと望んでいます。
　
Clutter（草のサーフェイス）について
　樹木がパフォーマンスに与えるインパクトについて演習から学び取ってたこととして、私達は草のモデルを作成する新しい方法を開発しました。これは描写をArmAよりももっと効果的なものとし、さらに密度とビジュアルを寄りよく見せるものです。私達は、遠方のLODの頂点数や目標とするサーフェイス数まで削除する作業を行っていた第1LODに関する知識をベースとしました。なぜならば遠方のLODは、たくさんのピクセルの描写を制限するからです。
　このエンジンの変更も、植物クラッター(草、花)の色をサテライトマップの色に綺麗に合わせる上でも、また自然界にフィットする景観や、もっとリアリスティックに見えるように描写しないサーフェイスを作り出す上でも、ナイスと言えるものでした。
　
今後に向けて

　当面の目標は、ArmA2での樹木に関する技術とモデルが必要とする全てのキーの最終工程を終えることです。これの後、ポリ・プレーンの生成作業に入ることでしょう。ポリ・プレーンとは、O2のスクリプトによってコントロールされるジオメトリまたはモデルの全てを意味します。樹木のサーフェイスを削減し、より良い樹木の形状と、LODのスイッチをシームレスに見せることをサポートします。この技術は、花びら、フルーツ、特別なジオメトリを持つ樹木にも有効です。私達はジオメトリの最適化を続けることでしょう、そして樹木の成長をコントロールできるように作り出します。
　これらを実現するのにとても重要なことは、LindaStudioから直接、プリコンピューテッド・ラディアンス・トランスファーマップ、ライトマップそして半透明のテクスチャのレンダリングを含め、樹木のテクスチャをレンダリングするのにもっとオープンなパイプライン(作業を一貫して行えるようにすること)を持つことです。
　特別なLODの自動生成システムの開発は、第一段階においてはもっと普遍的なシステムになるよう進みことでしょう。そしてある時には樹木のスケルトン作成する機能ができ、植物の物理的な相互作用を考慮したシステムに将来はなっていくと思われます。
　
　

パート1からどんな進化を遂げたか
　生成された全ての植物はまもなく完了し、その後に私達は針葉樹をより良い結果にするスクリプトの作業のやり直しをトータル的に進めていました。現在は、植物の色のチューニングの最終作業に取り組んでいるところです。今、どのように表示されているのか、このスクリーンショットをご覧下さい。樹木がブレンドされた時の複数のセクションにおけるちょっとした出来事について述べると、いくつかの幹に対してライトマップが各LODを通した共有が行われないといった問題がありましたが、割と簡単に修正することが出来ました。しかし大きく焦点を当てたいのは、特殊な植物の各LODについてです。草薮でLODが切り替わる時に問題があるのは分かっていました。なぜならば、LODが違いすぎたからです。なので、ポリプレーンを選んで描写するアルゴリズムをやり直し、そしてコントローラブルかつフレキシブルなアルゴリズムを作りました。枝全体から類似のトポロジを見つけた時も、Lindaは決して検出しないという別のバグも出ましたが、これは今は改善されています。このバグは、ブッシュ用に特定しませんでしたが、ブッシュはもっと混沌とした構造になり、この問題によってもっと大きな影響を与えてしまいました。

　
我々はすぐに何を行ったのか？
　私達は特殊なLODの自動生成の作業を続けていますが、近いうちに完了することでしょう。今日、私は、Lindaが全てのジオメトリLODを生成した最初のブッシュをテストすることになっています。私達は、マテリアルまたはシャープエッジなどに対して弾丸を貫通させる定義の割当を自動化するような、3Dデータ上の簡単ないくつかのポストプロセスを見失ったままでいます。ですが、製作全体で使用するファイナルツールが準備する前ならば、これは手動で行うことも出来ます。私達は今、システムにとって2つの最後の大きな問題に直面しています。最初の問題は、ジオメトリモデルが正確で複雑すぎることです。私達はゲーム内でのパフォーマンスで消費されていきく簡単な結果を必要としています(コンポーネント単位でのポリゴン数の簡単なカウント)。第２に、時としてコンポーネントが多すぎると、似たような結果になったり同じ結果にならなかったりする問題です。これはコンポーネントの数が増加しすぎると引き起こされるようですので、いくつかの起因となる類似点を見つけだし、そしてこれらのコンポーネントの数を削減するようにひとつのコンポーネントにまとめることに結びつけていけるよう、システムでの作業を行っています。
　
　将来において、作業を通じいくつかの思いもしなかった効果があります。私達は、衝突やAIが検知するのに使う”ブロブ(塊)”ジオメトリが、ライトの効果を薄めるボリュームとして将来的に使えそうなライティング技法を見つけました。別の思いもしてなかった効果として、ポリプレーン上の塊を作るために用いるクラッター(草、花、石)を使用することで、密度情報そして将来的な利用方法として無数の枝の中心になることに気が付きました。
　
画像から何が見えるのか？

　カラーパーツの表示を用いてコンポーネントがLindaの中でどのように位置しているのかを、最初の画像から見て取れるようにしています。ArmA2は右側で、左側は ArmedAssaultでのオリジナルのジオメトリLODの画像です。Armed Assaultで作成したオリジナルのものより、どれだけ更に正確そうか見てみてください。私達は、ゲーム内でのトラブル、そう「私には見えるが撃てない、またはAIが植物越しに撃ってくる」のようなあの現象は、これが解決してくれることを望んでいます。

　この画像は、クラッターを現しています。枝のボリュームにおける密集するマーカーは、コンベックス(凸面体)コンポーネントの計算結果を使用します（下の画像）。右側は、ファイアジオメトリとビュージオメトリで、左側が衝突ジオメトリです。
　
ゲームプレイでのインパクト
　私達のエンジンでは、AIはビュージオメトリを通して狙いを定めようとし、小さなパーツであるあなたの体ですら、十分認識しますし追いかけることができます。ビュージオメトリが葉っぱで覆いかぶさってないとしても、あなたは狙われ続ける機会を与えています。次の問題は、ファイアジオメトリは葉っぱのコンポーネントのない幹として扱い、例えばあなたが草むらに隠れてもAIはあなたを見つけ出すことができ、彼らが銃撃開始するとこのジオメトリは空っぽとなり、交戦できるまでファイアジオメトリを固定されていました。開かれた空間に対し、空っぽの葉っぱのファイアジオメトリは、植物越しに手榴弾やロケット砲を通過させることができますし、これらの全てはもっとよく動作することでしょう。植物のジオメトリの作成に私達が挑んでいる理由は、簡単なタスクではありません。典型的なモデルにおいて私達は、これら特殊なジオメトリLODの各ボリュームを参考材料として各LODの段階を利用することができます。しかしいくつかのビルボード、または交差する平面から作成する植物は、簡単ではありません。正しい植物ボリュームの作成は、手作業なのでとても時間がかかりますし、難しさや、現実的に不可能な面も多々あります。膨大な作業の背景にあるのは、自動化された植物モデルがもたらした成果と言えます。
　
フローラ(女神)と小さな目の結晶
　私達はクラッターと自動生成できない他の植物モデルの作業を続けており、これを特別にフローラとして、次のブログのエントリーでお伝えしようと思っています。最初の花びらの画像は、Lindaにおけるフローラ生成の実験に基づく結果ですが、そんな私達の挑戦においてもLindaが使われているのです。