Babytook's T Blog

아래에서 퍼옴

http://chulin28ho.egloos.com/5272883#5272883_1

아이쿠 예예. 좀 어려웠죠.
저번 시간이 살짝쿵 어려웠을 겁니다.
알파 채널의 '개념' 은 익숙해지지 않으면 잘 안 생기는 개념이라, 그걸 응용까지 하려면 확실히 이해하기 힘들죠.

자아 저번 시간에 이어서, 이번에도 개악마 알파 블렌딩과 싸우기 위한 기술을 알아보는 시간입니다.
저번 시간에는 알파 블렌딩과 테스팅을 적절히 사용하여 개악마 알파 블렌딩의 횡포를 줄이는 법에 대해 알아보았습니다
이번엔 좀 다른 방법으로 개악마 알파 블렌딩을 잡으러 레이드 뛰어 보기로 하죠.

자 , 1강과 2강에서의 Z 값 Read / Write에 대해 기억 나십니까?

이런 그림이 있으면 그려지기 전 자신의 Z 값을 보고, 자신보다 앞에 있는것이 있는지를 읽는(Read) 다고 했지요.

그리고 자신보다 앞에 있는게 없어지면 자신의 Z 값을 다시 쓴다(Write) 고 했었습니다.

네에 이것은 확실한 렌더링의 기본 신조. 꼭 지켜야 하는 내용이었습니다. 안지키면 안되는 법전 같은 것이었지요.

그렇지만, 이것을 조작할 수 있지 않을까요? 뭔가, 조작하면 뭔가, 뭔진 잘 모르겠지만,
하여간 뭔가 일어날 수 있지 않을까요?
뭔가 , 뭔가 말입니다.
Z Read와 Z Write을 맘대로 조작해 보잔 말입니다.

1.     Z Read = Off     Z  Write = On

자아. 만약 오브젝트를 찍을 때, Z Read를 안하고 Z Write를 한다면 무슨 일이 일어납니까?
으으음.. 머리가 좀 아프지만, 고민해 보자면...

Z Read는 왜 하는 것입니까? 자신의 앞쪽에 누가 있는게 아닐까 - 라고 검사하는 짓을 안한다는 말이지요?
즉 '나는 내 앞에 누가 있건 그냥 그려 버리겠다' 라는 겁니다 !

그러면서 Z Write는 하니까, '그대신 내 뒤의 놈들은 내 Z 값을 인식해서 내 앞에 오는 일이 없도록 하여라' 라고 하는 것입니다.
우왕 이기적이네요. 나는 맘대로 그리겠지만 너는 그러지 말아라 라고용?
(하지만 뭐 자신과 똑같은 Z 옵션을 가진 놈이 뒤에 오면 똑같이 무시되겠지만)

자 그림으로 찬찬히 풀어보도록 하죠.

오랫만에 봅니다. 지금 저 plan이 그려졌습니다. plan은 4의 깊이에 있고 Z read와 Z write 를 했습니다. 그래서 화면에 씌여진 Z값은 현재 4의 상태입니다.

 

그리고 주전자가 이렇게 나중에 그려졌습니다. 분명히 주전자는 뒤에 있습니다. Z 값으로 따지면 말이죠.
그렇지만 이 주전자는 Z Read가 Off 되어 있습니다. 즉 Z Read 과정을 하지 않도록 되어 있습니다.
그럼 나중에 그려진 이 주전자는, 그리긴 그려야 겠고, 기존에 있는 Z 값을 읽지 않기 때문에, 아무 생각없이 그려버리게 됩니다.
마치 저 plan 앞에 있는 것 처럼 말이죠.

 

즉 이렇게 보이게 됩니다. 분명히 주전자는 뒤에 있는데도 불구하고 앞에 보이게 되는 기현상이 일어나게 됩니다.

이번엔 그 상태에서 Z 값을 Write를 합니다.하지만 화면이 비어있으면 모를까 지금처럼 자신보다 더 앞의 Z 값이 잔뜩 있는 이 상황에서는 어차피 씌여지지 않으니 이 과정은 무의미합니다.
즉 Z Read를 Off 해 버리면, 앞에 뭐가 있건 무조건 자기가 그릴 타이밍에 그려 버립니다.
무식한 녀석이지요.

특별히 이 녀석을 동영상으로 보면 다음과 같습니다.

그렇지만 이 녀석이 앞에 있으면 문제는 달라지는데, 이 녀석 뒤쪽에 일반적인 오브젝트가 그려지면,
 

 

이번엔 또 그려지는 순서와는 상관없이 아주 정상적인 오브젝트처럼 앞뒤가 결정된다는 것입니다.
왜냐면 이녀석은 Z read는 안하지만 write는 해 놨기 때문이지요.

 

이런 무식한 녀석을 어디다 쓸 수 있을까요? 남들보다 무조건 앞에 그려버릴 일이 세상에 어디 있을까요? 그러면서 자기 Z 값은 쓰기 때문에, 자신보다 나중에 생기는 일반적인 오브젝트는 자신의 뒤로 가려져야만 합니다.


전혀 쓸모없을 것 같군요. 물론 좋은 점도 있습니다. 자신의 앞 쪽에 무슨 Z 값이 있건 없건 자신은 무조건 그려 버리기 때문에,
알파 블렌딩을 사용할 때 나오는 짤림 현상이 일어나지 않습니다.

 

이런 현상은 더이상 일어나지 않습니다

그래서 이펙트 담당자들이 이 기능을 쓰고자 하는 유혹을 자주 느낍니다. 이펙트만 놓고 뷰어에서 봤을 때, 짤림 현상이 없이 잘 나오거든요!!! 그래서 잘 되었구나.. 라고 생각한 채 게임에 넘기면, 이번엔 게임에서 이런 현상이 나타나게 됩니다.

 

네에. 기둥이나 다른 캐릭터, 건물 등을 뚫고 이펙트가 보이게 된다는 거지요. 위의 경우는 기둥을 뚫고 이펙트가 보이는 현상인데, 만약 기둥이 이펙트보다 나중에 그려졌다면 아무 문제가 없지만 '불투명한건 반투명보다 나중에 그린다' 는 원칙에 따르면 저렇게 보일 수 밖에 없는 것입니다. OTL
이펙트면 그나마 낫지요. 머리카락 같은거였다면 난리가 납니다. (얼굴을 뚫고 그려지는 머리카락들...)
네 실패입니다. 이 방법은 알파 블렌딩에 맞지 않습니다.


