回答:
lhfの答えはテッセレーションの観点からは良好ですが、これらはより単純な三角形メッシュの使用例で発生する可能性があります。
この3つの画面スペースの三角形、ABC、ADE、DBEの簡単な例を見てみましょう...
ポイントEは数学的にはラインセグメントAB上にあることを意図していましたが、パイプラインは有理数などの完全に正確な値を使用しません(例:https : //gmplib.org/)。代わりに、フロートを使用する可能性が高いため、近似/エラーが発生します。結果はおそらく次のようになります:
すべての頂点に不正確がある可能性があることに注意してください。上記の例では亀裂が示されていますが、代わりにTジャンクションがエッジに沿ってオーバーラップし、ピクセルが2回描画される場合があります。これは悪くはないように見えるかもしれませんが、透明性またはステンシル操作に問題を引き起こす可能性があります。
あなたは可能性があり、その後、浮動小数点で導入誤差は無意味であろうと思うが、レンダラーに、スクリーン空間頂点(X、Y)の値がほぼ常に固定小数点数で表される理想的な位置の意志からの変位に通常ははるかに大きくなります。さらに、レンダリングハードウェアは独自の内部精度でピクセルごとにラインセグメントを「補間」するので、Eの丸い位置から発散する可能性がさらに高くなります。
たとえば、三角形ABCを2つ、つまりAECとEBCに分割することによってTジャンクションが「削除」された場合、エラーによって導入されたシフトがすべて一貫するため、問題はなくなります。
さて、なぜレンダラー(特にHW)が頂点のXY座標に固定小数点演算を使用するのかと尋ねるかもしれません。問題を減らすために、なぜ浮動小数点を使用しないのですか?セガのドリームキャストなど、いくつかの問題が発生しましたが、三角形のセットアップの数学が壊滅的に不正確になり、特に細長い三角形では不愉快な方法でサイズが変化するという別の問題につながる可能性があります。
パラメータドメインのメッシュを使用してパラメトリックサーフェスをモデリングする場合、Tジャンクションはサーフェスの不連続性として現れる可能性が最も高くなります。これらは、レンダリングのギャップとして表示されます。下記参照。
より一般的には、三角形メッシュのTジャンクションは、おそらく色や法線などの補間された属性の不連続性をもたらします。
これを回避する簡単な方法は、すべての頂点が確実に溶接されるようにすることです
問題は、頂点に沿ってエッジに沿ってカットしているが、溶接/接続する隣接エッジに対応する頂点がないことです。シャツのボタンのように考えると、端にボタンが、生地が開いているようにそれに穴を与えていません。
以下の図では、赤い点は正しく溶接された頂点を表し、青い点はすべて隣接するエッジに切り込むために追加の頂点を必要とします。
一般的に、モデリングをクワッドとトライで維持することをお勧めします。これは、常に対応する頂点も溶接する必要があるため、この問題を軽減するのに役立ちます。また、メッシュ上でサブディビジョンメソッドを使用する予定がある場合は、クワッドを維持するのに役立ちます。