レンダリング出力を単体テストするにはどうすればよいですか?


19

最近、テスト駆動開発(TDD)を採用していますが、開発成果とコードベースの復元力に素晴らしい影響を与えました。このアプローチをOpenGLで行うレンダリング作業の一部に拡張したいと思いますが、これに対する良いアプローチを見つけることができませんでした。

具体的な例から始めて、どの種類のことをテストしたいかを理解します。ある軸を中心に回転する単位立方体を作成し、いくつかのフレームで各フレームが正しくレンダリングされるようにしたいとしましょう。

自動テストケースを作成するにはどうすればよいですか?できれば、キューブをレンダリングするコードを書く前にテストケースを書くことさえできます(通常のTDDの慣例に従って)。とりわけ、キューブのサイズ、位置、および向きがレンダリングされた各フレームで修正します。シェーダーのライティング方程式が各フレームで正しいことを確認したい場合もあります。

私が出会ったこれに対する唯一のリモートで有用なアプローチは、レンダリングされた出力を参照出力と比較することです。これは一般にTDDの実践を排除し、非常に面倒です。

他の必要な要件については進めることができますが、既にリストした要件は手の届かないところにあると思います。


3
ここでの問題は、テストケースが適切な出力によって決定されることです。しかし、その出力にバグがある場合(誤検知)はどうなりますか?どちらにしても、最初にワイヤーフレームをチェックすることから始めます。次に、前方にレンダリングされたシーンに移動し、最終的に延期します(使用する場合)。画像全体をXORして、すばやく比較することができます(完全に黒のパス)。GPUは、TDDを適用するには本当に悪い領域です。しかし、あなたが賢い何かを思いついたら、私は知りたいです。
ジョナサンディキンソン

希望する答えが正確に得られないのではないかと疑っていますが、まだ良いアイデアを期待しています。ブラックパスについての良い考え。深度バッファのテストも役立つ場合があります。
ノートルシュ


@Adam共有してくれてありがとう。残念ながら、それの途中モバイルゲームに取り組んで私のようなインディーズのための手の届かないところには:)また、私の基本的な要件のほとんどを失敗しました。
-notlesh

@Adam、あなたは間違いなくそのリンクに「答える」べきです。まったく小説。
ジョナサンディキンソン

回答:


8

これは、承認テストフレームワークの適切なアプリケーションまたはそれに似たもののようです。

コメントに記載されているように、間違った出力を承認した場合、誤検出の問題が引き続き発生しますが、これにより出力が大幅に変更されたときに通知されます。

あなたはOpenGLを使用しているので、承認は直接あなたのために機能しないと仮定していますが、アイデアは正しいです。ファイルのハッシュを確認し、異なる場合は、適切な差分ビューア(画像差分プログラムなど)で失敗を表示します。新しいバージョンを承認する場合は、「承認済み」ファイルを更新して新しい結果に一致させます。


それは面白いツールです。上記のコメントのAdamのリンクにあるテストファームのようなものを取り上げ、このような統合された承認メカニズムを適用した場合、オーバーヘッドがかなり低いものにアプローチし始めるでしょう。共有してくれてありがとう!
-notlesh

承認テストは自動テストではありません。
zwcloud

@zwcloud:どういう意味ですか?他のテストと同じように、作成されると自動化されます。最初の承認がオーサリングプロセスの一部であるというだけです。
ジョンギーツェン

@JohnGietzen私はあなたの答えからそれを理解できませんでした。承認テストのアイデアをより明確に明確にする必要があると思います。回答が更新されたら、ダウン票を削除します。
zwcloud

6

私はゲームビジネスには興味がないので、愚かで素朴な認識を抱いてください。

私にとっては、完全にレンダリングされた画像を比較筆記テストは、実際にはありませんユニットテストが、完全統合すべてが成功したテスト実行のための作業の罰金に持っているので、テスト。

すべてが正常であることを確認できる中間層はどうですか?私の頭に浮かぶ2つのことがあります:

  1. 直接描画しないで、途中でレンダリング呼び出しに変わるコマンドストリームを発行します。コマンドストリームの正確性を確認できます。これには、エンドツーエンドのテストではありませんが、あなたがしたいユニットテストではなく、完全な統合テストを。

  2. これは実際には1のバリエーションです。OpenGLをラップし、すべての呼び出しをキャッチし、これを本当にテストしたいものに取り除き、出力がまだ一致するかどうかを確認します。OpenGLラッパーは、適切に設定されていればチェック自体を実行でき、モックになります。


3

問題は、ビット単位で正確な画像を出力するために3Dエンジンが必要ないことです。それによって引き起こされるアーティファクトが視聴者に見えない限り、多少の余裕は許容されます。テクスチャが予想より1%暗いことは通常、深刻な問題ではありません...通常は。状況によっては、視覚的なアーチファクトになる場合があります。そして、それが問題です。自動テストでは、どのアーティファクトが人間の視聴者に気付かれ、どのアーティファクトが気付かないかを判断するのは困難です。それでも、非常に単純なジオメトリで使用される場合、自動テストは単純な健全性チェックに使用できます。

できることは、いくつかの単純なシーンをレンダリングしてから、生成されたイメージを参照レンダリングと比較することです。その参照レンダリングは、別のグラフィックエンジンから取得することも、同じエンジンからの以前のスクリーンショットにすることもできます(回帰テスト)。

グラフィックエンジンの変更後に一部のテストが失敗した場合、ヒューマンテスターは出力を参照画像と比較し、新しい出力が以前と同じように(またはさらに良い)見えるかどうかを判断する必要があります。その場合は、テストを変更して、新しく改善された出力と比較する必要があります。

自動的に確認できるもう1つのことは、パフォーマンス要件です。そのような要件の1つは、自己実行デモ(ゲームの実際のシーケンスをシミュレートする)中に、テストシステムでフレームレートが40 Fpsを下回ってはならないことです。これは自動的にテストできるものです。テストできないのは、レンダリングが満足できるものであるということです。しかし、このようなテストを使用して、開発者が見た目は優れているが、発売後数年が経過するまで手頃な価格のシステムで正常に動作しないゲームを開発できないようにできます(hello Crytek)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.