하지만 정말로 이 기능이 필요가 없느냐? 만약 이 기능을 쓴다면 이런 데 쓸 수 있을겁니다
바로 인터페이스!
인터페이스야말로 모든 게임의 오브젝트의 위에 그려져야만 하고, 그리는 순서를 바꿔줌에 따라 맨 앞에 나와야만 하는 것이므로, 이 옵션에 가장 잘 맞는 데이터입니다.
사실 뭐 게임에서는 굳이 Z 값을 이렇게 안해줘도 프로그래머들이 알아서 처리해 주곤 하지만 말이죠.

 

2.     Z Read = On     Z  Write = On

아... 이건 뭐 여태까지 5강동안 설명해 온 것이지 않습니까?
이게 기본이자 진리입니다. 알파 블렌딩이고 테스팅이고 불투명이고 사실은 이걸 써야만 합니다.
이게 안되니까 다른 짓을 하는 겁니다 지금. 하하하.

3.     Z Read = Off     Z  Write = Off

자, 둘 다 꺼버렸습니다 !! ㄷㄷㄷ
일단 슬쩍 생각해도 뭔가 정상적이지는 않을 것 같습니다.

차근차근 생각해 보지요. 뭔 일이 일어나겠습니까?
일단 Z read를 하지 않습니다. 즉. 1번과 같이 자신이 그릴땐 아주 소신있게 그려버리는 녀석입니다.
자신의 앞에 뭐가 있건 상관 안합니다.
"사나이 앞길을 막지 마라!" 이것이 Z read Off 입니다.

그런데 이번엔 Z write도 하지 않습니다! 이건 뭥미?
Read는 하지 않고 Write는 하면 인터페이스처럼 사용가능하다고 했습니다. 즉 자신의 뒤에 그려지는 녀석은 자신의 뒤에 가려집니다.
그렇지만 Write도 하지 않으면, 자신보다 나중에 그려지는 녀석이 Z read를 해 보니까, 자신의 앞에 아무것도 없다고 나오게 됩니다!!!! Z 값을 아무도 안 써 놨으니까요!!!!

즉 자신보다 늦게 그려지는 놈한테 덮여집니다!!! 아아 괴이합니다!!!!

다시 한 번 설명하지요.

 

이런 상태에서

 

이렇게 주전자를 나중에 그려도,

 

주전자가 앞에 그려진다는건 똑같습니다.

 

근데 이 주전자가 앞에 있는 상태에서,  나중에 뒤에 있는 공이 그려진다면?

 

그렇다면 나중에 그려지는 공은, Z 를 read하려고 시도하겠지만, 주전자가 Z 값을 Write 해 놓지 않았기 때문에
공 입장에서는 앞에 아무것도 없다고 인식하게 될 것입니다.
그러니 나중에 그려진 공이 기존의 주전자를 덮어버리겠지요.

아아 괴이합니다. 이거야말로 괴이합니다. 정말 쓸모가 없게 생겼군요.
생각하기도 복잡하고, 쓰기에도 애매한 놈이 됩니다. 이거 알파 블렌딩에 쓸 수 있는 녀석이 있긴 한 겁니까?


알파 블렌딩에 쓸 생각은 일단 접어둡시다. 그전에 이걸 쓸 데가 있기나 한지 궁금하군요.

말씀드리자면, 쓸 데는 거의 없지만 있기는 합니다.
바로 스카이박스 (또는 스카이돔) 입니다.

이 스카이 박스는, 보통 맨 처음에 그려집니다.
그리고 이 스카이 박스에 가려져서 보이지 않는 오브젝트 따위는 존재하지 않습니다.

즉 이 스카이 박스를 그릴 때에는 Z 값을 읽는 (read) 하는 행위가 무의미합니다. 오히려 쓸데없는 계산이 되어 버리기 때문에,
아예 read 안하는 것이 낫습니다.

또한 이 스카이 박스에 가려지는 오브젝트 따위는 없습니다. 무조건 맨 뒤에 그려져야 하는 거지요.
그러므로 괜한 z값 연산을 할 필요가 없는 관계로 쓰는(write) 하는 작업도 무의미합니다.

즉 꼭 그래야 한다기 보다 (Z read on Write on 해도 결과는 같거든요) '할 필요가 없는 연산을 줄여버린다' 라는 의미에서 쓸모가 있는 방법이라고 할 수 있습니다.
그렇다고는 해도 굉장히 마이너한 방법임에는 틀림이 없지만 말이죠 (...)


4.     Z Read = On     Z  Write = Off
이제 남은건 이것밖에 없습니다.
그래! 분명히 마지막에 남은 이것이 해답이라서 맨 마지막에 소개하는걸 꺼야!!!!
라고 생각하시는 분들 반드시 계시겠지요? 어디 한 번 봅시다. 정말 그런지 후후후.
 
아 그런데 이제 좀 퇴근해야겠군요. 이거 쓰는것도 꽤나 힘든 일이랍니다
다음 시간까지 Z read on , Write off 가 정말로 알파 블렌딩을 해결하는 해답이 될지 생각하는게 숙제입니다.

6부작에서 끝내려 했는데 너무 양이 많군요. 애석하게도 7부까지 가야만 하겠습니다.
쓰다보니 조금 지치네요. 읽으시는 분도 꽤 지치셨을 겁니다. 이게 한번에 쉽게 이해되는 개념은 아니거든요.

아래에서 퍼옴

http://chulin28ho.egloos.com/5271687

5부가 밝았습니다. 자잔~ 이번 시간에 과연 끝낼 수 있을까요?
크흑 이거말고 지금 강연준비도 두어 개 할 게 있어서 이럴 시간이 아닌데 성격상 벌여 놓은 일이 있음 안절부절하는 성격이라...

자아 각설하고, 시작해 보도록 하지요.

지난 4강의 내용에 따르면, 정말로 알파 블렌딩은 해결방법이 없는 개악마 였습니다.
알파 블렌딩을 사용하기만 하면 그냥 찍지도 못하고,
따로 알파 블렌딩인 것들만 모으는 작업을 해야지 않나, 그리고 그걸 나중에 뒤에서부터 찍어주는 작업을 해야하고,
그러다보니 가려지면 안그려도 된다라는 그런 좋은 최적화를 하나도 사용 못하게 됩니다. (물론 불투명한 물체에 가려지는건 안그리긴 합니다)

솔직히 시간과 자원이 엄청 낭비되는 작업이지요. 그런데 그것도 모자라서 그나마 완벽하게 나오지도 않아서, 물체를 조각내줘야 한다니!!! 그래도 완벽히 해결은 불가!!! 미칠 지경이지요. 별 방법을 다 쓰고 시스템 자원을 낭비하고 있는데도 완벽히 해결 방법이 없다는 건 정말 짜증나는 일입니다.

