14년 전 글이 아직도 소환되는 이유
게임 그래픽스 쪽에는 시간이 지나도 계속 회자되는 고전 글들이 있어요. stb 라이브러리(C 헤더 파일 하나로 끝나는 이미지 로더로 유명하죠)의 저자 Sean Barrett이 2012년에 쓴 “Corners Don't Look Like That”도 그중 하나인데요. 제목 그대로 “현실의 모서리는 그렇게 생기지 않았다”며, 당시 거의 모든 게임이 쓰던 SSAO라는 기법이 물리적으로 얼마나 틀렸는지를 실제 사진과 비교하며 조목조목 짚은 글이에요.
SSAO가 뭐냐면
먼저 앰비언트 오클루전(Ambient Occlusion, AO)부터 설명할게요. 현실에서 빛은 사방에서 튕겨 들어오는데, 구석진 곳일수록 주변 지형에 가려서 빛이 덜 도달해요. 그래서 방구석이나 가구 틈새가 어둑하게 보이는 건데, 이 “가려진 정도”를 계산해서 어둡게 칠해주는 게 AO예요.
문제는 이걸 제대로 계산하려면 장면 전체의 기하 정보를 다 뒤져야 해서 실시간 게임에서는 너무 비싸다는 거예요. 그래서 2007년 크라이텍이 크라이시스에서 SSAO(Screen-Space Ambient Occlusion)라는 꼼수를 선보였어요. 이게 뭐냐면, 장면 전체 대신 지금 화면에 그려진 깊이 버퍼(각 픽셀이 카메라에서 얼마나 먼지를 담은 이미지예요)만 보고, 각 픽셀 주변을 샘플링해서 “주변에 튀어나온 게 많으면 어둡게” 칠하는 근사 기법이에요. 화면에 보이는 정보만 쓰니까 엄청 싸고, 그럴싸한 음영이 거의 공짜로 생기니 순식간에 업계 표준이 됐죠.
그런데 현실은 그렇게 안 보인다는 거예요
Barrett의 지적은 간단하면서 뼈아파요. 실제 방 사진을 찍어서 보면, 벽과 벽이 만나는 모서리가 SSAO 결과물처럼 균일하게 어둡지 않다는 거예요. 현실의 빛은 벽에 맞고 튕겨서(간접광, bounce light라고 해요) 구석까지 꽤 밝게 채워주거든요. 흰 벽으로 된 방의 모서리는 오히려 부드럽고 밝게 이어지는 경우가 많아요. 그런데 SSAO는 기하학적으로 오목하기만 하면 무조건 검게 칠해버리니, 모든 모서리에 때가 낀 것처럼 어두운 줄이 생기고, 물체 주변에는 실존하지 않는 검은 후광(halo)이 둘러져요. “그럴싸해 보이는 것”과 “물리적으로 맞는 것”이 완전히 다른 이야기라는 거죠.
더 근본적인 문제는 화면 공간 기법의 태생적 한계예요. 화면에 안 보이는 지형은 계산에서 빠지니까, 카메라를 살짝만 돌려도 음영이 스멀스멀 변해요. 없던 그림자가 생기고 있던 그림자가 사라지는, 현실에서는 있을 수 없는 일이 벌어지는 거예요.
이 비판, 그 후에 어떻게 됐냐면
업계도 이 한계를 알고 있어서 개선의 계보가 계속 이어졌어요. HBAO, GTAO처럼 수평선 기반으로 좀 더 물리에 가깝게 근사하는 개선판이 나왔고, 하드웨어 레이트레이싱 시대가 열리면서 화면 밖 기하까지 실제 광선으로 검사하는 RTAO가 등장했어요. 요즘 언리얼 엔진의 루멘(Lumen) 같은 실시간 전역 조명(global illumination) 시스템은 간접광 자체를 계산해버리니까, AO라는 땜질이 점점 필요 없어지는 방향으로 가고 있고요. 결국 Barrett이 짚은 “간접광을 무시한 근사”라는 병의 뿌리를 업계가 14년에 걸쳐 치료해온 셈이에요.
그래픽스 안 하는 개발자에게도 남는 것
이 글이 오래 사랑받는 진짜 이유는 태도에 있다고 봐요. 업계 전체가 표준처럼 쓰는 기법이라도 “그런데 이거 정답(ground truth)이랑 비교해봤어?”라고 묻는 태도요. 우리 일에서도 캐시 전략이든 추천 알고리즘이든, 근사치를 쓰면서 그게 근사라는 사실 자체를 잊어버리는 경우가 많거든요. 근사는 죄가 아니지만, 무엇을 버리고 얻은 근사인지 모른 채 쓰는 건 문제라는 거죠.
정리하면
SSAO는 싸고 그럴싸하지만 현실의 빛과는 다르게 생겼고, 그 지적은 14년에 걸쳐 레이트레이싱과 실시간 전역 조명으로 응답받고 있어요. 여러분이 매일 쓰는 기법 중에, “다들 쓰니까” 쓰고 있지만 정답과 비교해본 적 없는 근사는 뭐가 있을까요?
🔗 출처: Hacker News