렌더링 테스트를 단위 테스트하려면 어떻게해야합니까?

최근에 TDD (Test-Driven Development)를 채택했으며 개발 결과 및 코드베이스의 복원력에 큰 영향을 미쳤습니다. 이 접근법을 OpenGL에서하는 일부 렌더링 작업으로 확장하고 싶지만 이에 대한 좋은 접근 방법을 찾지 못했습니다.

구체적인 예부터 시작해서 어떤 종류의 테스트를 원하는지 알 수 있습니다. 축을 중심으로 회전하는 단위 큐브를 만들고 프레임 수에 따라 각 프레임이 올바르게 렌더링되도록하려고합니다.

이를 위해 자동 테스트 사례를 어떻게 만들 수 있습니까? 큐브를 렌더링하는 코드를 작성하기 전에 (일반적인 TDD 사례에 따라) 테스트 사례를 작성할 수도 있습니다. 다른 많은 것들 중에서 큐브의 크기, 위치 및 방향이 올바른지 확인하고 싶습니다. 렌더링 된 각 프레임에서 수정하십시오. 셰이더의 조명 방정식이 각 프레임에서 올바른지 확인하고 싶을 수도 있습니다.

내가 겪었던 이것에 대한 원격으로 유용한 유일한 접근 방법은 렌더링 된 출력을 참조 출력과 비교하는 것입니다.

다른 원하는 요구 사항에 대해서는 계속 진행할 수 있지만 이미 나열된 요구 사항에 도달 할 수없는 것 같습니다.

— 노틀
소스

여기서 전체 문제는 테스트 케이스가 좋은 결과에 의해 결정된다는 것입니다. 그러나 그 출력이 버그 (거짓 긍정적)이면 어떻게됩니까? 어느 쪽이든 먼저 와이어 프레임을 확인하여 시작합니다. 그런 다음 앞으로 렌더링 된 장면으로 이동하고 마지막으로 연기합니다 (사용하는 경우). 전체 이미지를 XOR하여 빠른 비교 (전체적으로 검은 색 패스)를 만들 수 있습니다. GPU는 실제로 TDD를 적용하기에 나쁜 영역입니다. 그러나 당신이 똑똑한 것을 생각해 내면 알고 싶습니다.

— Jonathan Dickinson

나는 내가 원하는 대답을 정확히 얻지 못할 것으로 생각하지만 여전히 좋은 아이디어가 있기를 바랍니다. 블랙 패스에 대한 좋은 생각. 깊이 버퍼 테스트도 도움이 될 수 있습니다.

— notlesh

aras-p.info/blog/2007/07/31/testing-graphics-code

— Adam

@Adam 공유해 주셔서 감사합니다. 불행하게도, 그것의 방법으로 모바일 게임에 작업 나 같은 인디의 손이 닿지은 : 그것은 또한 내 기본적인 요구 사항의 대부분을 실패합니다.

— notlesh

@Adam 당신은 분명히 그 링크를 '답변'해야합니다. 아주 신기하다.

— Jonathan Dickinson

답변:

이것은 승인 테스트 프레임 워크 의 적절한 적용 또는 이와 유사한 것 같습니다.

의견에 명시된 바와 같이, 잘못된 출력을 승인하는 경우 여전히 잘못된 긍정 문제가 발생하지만 출력이 크게 변경되면 LEAST에서 알려줍니다.

OpenGL을 사용하고 있기 때문에 승인이 직접 적용되지는 않지만 아이디어는 건전하다고 가정합니다. 파일 해시를 확인하고 다른 경우 이미지 diff 프로그램과 같은 적절한 diff 뷰어에서 실패를 표시하십시오. 새 버전을 승인 한 경우 새 결과와 일치하도록 "승인 된"파일을 업데이트하십시오.

— 존 기첸
소스

흥미로운 도구입니다. 위의 주석에서 Adam의 링크에서 테스트 팜과 같은 것을 가져 와서 이와 같은 통합 승인 메커니즘을 적용하면 아마도 오버 헤드가 적은 것에 접근하기 시작할 것입니다. 공유해 주셔서 감사합니다!