그래서 사용하는 방법은 '해결' 쪽이 아닌 '완화' 쪽이라는 것이 지난번까지의 얘기였고,
그 '완화' 를 눈속임 잘 하기 위해 그래픽 디자이너의 잔기술 - 그래픽 디자이너들이 또 그런 눈속임 기술은 천재적으로 뛰어나지요 - 을 적극적으로 이용해야 한다는 것이었습니다.

오늘 얘기할 내용은 그 '완화' 의 기법에 대해서입니다.
잘 그려서 눈속임하는거야 이미 이전에 다 말했고... 그 부분은 정말로 그래픽 디자이너의 노하우에 달린것도 없지 않지요.

그치만 어쨌건 이런 알파 블렌딩의 문제점을 '완화' 시킬 수 있는 방법도 하나는 아닙니다.
몇 가지의 선택지가 있다는 것은 고마운 일이지요.
그리고 그 중 상당히 많이 쓰이는 선택지, '알파 테스팅(Alpha Testing)' 이 있습니다.

알파 테스팅과 알파 블렌딩은 사실 형제사이와 같습니다.
둘다 알파채널을 이용해서 투명한 부분을 뚫어 보여주는 기법이란 말이죠.

그치만 그 방법에는 근본적인 차이가 있습니다.

위 그림은 겜브리오 헬프에서 가지고 온 그림인데, 둘 다 같은 이미지입니다. 왼쪽 것은 알파 테스팅이고, 오른쪽것이 여태까지 얘기해 왔던 알파 블렌딩입니다.
그리고 저 나뭇잎 들의 피봇점은 중심에 있기 때문에, 알파 블렌딩을 사용했을 경우에는 오른쪽처럼 우선순위의 문제가 일어납니다.

왼쪽 것은 어떻게 보이시지요? 왼쪽 것은 뭔가 거칠게, 음... 그러니까 '안티알리아싱이 없는' 이미지처럼 보입니다. '도트가 튀어 보인다' 라고도 말씀하시지요.

자 이 이미지를 가지고 설명해 보겠습니다.
위 이미지의 알파 채널은 다음과 같습니다.

 

네에 부드러운 가장자리를 가지고 있군요. 이걸 알파 블렌딩 옵션으로 찍으면 어떻게 될까요? 가장자리의 부드러운 부분 말입니다.

 

이 부드러운 부분은, 나무가 찍힐 때, 뒤에 있는 이미지와 합쳐지게 될 겁니다.
알파 채널의 원리를 다들 아시니까 쉽게 이해하시겠지요. 그림으로 표현하면 다음과 같은 느낌.

 

뒤의 이미지와 알파 채널의 비율에 따라 부드럽게 섞인다. 네에. 이게 알파 블렌딩입니다.
즉 알파 블렌딩은, 사실 자신의 이미지 픽셀이 알파채널에 의해 안 보이더라도 다 찍기는 찍는겁니다. 자신이 0%로  찍을 뿐이죠.
그래서 자신이 보이지 않는 부분이라도 충실하게 Z 값은 Write 하고 있는 거지요.

그런데 이 옵션을 알파 테스팅으로 바꾸면, 이 이미지를 다르게 인식합니다. (이미지가 변하는건 아닌 겁니다)
만약 아래 이미지를 가진 나무를 알파 테스팅으로 바꾸고, 0~256 의 중간인 128로 그 수치를 맞췄다고 치면,  

 

이렇게 인식하게 됩니다. (이미지가 바뀌는게 아닙니다. 위 이미지를 아래처럼 인식한다는 뜻입니다)

 

원리를 설명하면, 알파 테스팅 (Alpha testing) 128이라 하면,
128 즉 50% 의 알파 채널 이하는 전부 알파가 없는 것으로 인식하고, 50% 이상의 알파 채널을 가진 것은 전부 알파가 있는 것으로 인식하겠다 - 라는 말입니다. 즉 흑백논리로 인식하겠다라는 것이지요. - 즉 128이라는 수치의 테스트에 통과한 것만 알파로 인정하겠다 라는 말에서 나온 말입니다.


이렇게 하면 뭐가 좋아지나요?

기존의 알파 블렌딩은 그 픽셀에 알파가 미세하게 들어 있어도 전부 계산하기 위해서, 전 픽셀을 모두 계산하고 앉아 있습니다. 아아~ 섬세하긴 하지만, Z 값은 제발 좀 안썼으면 좋겠는 부분도 전부 계산하고 있는거라고용.

그런데 이렇게 흑백논리로 인식해 버리면, 갑자기 뭔가 계산이 편해집니다. 알파가 있고 없고가 확실해 지니까요.
자아 이렇게 되면 기존의 불투명 오브젝트 처리하듯, 알파가 없는 부분은 Z도 안쓸 수 있게 됩니다.
그래서! 기존에 골머리 썩히던 알파 블렌딩의 앞뒤 판정이 모두 해결됩니다!!! 페르난도!!!!
....
하지만 좋아만 할 것은 아닙니다.

 

덕분에 알파 채널이 요따위로 들어가게 되거든요.

 

프리우스의 머리카락도 알파 테스팅을 사용하고 있는 것을 알고 있지요. 블렌딩을 쓰면 훨씬 자연스럽겠지만 테스팅을 써도 괜찮다면 써 주는게 낫습니다.

 

아이온도 잘 보시면 알파 테스팅을 적극적으로 사용하고 있습니다.

 

특히 많이 사용하는 곳은 나뭇잎이나 풀 등의 표현입니다. 이것들은 양이 많고 크기가 작기 때문에, 알파 테스팅으로 처리하는 경우가 일반적입니다. 이렇게 알파 테스팅은 잘만 쓰면 괜찮은 표현을 할 수 있습니다만,

속눈썹이나 머리카락 클로즈업 신이 자주 나온다면 고민해보는게 좋을 부분입니다. 속눈썹은 아무리 해도 알파 테스트로는 좀...
아예 모델링을 해버리고 말지...

 

그리고 또한 알파 테스팅을 사용 못하는 부분이 있습니다. 바로 이펙트 부분이지요.
이펙트는 알파 블렌딩만을 사용해야 합니다 OTL
또한 적절히 투명한 유리 효과나 비치는 옷을 표현할때에도 알파 테스팅은 사용할 수 없습니다.
자 여기까지 읽으셨으면 쉬어가는 문제하나. 만약 다음 그림처럼 알파 채널을 만들고

 

알파 '블렌딩' 옵션을 켠 직원이 있다면 어떻게 하시겠습니까?

