Babytook's T Blog

아래에서 퍼옴

http://jufoot.egloos.com/1933720

 

screen.xy = ndc.xy * 0.5 + 0.5;

아래에서 퍼옴

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) 이 되면 얘기는 좀 심각해지게 됩니다 ....

GDI 의 DrawText 같은 텍스트 출력 API 들은 우선 그 출력 품질이 좋지 못하고 특정크기 이하에서는 anti-aliasing 이 적용되지 않는다. (워드패드에서 12pt 크기의 글자와 40pt 글자의 품질을 비교해 보시라..) 무엇보다 DC 엑세스는 느리다!! 해서 어제는 난데없이 FreeType 라이브러리를 게임에 붙이는 작업을 했었다. 튜토리얼이 잘 되어 있에서 별 무리 없이 끝나긴 했지만 덕분에 알게 된 사실 한가지.

ttf 폰트는 저마다 인코딩 타입이 다르다. 완성형으로 되어 있는 폰트도 있고 유니코드로 되어 있는 폰트도 있다. 폰트쪽에 영 관심이 없다 보니 오늘 첨 알았다. -_-;;; 어쨌든 FreeType 은 glyph index(해당 글자의 인덱스) 를 넘겨주고 이미지를 넘겨받는 식인데 가장 해피한 경우는 "유니코드 ttf 폰트" 일 경우다. 이건 그냥 유니코드를 넘겨주면 글자 이미지가 튀어 나온다.

하지만 "완성형 ttf 폰트" 에서는 작업이 좀 골때리게 된다. 영문같은 경우에는 그냥 ASCII 코드를 넘겨주면 되지만 완성형 한글같은 경우 한글 2byte 한글자의 인덱스를 넘겨줘야 한다. 인덱스라 함은 완성형 한글 2 byte 를 하나의 숫자, 그것도 big-endian 으로 바꾼것을 의미한다. 간략하게 유니코드 한자에서 glyph index 를 얻어내는 코드를 살펴보자.

wcahr_t *szString = L"한글입니다~";

아래에서 퍼옴
http://includes.egloos.com/1482677



What is FreeType 2?

FreeType 2 는 작고 능률적이고 높은 수준의 커스텀이 가능하며 이식성이 높도록 - 양질의 출력을 가능하게 하면서 - 디자인된 software font engine이다. 이 것은 graphics librarys, display servers, font conversion tools, text image generation tools, 그리고 여러가지 다른 products에도 사용될 수 있다.

FreeType 2는 하나의 font service임에 유념하라. 이 것은 text layout이나 graphics processing 같은 고수준용의 API를 제공하지 않는다. 그러나 이것은 간단하고 이용하기 쉽게 정형화된 인터페이스를 제공함으로써 저런 작업들을 아주 간단하게 만든다.

FreeType 2는 두 가지의 open-source license에 의해 배포된다. 우리 고유의 FreeType License와 GPL이 바로 그것이다. 이 것은 어떠한 프로젝트에도 이용될 수 있고, 소유될 수도 있다(?).

Features

다음 사항들은 FreeType 2가 제공하는 대략적인 특징들이다.

-FreeType 2는 file format에 구애받지 않고 정형화된 방식으로 font에 접근 할 수 있도록, 매우 간단하고 사용하기 쉬운 API를 제공한다. 부가적으로 font file의 특정 data에 접근할 수 있도록 개별 format용의 API를 사용할 수 있다.

-다른 비교 대상들과 다르게 FreeType 2는 TrueType이나 Type1 같은 scalable font formats를 지원한다. 그리고 그 fonts의 outline data 등을 client applications에 제공할 수도 있다.

-FreeType 2는 module을 기본으로 설계되었으나, compile 시에 정적으로 link시킬 수도 있다. 이 modules는 특정 폰트용으로 사용될 수도 있고, 새 glyph image formats용으로도 사용될 수 있다.

-FreeType 2 는 embedded system을 고려하여 쓰여졌다. 즉, static writable data는 사용되지 않는다. ( ROM으로 부터 직접 돌아갈 수있다.) client application이 그 자체의 memory manager와 i/o stream implementation을 제공해 줄 수 있다.

그 이야기는 다음을 가능하게 한다. 당신은 ROM기반, 압축된 혹은 원격의 font file들을 같은 API로 쉽게 읽을 수 있다. 여러 stream inplementations 는 하나의 FreeType 2 instance로 동시에 사용될 수 있다.

당신은 당신의 embedded project/enviroment에 필요한 module만을 compile함으로써 FreeType의 사이즈도 줄일 수 있다.

기본적으로 FreeType 2 는 아래와 같은 font format들을 지원한다.
- TrueType fonts ( and collections )
- Type 1 fonts
- CID-keyed Type 1 fonts
- CFF fonts
- OpenType fonts ( TrueType과 CFF의 변형들 )
- SFNT-based bitmap fonts
- X11 PCF fonts
- Windows FNT fonts
- BDF fonts ( anti-aliased 된 것들 포함 )
- PFR fonts
- Type42 fonts ( 제한된 지원 )