— notlesh

승인 테스트는 자동 테스트가 아닙니다.

— zwcloud

@zwcloud : 무슨 뜻인가요? 테스트와 마찬가지로 작성되면 자동화됩니다. 첫 번째 승인은 제작 과정의 일부일뿐입니다.

— John Gietzen

@ JohnGietzen 나는 당신의 대답에서 그것을 이해하지 못했습니다. 승인 테스트에 대한 아이디어를 보다 명확하게 설명해야한다고 생각합니다 . 답변이 업데이트되면 downvote를 제거합니다.

— zwcloud 2

나는 게임 사업에 종사하지 않으므로 잠재적으로 어리 석고 순진한 인식을 가지십시오.

필자는 완전히 렌더링 된 이미지를 비교하는 테스트를 작성하는 것이 실제로 단위 테스트가 아니라 전체 통합 테스트입니다. 성공적인 테스트 실행을 위해서는 모든 것이 제대로 작동하기 때문입니다.

모든 것이 괜찮은지 확인할 수있는 중간 계층은 어떻습니까? 내 마음에 오는 두 가지가 있습니다.

직접 그리지 말고 렌더링 호출로 전환 되는 명령 스트림 을 발행하십시오 . 명령 스트림의 정확성을 검사 할 수 있습니다. 이것은 엔드-투-엔드 테스트는 아니지만 완전한 통합 테스트가 아닌 단위 테스트 를 원합니다 .
이것은 실제로 1에 대한 변형입니다. OpenGL을 래핑하고, 모든 호출을 잡아 내고, 실제로 테스트하려는 것으로 스트립하고 출력이 여전히 일치하는지 확인하십시오. OpenGL 래퍼는 올바르게 구성된 경우 자체 검사를 수행하고 모의 객체 로 바꿉니다 .

— 스테판 핸케
소스

문제는 3D 엔진이 비트 단위로 정확한 이미지를 출력 할 필요가 없다는 것입니다. 일부 여정은 그로 인한 인공물이 시청자에게 보이지 않는 한 견딜 수 있습니다. 예상보다 1 % 어두워지는 텍스처는 일반적으로 심각한 문제가 아닙니다. 어떤 조건에서는 시각적 인 인공물 일 수 있습니다. 그리고 그것이 문제입니다 : 인간이 보는 인공물과 그렇지 않은 인공물을 자동 테스트로 판단하기는 어렵습니다. 그럼에도 불구하고 자동화 된 테스트는 매우 간단한 지오메트리에서 사용될 때 간단한 위생 검사에 사용될 수 있습니다.

당신이 할 수있는 일은 간단한 장면을 렌더링 한 다음 생성 된 이미지를 참조 렌더링과 비교하는 것입니다. 이 참조 렌더링은 다른 그래픽 엔진에서 나왔거나 동일한 엔진에서 나온 초기 스크린 샷일 수 있습니다 (회귀 테스트).

그래픽 엔진으로 변경 한 후 일부 테스트가 실패하면 사람의 테스터는 출력을 참조 이미지와 비교하여 새 출력이 이전과 마찬가지로 좋아 보이는지 스스로 판단해야합니다. 이 경우 새로운 개선 된 출력과 비교하여 테스트를 변경해야합니다.

자동으로 확인할 수있는 또 다른 사항은 성능 요구 사항입니다. 이러한 요구 사항 중 하나는 자체 실행 데모 (게임에서 실제 시퀀스 시뮬레이션) 중에 프레임 속도가 테스트 시스템에서 40Fps 아래로 떨어지지 않아야한다는 것입니다. 이것은 자동으로 테스트 할 수있는 것입니다. 테스트 할 수없는 것은 렌더링이 만족 스럽다는 것입니다. 그러나 이러한 테스트를 사용하여 개발자가 멋진 것처럼 보이지만 출시 후 몇 년이 지나도 저렴한 시스템에서 제대로 실행되지 않는 게임 (hello Crytek)을 개발하지 못하게 할 수 있습니다.

— 필립
소스