............. 죽여야 합니다. 당신의 프로젝트를 망하게 하려고 낙하산타고 내려온 경쟁사의 첩자입니다
알파 채널 자체가 저 모양이면 품질은 알파 테스트 상태에 Z 버퍼 문제는 알파 블렌딩을 가진 괴물이 탄생하고 맙니다. ㄷㄷㄷ

어쨌건,
알파 테스팅은 알파 블렌딩의 단점을 극복하게 해줄 좋은 방법중 하나입니다.

보너스로 또 하나의 응용을 보여 드리지요.

바로 알파 블렌딩과 테스팅의 동시 응용과 고급 응용!!!


자아. 알파 채널이 있는 나무 이미지를 이렇게 배치하고,

 

알파 블렌딩은 사용하지 않고 알파 테스팅만 사용해 봅니다.
숫자는 0. 그야말로 외각을 최대한 살려서 (알파를 관대하게 test통과 시켜서) 출력해 내 주는거라, 외각이 지글지글 ... 원래 원한 면보다 크게 나옵니다.

 

그래서 50~150 정도 되는 영역을 쓰곤 하죠. 그렇다고 너무 줄여서 250까지 test를 빡세게 하면
역시나 원래 이미지와는 차이가 큰 앙상한 녀석이 나오게 되겠죠.

 

그래서 뭐 일반적인 방법은... 첫째로 나무 base을 만들 때 외각에 검은색을 채우지 말고 나무색과 비슷한 녹색을 채우는건 기본.
행여나 생기게될 '찌꺼기' 를 최대한 가리기 위해서지요. 뭐 이런건 그래픽 디자이너로써 기본이고..

어쨌건 평이하게 50 정도로 끊어보지요. 검은 찌꺼기가 좀 나왔지만 형태는 원한 정도대로랄까나.

 

그런데 여기서 다시 알파 블렌딩을 쓰는겁니다. 알파 테스팅과 동시에 말이죠.

그럼 이렇게 됩니다.

 

오오 뭔가 거친 듯 하면서 부드러운 외각을 가지게 되었습니다.

그리고 알파 블렌딩만 사용했을때 나오는 커다란 사각형의 짤림 현상이, 외각에 연하게 줄 이미지 정도로 줄었습니다.
그 이유는 일단 알파 테스팅을 거치면서 외각의 대부분이 알파를 통과하지 못하고 처리가 안 되었고,
이제 남은 영역에 한해서만 알파 블렌딩을 하기 때문에 그 영역이 대폭 줄게 된 것입니다. +_+

비교해 볼까요

 

좌측이 그냥 알파 블렌딩만 사용한 것이고, 우측이 알파 테스팅을 먼저 거친 다음 남은 부분으로 알파 블렌딩을 한 방법입니다.
만약 굳이 알파 블렌딩을 사용하겠다면, 우측 방법을 응용해 보는 것도 좋은 방법이겠지요?
이펙트도 이미지의 손상을 최소로 하기 위해 알파 테스팅을 5나 10 정도로 약하게 주고, 다시 알파 블렌딩을 처리하는 방법을 사용하면 앞뒤문제를 어느 정도 해결할 수도 있겠지요 +_+


이런 내용을 테스트 한 것이 겜브리오 메뉴얼에 잘 나와 있습니다.
저는 사실 오늘은 아래 사진 한 장을 설명한 것 뿐이네요.

 

자아. 이렇게 5강은 끝입니다. 알파 테스팅이라고 하는 멋진 녀석을 소개시켜 드려서 기쁘군요.
다음 시간에는 Z Read/Write 응용을 함 해볼까요?
... 문제는 그것도 한 강의 안에 끝날 수 있느냐는 건데 ... ㄷㄷㄷ 이쪽은 너무 큰 것들이 얽혀 있어서 설명하기가 쉽지 않네요. ㄷㄷㄷ

어쨌건 다음은 마지막시간 (이 되기를 기대하면서)
Z 버퍼의 Read / Write 개념 (6부, Z Read/Write) 편이 되겠습니다.

아래에서 퍼옴

http://chulin28ho.egloos.com/5270691

우하하 . 어느덧 4부입니다.
제길 이거 진짜 힘든 강의잖아 OTL

익숙해 지고 나니 별 게 아니긴 한데, 잘 설명하려니까 얽히고 설킨 것들이 너무 많습니다 OTL

어쨌건 지난줄거리 요약

- 불투명인 것들은 Z 버퍼만으로 앞뒤구별이 가능하니, 대충 찍어도 된다.
- 반투명인 것들이 끼어 버리면 문제가 되니, 불투명한 것 먼저 찍고 반투명한걸 나중에 모아서 찍는다.
- 반투명인 것들끼리도 먼저찍히냐 나중에 찍히냐에 따라 문제가 생기기 때문에 반투명한 것들은 순서를 판정해서 뒤에서부터 앞으로 찍어온다.

라는 것입니다.
자 그럼 이번 시간에는...

바로 그 마지막 방법. 반투명한 것들끼리 찍을때 뒤에서 부터 찍는다는 그것 말입니다.
그게 잘 될것 같지만, 생각만큼 잘 되지를 않는단 말입니다 (...)  

자아 예를 들어 봅시다.
아래의 모든 오브젝트는 이제부터 반투명이라고 생각하세요.

그리고 이제 격자 같은거 안그려도 앞뒤 판정은 하실 수 있으시겠죠?

 

네에 이건 뭐 쉽습니다. 당연히 앞에 있는 노란 공이 제일 나중에 그려지겠고,
맨 뒤에 있는 튜브가 제일 먼저 그려지겠죠 하하하.
뭐 이렇게 쉬운걸 문제라고..

하하하 아주 쉽네요

좋습니다. 잘 하셨습니다.
그런데 이 물체들이 누가 앞에 있고 누가 뒤에 있는지를 무엇을 기준으로 판단하는 것입니까?

모든 오브젝트에는 각자가 가지고 있는 피봇(pivot)이라 불리는 포인트가 있지요.
이 포인트와 카메라의 거리로 거리판정을 하는 겁니다. 과연. 뭐 그래픽 하시는 분들이라면 다들 알고 있는 내용.

 

그치만 말입니다. 그치만 말예요. 그렇지만 말입니다.

이게 이런 경우도 나온단 말이지요.

 

아래쪽에 넓은 판 하나가 생겼습니다. 주로 '반투명의 물' 을 만들때 사용되는 방식이지요.
자아 위의 그림처럼 반투명의 물과 오브젝트가 있다 칩시다.  그리고 이 반투명들은 모두 Z Read와 Write 를 하고 있습니다.  

카메라는 정직하지요... 반투명인 물체들이 모였으니까 , 뒤에서 부터.. 즉 "카메라로부터 피봇점이 먼 것부터" 그리기 시작합니다.

 