주어진 글꼴의 형태로 FreeType 2는 256단계의 "회색"을 이용해서 양질의 단색 bitmap 혹은 anti-aliased pixmap을 만들 수 있다. Windows 9x/98/NT/2000, FreeType 1 의 5단계 보다 훨씬 낫다.

FreeType 2 는 TrueType 과 OpenType에서 정의된 모든 character mapping들을 지원한다. 그리고 머리 아픈 "encoding translation" 문제로 몰아넣는 Type 1으로부터 Unicode charmap을 합성해낼 수도 있다. ( 물론 원한다면 original encoding을 사용할 수 있다. )

FreeType core API 는 glypn name이나 kerning data 같은 선진 정보(advanced data를 머라 해석해야 할지)에 접근할 수 있도록 간단한 함수들을 제공한다.

성능 좋고 모든 기능을 갖춘 TrueType bytecode interpreter를 제공한다. 이 engine은 작은 사이즈에서 멋진 출력을 만들 수 있다. 모하하고 혼동을 일으키는 TrueType specifications 때문에 이 요소를 제대로 만들기란 매우 어렵지만, 이제 우리는 Windows와 Mac의 질에 밀리지 않는다. ( 부디 interpreter를 사용하기 전에 이와 관련한 우리의 특허권 조항을 읽어주길)

TrueType bytecode interpreter이 필요없거나 혹은 사용하고 싶지 않은 사람들을 위해, 우리 고유의 hinter module을 만들었다. 이 것 역시 크기가 조정 가능한 font에 사용 될 수 있다.

FreeType 2는 비슷한 font engine들에선 주로 가능하지 않은 정보들을 제공한다. 이를 테면 kerning distances 나 glyph names, vertical metrics 등등..

module 디자인 덕택에 추가적인 format-specific 정보들을 optional API들이 제공할 수 있도록 library를 강화하는 건 쉽다. ( 예를 들면 어떤 optional API는 TrueType과 OpenType fonts의 SFNT table을 검색하는 기능을 제공한다. )

FreeType 2는 release 2.0.1부터 고유의 caching subsystem을 제동한다. 이 기능은 face instances나 glyph images를 저장하는데 효과적으로 사용될 수 있다.

Requirements

FreeType 2는 산업표준의 ANSI C로 작성되었고 다른 C compiler로 쉽게 compile 된다. 심지어 우리는 유명한 compliers에서 compile 할 때 (gcc나 Visual C++혹은 Boland C++) 모든 "warning"을 제거하기 위해 하기 위해 대단한 노력을 기울였다.

표준 ANSI C library와 별개로, FreeType 2 는 어떠한 추가적 의존성을 가지고 있지 않고, 어떠한 system에서도 독립적으로 complie되고 install 된다.

Patents issues

TrueType specification의 몇몇 부분들은 여러 Apple소유의 특허권으로 덮혀 있다. TrueType gliyph를 rendering하는 것은 Apple의 IP 권리 (license를 제외하고 : 뭐지?) 를 위반하지 않고선 일반적으로 불가능하다.

아래의 설명은 우리가 이 문제를 풀어낸 약간 특별한 방법에 관한 것이다.

- 먼저, FreeType의 기본 build는 TrueType glyphs rendering에 관한 특허 기술들을 전혀 사용하지 않을 것이다.
불행하게도, 이 자유는 font design과 주어진 font와 다른 glyph metrics에 따라 때때로 이상적인 질보다 낮은 glyph를 대가로 요구한다.

- 만약에 당신이 특허권이 인정되지 않은 나라에 살거나, 당신이 Apple로부터 license를 받았다면, 그리고 최상의 품질을 원한면, library를 컴파일하기 전에 간단한 설정 macro만 실행 시키면 된다. 만세!

