많은 일반적인 AAA 타이틀 (특히 소스 엔진 게임)에서 플레이어가 경계를 벗어 났거나지도 아래에서 클리핑하지 않는 등의 범주가 지정되지 않은 영역에 도달 한 경우 화면에 이상한 효과가 발생합니다 (버퍼 찢기?).
시스템이 멈추는 동안 Windows XP가 드래그되는 창 뒤에 남겨 둘 수있는 창의 흔적과 유사하다고 설명 할 수 있습니다.
화면을 새로 고칠 때 개발자가 색상 버퍼를 지우지 않는다고 가정 할 수 있습니까?
그 맞습니까? 그렇다면 왜 그렇습니까?
답변:
옛날 옛적에 색상과 깊이 버퍼를 지우는 데 실제로 시간이 걸렸습니다. 명확하게하는 것은 그래픽 카드가 프레임 버퍼의 모든 픽셀을 걸어서 값을 써야한다는 것을 의미했습니다.
이 때문에 게임 개발자는 모든 픽셀을 다시 렌더링한다고 가정하는 것이 더 효율적이라는 것을 알았습니다. 그들은 이것을하기위한 많은 기술을 개발했습니다.
컬러 버퍼는 무시하기 가장 쉬운 방법입니다. 깊이 버퍼는 이전 데이터로 오염되기 때문에 덜 쉽습니다. 그래서 그들이 한 일은 간단했습니다.
프레임 0에서 glDepthRange(또는 D3D와 동등한) (0, 0.5)로 렌더링 하고 glDepthFuncof GL_LESS(또는 GL_LEQUAL)를 사용합니다. 이는 깊이 버퍼에서 얻을 수있는 가장 먼 깊이 값이 0.5임을 의미합니다. 따라서 프레임 0 끝의 깊이 버퍼에서 가장 큰 값은 0.5입니다 (모든 픽셀에 쓴 것으로 가정).
프레임 1에서는 깊이 범위를 (1, 0.5)로 변경합니다. 이 경우 근거리 값이 원거리보다 큽니다 . 그러나 깊이 기능을 GL_GREATER(또는 GL_GEQUAL) 로 변경 하여 깊이 테스트의 의미를 반대로합니다. 깊이 버퍼에서 가장 큰 값은 0.5이므로 작성하는 모든 값이 이보다 큽니다 . 깊이 테스트가 역전되었으므로, 이는 프레임 0에 기록 된 것이 프레임 1에 기록 될 수있는 것보다 멀리 떨어져 있음을 의미합니다. 프레임 1의 끝 에서 깊이 버퍼 의 가장 작은 값은 이제 0.5입니다.
그리고 그들은 반복합니다.
2003 년경 이후로 만들어진 모든 하드웨어에서 이것은 더 이상 최적화가 아닙니다. 실제로, 그것은 부정적인 최적화 입니다. 깊이 버퍼를 지우면 실제로 하드웨어가 더 빨라 집니다. 아뇨
기본적으로 버퍼를 지우면 실제로 아무것도 쓰지 않습니다. 그것들은 GPU의 캐시에 약간의 비트를 저장하여 시스템이 어떤 색 / 깊이를 지웠는 지 알려줍니다. 시스템이 프레임 버퍼의 캐시 라인에 쓰려고 할 때, 그것이 명확한 색 / 깊이 값의 빈 필드임을 이미 알고 있기 때문에 거기에있는 것을 읽는 것을 귀찮게하지 않습니다. 존재하는 것과 혼합하거나 깊이 테스트를 다시 시도하면 다시 읽을 필요가 없습니다. 혼합 / 테스트와 함께 /에 대해 어떤 가치가 있는지 알고 있습니다.
따라서 삭제 후 각 캐시 라인에서 수행하는 모든 첫 번째 읽기 / 수정 / 쓰기는 기본적으로 쓰기입니다. 그것은이다 무료 .
또한 들쭉날쭉 한 깊이 버퍼를 사용하면 하드웨어의 Hyper-Z / Hierarchial-Z / Z- 컬링 최적화에 맞출 수 있습니다. 그렇습니다. 디테일을 추가하면 장면이 결국 장면과 맞 닿게됩니다. 그러나 뎁스 버퍼가 이전 렌더링에서 들쭉날쭉하면 배경 객체가 배경에 있어도 Z- 컬링 기술의 효율성에 영향을 줄 수 있습니다. 그리고 그것은 성능을 향상시키지 않을 것입니다.
따라서 현대 게임에서이 깊이 반전 기술 을 사용해서는 안됩니다 .
참고 : Jari는 (대부분의 모바일 플랫폼에서 볼 수있는) 타일 기반 렌더링 아키텍처를 잘 보여줍니다. 깊이를 지우지 않으면 불쾌감을 줄 수 있습니다.
예, 백 버퍼가 지워지지 않은 것이 맞습니다.
이유는 (주로) 각 프레임의 반대 방향으로 깊이 값을 핑퐁하는 커스텀 셰이더를 사용하는 것이 더 빠르기 때문에 게임이 항상 화면의 모든 픽셀을 렌더링한다는 사실에 의존합니다.
따라서 비용이 들지 않으면 프레임 당 하나의 버퍼 공간을 절약 할 수 있습니다.