슬쩍 상식적으로 생각해 봅시다. 어떤게 가장 '카메라부터 멀리 있어서 제일 먼저 그려야 할 것' 인가요?

당연히 상식적으로 생각하면 5-4-3-2-1 순서입니다.
반투명인 물 (연두색이지만!) 이 가장 먼저 그려지고 그다음에 4-3-2-1 순으로 그려야 겠지요.

하지만 정말 컴퓨터도 그렇게 생각할까요?

자 언제나 공정하고 냉정한 그래픽연산장치님의 눈으로 쳐다봅시다.
위 그림에서 가장 먼 피봇 점은 5번인가요?
전혀 그렇지 않습니다. 카메라와 피봇 점만 냉정하게 따져보면 , 사실 가장 멀리 있는 것은 4번입니다! 
그리고 그 다음이 5번... 아니 3번인가요?

그다음은 2번, 1번. 이건 뭐 평이하네요.
자 이제  컴퓨터가 그리듯 카메라 뷰에서 그려봅시다.



먼저 가장 멀리 있다고 생각한 4번을 먼저 그립니다.

 

그 다음에 멀리 있다고 판단되었던 물을 그립니다.
그런데 물을 그리려다 보니, 이미 누군가가 물보다 앞쪽에 Z 값을 써 놓았습니다.
그렇습니다. 나뭇잎 4번입니다!! 4번은 피봇으로 따져보면 더 멀리 있지만, 픽셀로 따져보면 더 가까이 있는 것이니까요!!

아아아악 개악마 알파의 저주가 시작되었습니다.

 

게다가 여기서 끝난 것도 아닙니다. 3번과 5번처럼 거리가 애매한 녀석은, 프레임에 따라, 카메라 각도에 따라 서로 우선순위가 엎치락 뒤치락 합니다. 엔진의 거리버퍼가 정밀하지 못하면 더더욱 말입니다.
가끔 절묘하게 동일한 선상에 있다고 판단될때는 여지없이 깨지기도 합니다.
(아래의 그림이 현재 상태에서 정확하지는 않습니다. 보통 아래와 같이 깨지는 경우는 주로 두 평면이 서로 바짝 붙어 있을때입니다)

 

으아아아아악.

나머지 두 개는 문제가 없다고 해도 이미 저 두 잎이 다 망쳐 버렸습니다. 더 해봤자 희망이 없네요.

그렇습니다. 바로 아래와 같은 경우 발생입니다.
물도 반투명, 배에서 나오는 이펙트도 반투명이었습니다.
물의 plan은 꽤 크기 때문에, 카메라는 물보다 이펙트가 멀리 있다고 판단해 버린 것이었습니다 (!!)

이런 경우만 있으면 차라리 괜찮기나 하죠.

아래와 같은건 어쩔껍니까?

 

반투명 안에 반투명이 있습니다.
피봇축이 동일합니다. 어쩔까요 이거?

 

머리카락의 경우도 위험합니다. 저렇게 덮개 모양으로 만드는 데다가, 두꺼워 보이게 하기 위해 여러 겹을 겹치곤 합니다.
저런 머리카락 형태의 문제는, 머리카락의 앞이마 부분은 안쪽머리가 가장 뒷쪽이지만,
뒤통수 부분은 안쪽머리가 가장 앞쪽이라는 겁니다. 엉망이죠.
알파 블렌딩을 충분히 사용하면 저 머리카락은 차마 볼 수 없을만큼 엉망이 됩니다.
 

게다가 머리카락의 텍스쳐는 주로 끝부분이 부드럽게 빠지게 하기 위해 알파 블렌딩을 사용하기 때문에, 어쩔 수 없이 머리카락 전체는 반투명(알파 블렌딩) 을 사용할 수 밖에 없게 됩니다.
그래서 이 문제를 해결하기 위해 주로 쓰는 방법은, 알파 블렌딩을 사용하는 부분을 최소화 하는 겁니다.
아래 그림에서 보면, 머리카락이 제대로 나오지 않은 것을 알 수 있지만, 쉽게 눈치채지 못할 만큼의 면적으로 블렌딩을 했기 때문에 눈속임으로 넘어갈 수 있을 정도가 됩니다.

(좀 더 좋은 예제 있었는데.. 찾으면 업데이트 하겠습니다)

결론은, 실무에서 사용하면 뒤죽박죽이 될 수 밖에 없다는 겁니다.
그래픽 디자이너가 결벽증을 가지고 있는 친구가 아닌 담에야 피봇축을 일일히 가운데에 맞출리도 만무하고,
위와같이 오브젝트가 크거나 덮고 있는 형태면 방법도 없습니다.

네, 방법이 없습니다. 개악마 알파 블렌딩의 패악질을 이길 방법이 없습니다.

사실상 대부분의 게임들이 이런 문제로 골머리를 앓고 있습니다.
그리고 프로그램적으로 완벽히 해결하는 방법은 이제 없습니다.(DX11이 나오면 어찌 될까나..)
나머지는 이 단점을 가지고 어떻게 응용해 나가냐는 거지요.
그리고 그 모든 방법에는 장점이 있고 단점이 있기 때문에,
해결하는 방법은 여러 개이고 그 방법을 때에따라 적절히 섞어가면서 사용합니다.
여기서 그래픽 디자이너와 프로그래머와의 궁합이 얼마나 되느냐 - 커뮤니케이션이 잘 되느냐 - 에 따라 결과물이 판가름나게 됩니다.



일단 위의 경우를 피하기 위해 그래픽팀에서 많이 사용하는 방법은 다음과 같습니다.

- 물체를 잘게 쪼갭니다 :
어찌보면 완벽한 방법입니다. 쪼개면 쪼갤수록 피봇축이 정밀해져서, 앞뒤 판정이 정확해 질 테니까요.
하지만 그런 식으로 가다가는 모든 폴리곤을 쪼개야 할겁니다 OTL
이것도 적절한 수준으로 쪼개는 수 밖에 없지요.

- 알파 부분을 최소화해서 그립니다. :
상당히 소극적인 방법입니다. 잎을 그릴 때 잎 모양으로 아예 모델링 해 버린다던가, 머리카락을 그릴 때에는 정말로 머리카락의 '맨 끝만' 알파 블렌딩을 사용하는 방법입니다. 소극적이지만 효과적입니다.

- 알파 테스팅을 사용합니다. :
이건 다음 시간에 설명하지요.

- Z Write를 사용하지 않습니다. :
역시 다음 시간에 설명하겠습니다.



그리고 프로그램팀에서 많이 사용하는 방법은 다음과 같습니다.