이 주제에 관한 추가적 정보는 우리의 TrueType Patents page(http://freetype.sourceforge.net/patents.html)에서 찾을 수 있다. 당신이 Apple로부터 license를 획득하고 싶다면 그들의 Legal Department(mailto:iplaw@apple.com)로 연락하라. 우리는 그것이 가능한지, 얼마의 비용이 소요되는지등에 관해 어떠한 정보도 줄 수 없다.

 GFx 2.0 SDK 라이센스 비용 (full source access) 
 - $15,000 USD License per App / 첫번째 플랫폼 가격
 - $10,000 USD License per App / 각각의 추가적 플랫폼 가격
 - $10,000 USD Support per App / per year (1년 의무 사용)

 - 만약 PC용 게임만 개발할 경우 전체 $25,000 USD (2번 항목이 빠지므로)
 - 만약 PC & Xbox360을 동시에 개발할 경우 전체 $35,000 USD
 - GFC 라이센스를 살 경우 GFx가 포함 되어 있음, $50,000 USD

 GFC & GFx 혼합 사용 여부 
 - Sony 사에서 GFC & GFx를 함께 사용하여 게임을 만들고 있음 (Scaleform 사에서 직접 밝힘)
 - 혼합 사용에 대해서는 Scaleform 에서는 지원하지 않음 (혼합 사용하는 당사자가 문제를 직접 해결해야 함)

 GFx SDK Components 

 - GFx 툴킷은 다음과 같은 코어 라이브러리 컴포넌트들로 구성되어 있다.

   * GFx.lib - GFX 핵심 라이브러리
   * GMain.lib - WinMain 컨테이너
   * GFx_D3D9.lib - D3D9 기반에서 렌더링하는 라이브러리
   * GFx_GL.lib - OpenGL 기반에서 렌더링하는 라이브러리

   * GFx.lib 는 아래와 같은 3개의 핵심 코어로 이루어져 있다.
   * GFXPlayer - 코어 플레이백 엔진
   * Renderer - 코어 렌더링 서브시스템
   * Kernel - 코어 라이브러리

 프로그램 설정 방법
먼저 웹사이트에서 GFx SDK를 다운로드 받아서 설치한다. GFx는 MSVC7.0 버젼과 MSVC8.0 버젼 이렇게 두개가 존재한다.
설치하면 설치한 SDK 경로에 다음과 같은 하위 폴더가 생성된다.

(기본폴더를 예로 설명 하겠습니다.)
 - C:\Program Files\Scaleform\GFx SDK 2.0 Eval\Include  <- 위 헤더 파일을 프로젝트에 포함 시킴

 - C:\Program Files\Scaleform\GFx SDK 2.0 Eval\Lib\Win32\Msvc80\Debug_MT
 - C:\Program Files\Scaleform\GFx SDK 2.0 Eval\Lib\Win32\Msvc80\Debug_Static_MT
 - C:\Program Files\Scaleform\GFx SDK 2.0 Eval\Lib\Win32\Msvc80\Release_MT
 - C:\Program Files\Scaleform\GFx SDK 2.0 Eval\Lib\Win32\Msvc80\Release_Static_MT

라이브러리 폴더는 위와 같이 4개가 생성되는데, 설정 방법은 아래와 같다

- Debug_MT ( Scaleform GFx 멀티 스레드 디버그 DLL 라이브러리)
 * 프로젝트 속성 -> 구성 속성 -> C/C++ -> 코드 생성 -> 런타임 라이브버리 -> 다중 스레드 디버그 DLL(/MDd)
 * 프로젝트 속성 -> 구성 속성 -> C/C++ -> 일반 -> 디버깅 정보 형식 -> C7 호환(/Z7)

- Debug_Static_MT ( Scaleform GFx 멀티 스레드 디버그 라이브러리)
 * 프로젝트 속성 -> 구성 속성 -> C/C++ -> 코드 생성 -> 런타임 라이브버리 -> 다중 스레드 디버그 (/MTd) 
 * 프로젝트 속성 -> 구성 속성 -> C/C++ -> 일반 -> -> 디버깅 정보 형식 -> C7 호환(/Z7)

- Release_MT ( Scaleform GFx 멀티 스레드 DLL 라이브러리)
 * 프로젝트 속성 -> 구성 속성 -> C/C++ -> 코드 생성 -> 런타임 라이브버리 -> 다중 스레드 DLL(/MD)
 * 프로젝트 속성 -> 구성 속성 -> C/C++ -> 최적화 -> 최적화 -> 속도 최대화(/O2)

- Release_Static_MT ( Scaleform GFx 멀티 스레드 라이브러리)
 * 프로젝트 속성 -> 구성 속성 -> C/C++ -> 코드 생성 -> 런타임 라이브버리 -> 다중 스레드 (/MT)
 * 프로젝트 속성 -> 구성 속성 -> C/C++ -> 최적화 -> 최적화 -> 속도 최대화(/O2) 로 설정)

 GFx 검토 사항 
  - SWF file의 액션 스크립트를 통하여 게임과 통신 가능
  - flash 파일을 동적 텍스쳐로 사용 가능
  - Flash 8 포맷 지원 가능 (몇몇개 밖에 지원하지 못한다, color add, subtract, multiply)
  - Flash 7 포맷은 많은 부분을 지원
  - Flash 6 포맷은 거의다 지원
  - 액션 스크립트 지원하나 제한이 있다 (2007년안에 100% 지원을 목표로 하고 있음)
  - Shockwave 는 아직 지원하지 않음
  - 액션 스크립트 이용한 동적 메뉴 지원
  - UNICODE 지원
  - 2D 렌더링시 이미지와 도형을 변환하고 기울이기가 가능
  - FSAA or 픽셀쉐이더를 사용하지 않고 High quality AA(anti-aliasing)렌더링 가능
  - Flash 파일의 Text 렌더링 가능
  - Flash 비디오, 사운드 파일은 지원하지 않는다
  - 아주 적은 메모리 사용 (풀스크린에서 SWF 인터페이스 사용시에 1MB 이하의 메모리 사용)
  - Win32API & FreeType2 폰트부분에 이용가능