カバレッジ-アルゴリズムの欠陥-その使用を取り除く方法は？
前書き
メインラインのベクターグラフィックスレンダリングエンジンの多くには、アルゴリズム上の欠陥があります。これらは、各シェイプを個別にレンダリングし、ピクセルカバレッジを計算してアンチエイリアスを作成してから、それらを重ね合わせます。はい、それは簡単ですが、正しい解決策はさらに簡単です。
これは、透明度によってカバレッジを膨らませるので、合成の問題を引き起こします。アルファブレンディングは、状況を正確に表さないルールに従います。たとえば、50％カバーされているピクセルが、50％相補的カバーされているピクセルと隣接している場合、100％のカバレッジにならず、75％のカバレッジになります。 。これがどのように見えるかは、アルゴリズムの調整方法やその他の詳細によって異なりますが、本質的にはこれは既知のエラーです。誰かが、さまざまな engine errors を文書化して、それをどのように改善できるかを示す論文を書くという困難を乗り越えました。
画像1：三角形から作成された図形をレンダリングする完全に非代表的なサンプル。一番上の行に拡大されたエラーが表示されます。 SVGソース
この問題には、単純な単純な解決策*があり、カバレッジ計算のないスーパーサンプルであり、画像をフィルターで絞り込みます。おまけとして、ボックスフィルタリングよりも優れた画像再構成アルゴリズムを使用できます（読み取り ピクセルは正方形ではありません３ ）。現在のソリューションと同等の速度を持つソリューションもあり、これらのソリューションはハードウェアラスタライゼーションパイプラインで実行する方がはるかに簡単です（この問題を回避するために構築されているため、GPUでこのエラーが表示されることはほとんどありません）。
これもコストがかからない問題ではありません。グラフィックデザインで作業している多くの人が、この問題を手動で回避するために重要な時間を費やして、ここでオーバーラップがあり、オーバーラップがないことを確認して、コンピューターがそれらに対して行うべき問題を修正しています。そして多くの場合見事に失敗します。しかし、クライアントは、エラーがなぜそこにあるのかを気にせず、修正する必要があります。
質問
エラーはどのように伝播しますか？それらはすべて同じエラーを実行しているため、アルゴリズムに同じソースを使用していると結論付けることができます。デザイナーがこのアルゴリズムを選択した原因は何でしょうか？ 3Dプログラマーだけがこのエラーを認識し、2Dプログラマーが認識しなかったのに、APIと教育でその部分を成文化したのはなぜですか？
このエラーがそれ以上伝播しないようにする方法を教えてください。
補遺（しかし私はこれについて尋ねていません）
*どうやら、スーパーサンプリングが問題なく機能するという私の主張は異常であり、異常な証明が必要です。 OK、つまり、スーパーサンプリングが機能するkeyは、スーパーサンプリングがカバレッジ処理を行わないことです。本質的に、スーパーサンプラーは各サンプルをポイントサンプルとして扱います。ポイントサンプルは基になる領域を想定していないため、アルファ比較が発生しない場所では発生しません。
答えの1つで説明されているように、それが一貫して機能するために。一貫性を保つために、サンプルを整数サンプリングで処理する必要があります。これにより、一度スクリーンスペースに変換された各ポイントが、等しい座標に対してまったく同じソリューションを取得し、サンプルがピクセル境界によって2回シェーディングされないことが保証されます。これを行うには、サンプルが左下のサンプルである場合、サンプルがピクセルをトリガーしない可能性があります（そのため、正確なエッジが> vs <=で処理されるというルールを作成します）。 1つを除くすべてのコンソールグラフィックカードは、このように機能します。これにより、余分なデータをキャッシュしたり、近くで追加のテストを行ったりする必要がなくなります。 このソリューションは、カバレッジベースのソリューションよりも安定しており、より一般的で一貫しています。
アルゴリズムは元のコードとまったく同じで、コードが少し少なく、サンプルが少し多くなっています。したがって、カバレッジベースのアルゴリズムと同じかそれ以上ではありません。これは、グラフィックスカードだけでなく、他のほとんどすべての信号処理分野で古くからこのような方法を使用してきたためです。
この方法には欠点がありますか？まあ、単純な仮定をすると、少し遅くなります。理論的には、カバレッジラスタライザよりも速い漸近的な振る舞いをします。レイトレーサーのように、典型的なシーンではまだ同等です。また、畳み込みベースのエフェクトの使用を実装するのがより困難になる可能性があります。
スーパーサンプリングは、単純に行うと計算コストが高くなります。たとえば、ディスプレイのピクセルサイズの半分を使用する場合、メモリとバンド幅の4倍が必要になるためです。 Wikipedia はこれに言及し、可能な解決策として適応型スーパーサンプリングも挙げています。しかし、それによってアルゴリズムははるかに洗練され、複雑になり、実装が困難になっています。
そして、それがあなたが探している理由だと思います：多くのメモリと実行時間を必要としないアルゴリズムが必要な場合、物事は素朴な「透明性」アプローチよりもはるかに複雑になっています。
スーパーサンプリングは、一般に問題を解決しません。単に目立たなくするだけです。ピクセルが半分のサイズの場合、問題は半分ほど顕著になりますが、なくなることはありません。
これらのデザインの背後にあるアーキテクチャ上のポイントは、「render triangle ABC」コマンドに明確な意味を持たせたいということです。描画コマンドのコレクションの一部と見なされる場合を除いて、あいまいにならないようにします。たとえば、「レンダートライアングルBCD」もコレクションにある場合は1つの意味を持ち（同じまたは異なる色）、別の場合はそうではありません。
たとえば、1,000個の三角形を考えると、ABCと1つの辺または1つの辺の一部を共有するすべての三角形を見つけることは、計算上重いです（1000回再実行する必要があることを思い出してください）。他にも多くの実用的な問題があります。特に、新しい追加のリクエストのために再評価する必要がある場合に備えて、元のレンダリングリクエストは、かなり前に描画された場合でも、保持する必要があります。
結論として、完全に一貫したソリューションは実用的ではありません。疑問が残っています。可能な場合は、現在の状況を改善しようとする必要がありますか？一般的に、その質問に対する答えはNo。です。モデル自体に図示した制限がある場合でも、モデルの完全に一貫した実装は常に優れています。代替手段は、特定のケースでこれら2つのうちどちらが成り立つかをプログラマーが知る方法がない、場合によってはうまくいく場合もあれば、そうでない場合もあります。さらに、プログラマーが行った小さな変更の結果として、またはプログラマーの制御外の変更の結果としても、「より良い」から「より良くしない」にジャンプする可能性があります。プログラミングのコンテキストでの予測可能性は、時折の正確さよりもはるかに優れています。