- 렌더링 레이어를 만듭니다 :
강제로 그리는 순서를 그룹화 시켜서 제어하는 겁니다. 예를 들어 반투명이라고 하더라도 'water' 속성인 녀석들은 무조건 반투명 중 제일 먼저 그린다 - 라는 식으로 제어하는 것입니다.
그런 식으로 이펙트나 기후 등 종류에 따라 그리는 순서를 제어합니다. 완벽하진 않지만 크게 제어가 가능한 방법입니다.

- 여러 Pass를 사용하여 그립니다 :
머리 카락등에서 방향에 따라 여러 번에 나누어 그리는 방법입니다. 그래픽에서 얼마나 잘 쪼개주느냐에 따라 다른 결과가 나올 수 있습니다. 때문에 매우 고난이도의 방법이지요.





자아 . 일단 성급하게 결론내려보면 다음과 같습니다.
- 불투명인 것들은 Z 버퍼만으로 앞뒤구별이 가능하니, 대충 찍어도 된다.
- 반투명인 것들이 끼어 버리면 문제가 되니, 불투명한 것 먼저 찍고 반투명한걸 나중에 모아서 찍는다.
- 반투명인 것들끼리도 먼저찍히냐 나중에 찍히냐에 따라 문제가 생기기 때문에 반투명한 것들은 순서를 판정해서 뒤에서부터 앞으로 찍어온다.
- 그래도 피봇으로 앞뒤를 판정하기 때문에, 완벽하게 앞뒤를 구분하는것은 사실상 불가능하다.


이것이 프로그래머와 그래픽 디자이너의 머리를 싸매게 만드는 알파 블렌딩의 저주입니다.

자 그럼 다음 시간에는, 이 문제의 해결책들중 하나인 알파 테스팅과 Z Read/Write 에 대해 좀 더 자세히 설명해 보겠습니다.
5부, 알파 테스팅과 Z Read/Write 에서 뵙지요. (아아 슬슬 지쳐간다...)

아래에서 퍼옴

http://chulin28ho.egloos.com/5269434

우왕. 이 부분이 아무래도 Z 버퍼와 알파블렌딩, 소팅의 개념까지 짬뽕되어 들어가는 곳이라
"우왕 이거 아무래도 간단하게 설명하기 힘들겠는걸..." 이라고 생각했는데 과연. 2부까지 써 보니 제대로 하려면 6부는 되어야 하는거 아닌가 - 라는 생각이 드는군요.

어쨌건 벌여 놓은 일은 마무리를 해야 하니.. 콜록.

==================================================================================

자 지난 시간까지 알아본것을 한 마디로 요약하면 '알파 블렌딩을 쓰면 Z 버퍼가 엉망이 되니 불투명 오브젝트부터 먼저 그리고 나중에 반투명 오브젝트를 몰아서 그리면 된다. ' 라는 것이었습니다.

네 그럼 될 것만 같습니다.

즉 불투명 오브젝트부터 먼저 그립니다. 랄라.
이 녀석들은 이전에 말씀드렸다시피, 어느게 먼저 찍혀도 상관이 없습니다. Z read와 Write 만 하면 완벽히 그려지니까요.

 

그다음 반투명을 그립니다. 역시 그리는 순서는 뒤죽박죽입니다. 왜 뒤죽박죽이냐고요? 길게 설명하진 않겠습니다만, 당연합니다. -_- ;;; 들어오는 순서대로 그리다보니, 앞에 있는지 뒤에 있는지 판단하지 않고 그냥 오는대로 그려서 그렇습니다.

 

자 이놈들도 Z Read / Write를 물론 합니다.
문제가 해결 될 것만 같습니다. 아이 기뻐라.


근데, 역시 문제가 생깁니다. 알파 블렌딩은 말씀드렸다시피 개악마 니까요 .

그렇습니다. 반투명끼리의 앞뒤판정!!!

즉 아래와 같이 반투명 이미지가 있다고 칩시다.

 

알파는 이렇구요

 

뭐 이러면 게임에서는 이렇게 나오는걸 기대할 수 있겠죠.

 

그치만, 가끔 이렇게 나옵니다..!! 뭥미 이건!!!!

 

그림을 보고 이해가 가십니까? 위의 것은 뒤의 나뭇잎이 먼저 그려지고 앞의 나뭇잎이 그려져서 문제가 없었지만,
아래의 것은 앞의 나뭇잎이 먼저 그려지면서, 투명한 부분에도 그림은 그리지 않았지만 Z 값은 Write 해 버렸기 때문에 뒤의 나뭇잎이 그려질때 Z 값을 Read 하다가 보니 이미 자기 앞의 Z 값이 있으니 그리는데 실패해서 이렇게 나오게 되는 것입니다.

여기까지 설명하면 보통 그래픽 디자이너분들은 이렇게 얘기하죠. (실제상황)

아니 그러니까 프로그래머들이 다 해결 가능하면 내가 이걸 왜 쓰고 있겠냐고.

자아 . 기존에 반투명과 불투명인 것들끼리도 저런 문제가 생겨서, 불투명한걸 먼저 그려서 해결했었습니다.
그런데 이번엔 반투명한 것들끼리 동일한 문제가 생기는군요. 그래서 알파 블렌딩은 개악마입니다

이걸 해결하는 법은 무엇일까요?
그래서 이것을 해결하기 위해 많이 사용되는 방법은 "줄세우기" 입니다.
즉 "그렇다면 반투명인 것들은 뒤에서부터 그리면 되잖아!!!" 라는 것입니다.
오호라. 과연 명안이십니다.

그렇습니다. 반투명인것들만 따로 모아서, 줄세우기를 하는 것입니다.

불투명한 것들은 기존에 그리듯이 그냥 막 그리고 (그래도 불투명한 것들도 앞에서부터 그리면 퍼포먼스가 좋아지긴 하지만요)
반투명한 것들을 그릴 때, 줄세워서 뒤에 있는 녀석들을 먼저 그려버리는 것입니다.

그림으로 앞뒤판정하기 좀 힘들지만, 대충 써 보면 저런 순서대로 정렬이 되겠군요.
아이 좋아라. 이제 반투명한 것들 끼리도 Z 값 걱정없이 그릴 수 있게 되었습니다.
물론 이게 부하가 장난이 아닙니다... 당장 화면에 나뭇잎이 수천장이 있는데 그게 모두 알파 블렌딩이라면... ㄷㄷㄷ
다 모아서 매 프레임마다 ( 초당 30번씩) 어떤게 앞에 있는지 판정하는 것도 보통 일이 아닌 겁니다.
그래서 일단 알파 블렌딩은 부하를 엄청나게 먹고 갑니다.

