それと「Ｚバッファ干渉」という用語は恐らくＶＲＭ界独自のものであり、３ＤＣＧ界の方では「Ｚファイティング」という用語が使われていますが、この記事内では「Ｚバッファ干渉」という用語を使用します。
久しぶりの長文ですのでご注意を（笑） 緑の文字は雑談ですので飛ばしても良いでしょう。
なお「ココが間違っている」という点にお気づきの方はご教示くださいませ。では。
＜ジオメトリ演算処理＞
まず、Ｚバッファについて語るためには、「ジオメトリ演算処理」というものを知っておく必要があります。この「ジオメトリ演算処理」というのは、仮想空間上の立体モデルをスクリーン座標に変換する演算処理のことです。簡単に言うと、人の目で見ても何なのかよくわからない３Ｄ座標情報の集合体を、人の目で見て形がわかるように２Ｄのモニター上に投影する処理のことです。
最近は、この「ジオメトリ演算処理」能力もＰＣに要求されるレベルが非常に高くなっています。昔は「ジオメトリ演算処理」もＣＰＵに要求していたのですが、リアルタイムレンダリングのように高負荷のものは、流石に汎用の演算装置であるＣＰＵではまかないきれなくなり、ビデオカード側にＧＰＵなどと呼ばれる「ジオメトリ演算処理」専用の演算装置がつくようになりました。そのせいでビデオカードにも大きなファンが付いたり、電源もバスだけでは容量が足りず電源から直接ケーブルで繋ぐようになったりと、どんどん大掛かりなものになってきています。価格も下手をすればＣＰＵよりも高価になっていますね。
たまに勘違いしている人がいるのでちょっと付け加えますと、このＧＰＵの処理というものはリアルタイムレンダリング専用ということであり、３ＤＣＧソフトにおける静止画の最終出力レンダリングの処理はＣＰＵが行っています。ですから、３ＤＣＧソフトで最終レンダリング出力を高速化したいなら、ＧＰＵではなくＣＰＵをパワーアップさせなければ意味がありません。３ＤＣＧ用ワークステーションに高価なビデオカードが搭載されているのは最終出力用ではなく、事前確認用のリアルタイムレンダリング（DirectXよりもOpenGL用にチューンされていることが多い）のためなのです。最終レンダリング出力は非常に時間がかかりますから、時間を無駄にしないためにも事前確認は大切なのです。
ＶＲＭユーザーにはあまり関係ない話でしたね。ＶＲＭユーザーはＧＰＵの方が重要ですから。でもＧＰＵだけでも駄目なんですよ。ＣＰＵが全体をとりまとめていますから、ＧＰＵの性能に見合うクラスのＣＰＵにしておかないとＣＰＵがボトルネックになったりしますので。あとメモリも関係しますが、この辺のことは他の場所等で調べてください。私は「元」パワーＰＣユーザーなので最近の状況はあまり詳しくはありません（私のバックには現役というか、ある意味プロがいますけどね）。
話が脱線しましたので元に戻しましょう。
＜Ｚバッファ法＞
Ｚバッファ法というのは、この「ジオメトリ演算処理」における隠面消去方法の１つで、最も単純な原理のものです。
簡単に書くと、投影される画面上の各画素において（つまり画面上の各ピクセル単位で）「表示すべき最も手前のオブジェクトまでの距離とその色は何か？」ということをバッファに記憶していく方法です。この距離（奥行き）のことをＺ値と呼び、その記憶領域をＺバッファ、色の記憶領域をフレームバッファと呼びます。画素１点１点が計算されて画面に表示されている訳です。単純で高速が売りのＺバッファ法ですが、膨大な計算がなされていることになりますね。また、メモリを多く消費する点が欠点とされています。
文字ではわかりづらいと思うので、実際のＶＲＭでの状況予想を絵にしてみましょう。
＜１画素あたりの「Ｚバッファ法の計算量」と「レンダリング範囲」との関係＞
「一番近い点はどこか？」を調べるために、一番奥から調べていく訳ですから、「レンダリング範囲」が大きくなれば計算量が増えますし、画面を大きくしても画素が増えるので計算量が増え、その分表示速度が遅くなるということです。
Ｚバッファ法以外にはＺソート法というものもあります。これはオブジェクトの面を基準とし、一番奥から面をどんどん書いていき、一番手前の面が書きあがった時に絵が完成するというやり方でＢＡＳＩＣ時代の絵の書き方がこんな感じでしたね（若い人にはわからないかもしれませんが）。これ以外にも、スキャンライン法やレイトレーシング法というものがありますが、こちらは精細な絵が得られる一方で、非常に時間がかかるのでリアルタイムレンダリングでは使われることはありません。静止画用の最終レンダリングに使われるやり方です。
＜Ｚバッファ干渉＞
さて、以上を踏まえて、本題のＺバッファ干渉について書きましょう。もう隠面消去方法の仕組みが解ってしまえば、どうしてこういう現象が起こるのかは理解されているとは思いますが。
まず、現象としては、
「同一平面上に面が重なった時に表示がおかしくなる」というもので、下図のような状態を指します。
更に「視点を移動させると面がチラチラと表示される」というものですね。
何故こんなことが起こるかと言えば、Ｚバッファ法の仕組みから、「同一のＺ値なので表示すべきフレームバッファの色がどちらの面であるべきなのかＧＰＵが正確には判断できないから」ということです。それでもＧＰＵは判断し表示しなければいけません。ですから重なった部分において、ある部分はコチラの面、またある部分はアチラの面というような安定していない結果になってしまい、混じり合ったような表示になってしまうのでしょう。
上図のように視点を横に平行移動させた時は、Ｚ値があまり変わらない（バッファ内容があまり変化しない）ので、似たような表示が得られますが、
視点を回転移動させた時や近づいた時は計算結果によって、全く異なる表示結果が得られます。これが視点移動した時のチラつく原因になっているという訳です。
運転席視点で直線部よりも曲線部で画面表示速度が遅くなるという現象を私はＶＲＭ４で経験していますが、恐らくこの辺の影響があってそうなっているのだろうと思います。
＜Ｚバッファ干渉対策＞
元々この記事を書いたきっかけは、
45-50sさんのsuch a cool「両渡り線に一工夫」
↓
tettaさんのSKY & ICE「九州からの雑談」
の流れを受けたものです。
45-50sさんは記事の中で面が重なる部分に「0.1mm」の差を付けるようにして対策をとられていますが、私もその「0.1mm」ぐらいが経験上良いのではないかなと思っています。通常の状態で使う分にはこの値で問題ないでしょう。ただもっとこの値を小さくしたいという場合には、これから書くことを頭にいれておかないと「あれ？」ってことになります。
まず下図を見てください。これは「0.01mm」の差をつけた場合の表示です。
どうですか？ おかしくないですよね。しかし、カメラを遠ざけていくと・・・
Ｚバッファ干渉！
つまり、こういうことです。
最初のおかしくなかった絵のＺ値を仮に10mmとし、おかしくなった絵のＺ値を仮に100mmとしましょう。
そうすると前者での２面の距離は、10.01と10.00で、0.1％（0.1ポイント）の差ですが、
後者での２面の距離は、100.01と100.00で、0.01％（0.01ポイント）の差になる訳です。
表示を高速化させるために、ある値で数値の丸めが実行されます。そこで0.1ポイントの差なら差として認識されるが、0.01ポイントの差では丸められて0、つまり同一平面と見なされるということが起こるということです（具体的にどの値で丸められているかは不明ですので、0.1とか0.01とかの値はあくまでも仮の話です）。
ということで、あくまでも比率によるものであるということを頭にいれた上で、値を決める必要があるという訳です。先にも書きましたが余程のことがなければ「0.1mm」の差で良いでしょう。
さて、tettaさんの記事の中で、「こういう風に組み合わせたら確実にＺバッファ干渉を起こす」というものが知りたいというお話ですが、組合せパターンは無限にあるので、全てを列挙することは不可能です。原則論として同一平面上に面がある部品同士がＺバッファ干渉を起こすとしか言い様がありません。レイアウターでの配置ではＺバッファ干渉は気にせず、最終仕上げとしてＺバッファ干渉を潰していくというスタンスで良いのではないかなぁと個人的には思っています。もし複製したものをたくさん配置するならば、複製前に確認してＺバッファ干渉を潰しておかないと後で面倒なことになりますがね。余談ではありますが、第６号のマンションなんかでは部品単体でＺバッファ干渉を起こしていますし、どの程度Ｚバッファ干渉を潰すかは個人的な嗜好によるものになるでしょう。
最後に、３ＤＣＧの用語等に興味のある方のためにコチラのページを紹介しておきます。今回の記事を書く上で確認用として利用させていただきましたので。