어떤게 앞에 있는지 정렬하는 부하도 물론 있는데, 거기에다가 또 뒤에 있다고 안그릴 수도 없습니다. 맨 뒤부터 그리다 보니 화면에 존재하는 모든 알파 블렌딩은 일단 다 그려 버린다는 거지요. 불투명한 것은 뒤에 있으면 안그리면 되지만 알파 블렌딩은 뒤에 있어도 보일수 있다는 전제로 그려지는 방식이거든요. 그러니 절약할 수 있는 구멍이 하나도 없습니다.

...알파 블렌딩을 남발하면 당신의 게임 퍼포먼스를 최악으로 만들기는 매우 쉽습니다.



자 뭐 퍼포먼스는 프로그래머들이 어떻게 해 주겠지 라는 무책임한 생각을 가지고, 어쨌건 이렇게 하면 일단 문제는 다 해결된 것 같습니다만, 아직도 문제는 또 남아 있습니다. 알파 블렌딩은 개악마 니까요.

아래에서 퍼옴

http://chulin28ho.egloos.com/5268685

이전 시간에 기초적인 Z 버퍼의 작동 개념에 대해 알아 보았습니다.
그런데 세상은 참 넓고도 깊은지라, 여러 가지 해결 안되는 문제가 있기 마련인거지요.

자 이전 시간으로 거슬러 가서 다시 생각해 봅시다.

위와 같은 환경에서 공이 안보이는 이유는?
네에 바로 plan의 Z 값이 공의 Z 값보다 앞에 있기 때문이지요.
그렇다면 다시 말해서, 공을 화면에 찍으려고 할 때
공보다 앞에 있는 물건이 있는지 없는지를 검사한다는 말이겠지요?

이것을 "Z 값이 씌여져 있는 상태를 읽어서, 자신이 그려져도 되는지를 확인해본다" 라고 합니다.
그 말을 줄여보면 "Z값을 읽는다" 라고 하고, 이 말을 다시 "Z Read" 라고 하는 것입니다.

또한 아래 그림을 다시 한 번 생각해 봅시다.

이번엔 공이 튀어나와서 앞에 있게 되었습니다.
공이 Z Read를 해 보면, 절반은 plan보다 앞에 있다는 것이 판명나니 일단 보이겠지요?
그렇지만 그걸로 끝이 아닙니다.
이번에는 화면에서 자신이 제일 앞에 있다라고 써 줘야 하는 상황이 벌어진겁니다.
즉 이렇게 말이죠.

다시 말하자면, " 자신이 기존의 Z 값보다 앞에 있다는게 판명나면, 자신의 Z 값을 덮어씌워 기록한다" 라는 과정이 필요하게 되는 것입니다. 위에서 plan이 써 놨었던 4라는 깊이값을, 공이 들어오면서 2와3으로 갱신해서 기록한 것과 같이요.

그래서 이것을 " Z 값을 쓴다" 라고 하고 "Z Write" 라고 부르는 겁니다.
즉, 기본적으로 모든 오브젝트는 자신보다 앞에 있는 녀석이 있는가를 체크하기 위해 Z Read를 해야 하고, 자신이 제일 앞에 있을 때에는 자신이 제일 앞이라는걸 표시하기 위해 Z Write를 해야만 하는 겁니다. 이걸 이렇게 표시하지요 "Z Read:ON, ZWrite:ON" 그리고 이래야 모든 오브젝트의 위치가 제대로 판정이 되게 됩니다.





....자 여기까지가 일반적인 상황이었습니다.





그렇지만 개악마 알파 블렌딩이 들어가면 아주 사정이 달라지게 됩니다.

우선 알파 블렌딩(Alpha blending) 이란 무엇을 의미할까요?
별 거 아닙니다. "반투명이 되는거 전부 다" 를 의미합니다.

-그냥 셀로판지처럼 50% 반투명해도 알파 블렌딩입니다.
-섬세하게 그라디에이션 되는 머리카락 끝도 알파 블렌딩입니다.
-빵빵 터지는 이펙트나 파티클도 알파 블렌딩 들입니다.
-반투명 되는 물도 알파 블렌딩입니다.
-살짝 뒤가 비치는 UI도 알파 블렌딩입니다.

하여간 "조금이라도 반투명한 영역이 있어서 뒤의 배경과 색이 겹치는 영역만 있으면"
그건 모두 알파 블렌딩입니다. 머리카락 끝에만 살짝 알파가 들어가 있다 해도, 머리카락 전체가 알파 블렌딩인 겁니다.

이 알파 블렌딩은, 위의 Z 버퍼 개념을 완전히 부숴버리는 무서운 짓을 합니다.
자, 생각해 보겠습니다.

먼저 투명한 plan이 찍혔다고 칩시다. 이 녀석은 알파 블렌딩인게 확실합니다.
그리고 이전에 얘기한대로  Z Read 와 Z Write 를 모두 ON 한 상태입니다.

 

그 뒤에 불투명한 공이 나중에 찍혔습니다. 어떻게 되겠습니까?

 

상식적으로 당연히 보여야겠지만, Z 값을 비교해 볼까요?
이미 plan이 Z 값을 4로 모두 Write 한 상태인 겁니다.

즉 불투명일때랑 똑같은 상태의 Z 값이 들어간 거지요.

다시 말해서 뒤의 공은 Z read를 해 보니,

자신이 plan보다 뒤에 있다고 판명되었기 때문에 찍지 않게 됩니다!!!!

제기랄 뒤에 공이 있는데 전혀 보이지 않아!!!


이것을 "Z test를 통과하지 못했다" 라고 말합니다.
 분명히 반투명인 plan이지만, 뒤에 있는 것은 전혀 보이지 않게 되는 기현상이 일어나게 되는 것입니다.
이것이 Alpha blending의 문제입니다.

보다 현실적인 예를 들어 보지요.

이런 알파 채널을 가진 나뭇잎이 있다고 칩시다.
알파 채널에 사알짝 반투명한 부분도 들어 있고 하니 이건 분명 알파 블렌딩이 맞습니다.

 

만약 게임에 찍히게 되면 이렇게 생겼겠지요.

 

조금 작게 만들어 봅시다. 1/4 크기로요. (외각 라인은 일부러 강조를 해 놨습니다.)

 

자 이렇게 알파 블렌딩된 나뭇잎이 찍혔습니다.
그 다음에 불투명한 커다란 공이 찍힌다고 생각해 봅시다.

 

자 여기서 생각을 해 봅시다. 저 나뭇잎이 먼저 찍혔기 때문에, 저 나뭇잎은 Z 값을 4로 이미 써 놨습니다.
그러므로 저 Plan에 속한 영역은 모두 공보다 앞에 있는 것입니다.

즉 최종 결과는 이렇게 나오게 되는 겁니다.

 

역시 알파 블렌딩의 악마짓이 시작되었습니다.

잘 알겠습니다. 그런데 지금 이건 나뭇잎이 먼저 그려진 경우이지요.
그렇다면, 만약 공이 먼저 그려지고 그 다음에 나뭇잎이 그려졌다면?

...그렇게 순서가 바뀌게 된다면 아무 문제 없게 됩니다!
이 문제가 일어날 때 이유를 찾기 쉽지 않은 이유가 바로 저것이지요.
실제로 오브젝트가 찍힐때 어떤게 꼭 먼저 찍힌다고 보장할 수가 없습니다.
(그 이유는 추후 또 얘기하도록 하지요.)


그래서 일반적인 해결책은 어떻게 하는 걸까요?
그래서 일반적으로는 , 일단 불투명한걸 모두 모아서 그려 버리고
나중에 반투명한것들만 모아서 그려 버리는 방식으로 해결해 버립니다.
이렇게 하면 불투명한 것들끼리는 단순한 Z 버퍼 방식으로 처리하면 되는 거니 일단 다 그려지고,
반투명한 것들은 나중에 그리니까 먼저 빈 영역이 Z 값을 차지하고 있어서 뒤에 있는 불투명한 것들이 안그려지는 불행한 사태를 피할 수 있는 것입니다.


그리고 이런 증상은 실무에서 이렇게 나타나게 됩니다.
배에 붙어 있는 이펙트가 파란 바닥 오브젝트를 잘라버렸습니다.

 

(물론, 위의 예제는 여태까지 설명한것과 완전히 같은 증상은 아닙니다. 그건 또 추후에 설명을..)


자아. 이렇게 하면 모두 해결된 것으로 보이지요? 불투명한 것만 먼저 그리고 반투명한 것만 나중에 그리면 다 해결되니까...
별로 개악마도 아니네? 라고 생각하는 당신...!

하지만 진짜 문제는 이제부터 시작입니다!!!

게임 개발은 그렇게 녹록한게 아니라구!!!!

이어지는 3부 (개악마 알파블렌딩 2편) 을 기대해 주세요.

아래에서 퍼옴

http://chulin28ho.egloos.com/5267860

사내게시판에 올릴 내용인데 여기다 먼저 정리한 후 올립니당.

에또.. 이 부분에 대해 개념을 가지신 그래픽 디자이너분이나 기획자분이 많지 않은 관계로,
게다가 이것이 설명된 책은 일단 프로그래머 책이다 보니 보기가 힘들고 (!!!) 그림을 대충 그려서 (!!!) 알아먹기가 보통 힘든게 아닌 관계로
좀 더 쉽게 만들어서 그래픽 디자이너나 기획자가 볼 수 있게 만들어 올려봅니다.

일단 Z 값의 구조는 다음과 같습니다.

 

ps: 으악 X와 Y가 바뀌었다.


모니터는 평면이지만, 그 안에는 가상의 3차원 메트릭스가 펼쳐져 있지요.
그래서 카메라 방향이 위 그림처럼 있다 치면, 화면에서의 깊이값이 바로 Z 방향입니다. 깊이라고도 하죠.

이건 어떨때 사용하느냐... 하면 어느 놈이 앞에 있냐? 랄때 사용합니다.

즉 아래 그림처럼 깊이값이 있다고 칩시다.

 

카메라와 가까운 곳은 0이고, 먼 곳은 9 겠지요. (진짜는 당연히 이정도가 아니겠지요.굉장히 큽니다. 물론 몇 비트로 지원해 주느냐에 대한 한계는 있지만.)
그런데 여기에 떡하고 평면이 나왔다 칩시다.

 

 4의 깊이에 평면이 있게 되는 거군요.
만약 이 뒤에 공이 있다면?

 

당연히 화면에서는 안보여야 정상입니다. 근데 어떻게 안보인다는걸 알 수 있습니까?
바로 '깊이값' 이 다르기 때문입니다.

plan 은 깊이 4에 있는데 공은 8 ~12  부근에 있습니다. 이걸로 뒤에 있다는걸 알 수 있다는 것입니다.
즉 모니터의 각 픽셀이  4의 위치에 있는 plan들로 채워져 있다는 것을 어디다가 적어 놔야 할 겁니다.  아래처럼 말입니다.  

 

그리고 이제부터 다른 걸 그릴때, 4보다 큰 숫자의 Z 값이 나오는 픽셀이면 안 찍어 버리면 되는 것입니다.

다시 말해서,  찍을때 보니 Z 값이 2나 3처럼 4보다 작은 (앞에 있는) 위치의 픽셀이면,
 이번엔 그 픽셀 부분을 다시 갱신해 버리고 찍어버리는 겁니다.

 

즉 이렇게 되는 거지요.

 

(* 주: 사실은 위 그림에서 공이 절반만 걸친 부분의 깊이값은 뭐냐.. .라고 혼동하실분이 계시겠지만, 실제로는 저 칸 하나가 한 픽셀이기 때문에 걱정하신것 같은 일은 안일어 납니다 ;ㅅ; 알아보기 쉽게 격자를 확대하다보니...)

그러므로 이런 깊이값은 지속적으로 저장되고 업데이트 되어야 합니다.
이것을 이미지로 만들어 놓은 것이 Z 버퍼라 불리는 그것입니다.

http://www.felixgers.de/teaching/jogl/depthbufferALgo.html

마치 fog와도 같게 생긴 Z 버퍼를 보시면, 검은 색은 카메라와 가까운 곳을 의미하고
흰색은 먼 곳을 의미한다는 것을 알 수 있습니다. (그리고 진짜로 fog도 이걸 이용합니다! )
 
이  z 버퍼의 좋은 점은, 찍는 순서고 나발이고 하나도 필요가 없다는 것입니다.
앞의 놈이 먼저 찍히나, 뒤의 놈이 먼저 찍히나 생각할게 없습니다. 아니 오히려 앞의 놈이 먼저 찍혀주는게 고맙지요.
뒤가 먼저 찍히면 뒤의 것을 그리고 Z 버퍼를 업데이트 한 다음에 다시 앞의 것을 그리고  Z  버퍼를 업데이트해 줘야 하지만 앞의 것을 한 번 그려놓으면 뒤의 것은 하나도 안그리면 되니까요.

이것이 Z 버퍼의 개념입니다. 간단하고 명쾌합니다.
그렇지만 , 반투명이 되어서 알파 블렌딩 (Alpha blending) 이 되면 얘기는 좀 심각해지게 됩니다 ....