안녕하세요 호주갔다온 대마왕입니다 이힛.
짧지만 일에 방해되기는 충분히 긴 정도로 갔다왔기 때문에 역시 이번에도 내용은 짧습니다.
요샌 이래저래 일이 겹쳐서 - 한 일주일 앓아 눕기도 하고 - 여유시간을 내기가 쉽지가 않아요
더 얘기하면 만수무강 기원하는 글이 좌르륵 달릴거기 때문에 여기서 끝.

 호주의 Light 는 참 ... 대단하더군요.

오늘은 이전 시간에 이은 라이트 얘기를 마무리하도록 해 보지요.
세부적으로 꼼꼼하게 따지면 더 많지만, 일단은 '이정도만 알아두어도 프로그래머가 무시하지는 못한다' 수준의 지식을 목표로 정리해 보고 있습니다. ^[각주:1] 저도 아는게 쥐뿔만큼이라는게 문제

지난 번 11강에서 배웠던 내용을 한 마디로 정리해 보면 일단 이거지요 이거.

네네. 이거 뭐 주어도 없는 글입니다만 일단 이정도로 알아두도록 합시다.

이걸 말하려고, '멀리 떨어진 오브젝트가 더 밝다' 라는 상식에서 벗어난 주장으로 환기효과를 노려 보았습니다. 굉장히 중요한 진리 뭐 그런거 아니예요. 그러니까 11강은 사실 낚시  

11강에서 말한 것 처럼 멀면 더 밝아지는 3d 의 빛에서는 함정이 하나 있죠.
그 함정은 'Point light 일 때만" 이라는 것입니다.^[각주:2]  (spot 라이트도 point와 같은 종류의 라이트라고 할 수 있지요. )

그럼 다른 라이트가 또 무엇이 있었지요?
넹 바로 Direct light 입니다.^[각주:3]

이 라이트는 성격이 좀 달라요. 그리고 3DMAX에 있는 녀석은 게임안에 있는 조명과도 좀 많이 다릅니다. 다른 조명보다도요. 일단 이 Direct light 란 녀석을 알아보도록 하지요. 이 light는 꽤 중요한 light예요.

일단 , 3Dmax 에서는 이렇게 생겼지요.

원통이네요.

원통이예요.

원통이군요.

원통하군요.

네 그냥 원통이지요. 그래서 그런지, 그래픽 아티스트들은 다이렉트 라이트를 이 '원통' 모양이라고 생각하는 사람들이 많습니다. 시작점이 있고, 넓이가 있지요. 끝 점도 있 (...다고 느껴집니다만 사실 써보면 끝은 없습니다) 어 보이구요.

그림으로 표현하자면, 이런 모양의 빛 덩어리가 다이렉트 라이트라고 그래픽 아티스트들은 느끼게 됩니다.

두둥

이건 좀 이해해 줘야 해요. 맥스 라이트가 저렇게 생겨먹었잖아요. 그림을 보고 배우는 아티스트들에게 저런 그림을 보여줬으니까 당연하지요. 그래서 그냥 3D max로 배운 초보 그래픽 아티스트들은 Direct light가 저렇게 생긴줄 알고 있는 경우가 많습니다.

그런데 라이트를 좀 사용해본 그래픽 아티스트들은, 맥스에서 다이렉트 라이트가 사실은 이렇다는걸 느끼게 됩니다. 생각이 좀 바뀌게 되는 거지요.

끝이 없지요.

 네, 뭐 이건 어쩔 수 없습니다. 태어나서 처음 만져본 3D 프로그램의 라이트가 진짜 저렇게 생겼고 저렇게 작동하니까요.
당연히 이게 전부다라고 생각하는건 너무나도 당연합니다. 심지어 3D max 교재에서도 저런식으로 라이트를 설명합니다.
시작 지점이 있고, 넓이가 있습니다.

그렇지만 프로그래머들이 배우는,  게임에서 쓰는 다이렉트 라이트는 위와 다른 개념으로 설명하곤 합니다. 
프로그래머들의 책에서는 보통 이렇게 표시해요.

 읭?

화살푭니다. 저건 아무리 봐도 화살표잖아요.
혹은 이렇게 표시하기도 합니다.

의의읭?

화살표가 늘었습니다. 이게 뭘까요? ^[각주:4]

이게 프로그래머들이 인식하는 "Direct light"입니다 뭘까요? 뭐가 다른 걸까요?

사실 그림으로 설명하기 힘든 개념인건 사실입니다. 저건 벡터(Vector) 를 나타내는 표시로,
게임에서의 Direct light는 - 프로그래머들이 이해하는 Direct light는 - 위에서 설명한 그래픽 아티스트의 Direct light와 개념이 좀 다릅니다. 뭐가 다르냐고요?

1. 시작점의 개념이 없습니다.

말그대로 시작점이 없습니다. 끝 점도 없구요. 무한대에서 시작해서 무한대로 끝나는 빛입니다.

2. 범위의 개념이 없습니다.

이것도 말그대로입니다. 원통형? 그런거 없습니다. 넓이도 무한대입니다.^[각주:5]

3. 그러므로 빛의 방향과 크기만이 있습니다. 다른건 없어요.

크기도 사실은 단위벡터 처리하는 경우가 대부분이라... 사실 사용할때에는 빛의 방향밖에 없습니다. 그게 정보의 전부입니다. 범위나 시작점 모두 Max에서 '추가적으로' 만든 기능일 뿐입니다.  

그리고 추가적으로 여기서 알 수 있는 이 '위엄있는' Direct light에 대한 정보는 다음과 같습니다.

1. 가벼운 Light이다.

공식적으로 '가장 가벼운' light는 Ambient light입니다. 그렇지만 Ambient light는 이걸 과연 light라고 불러도 될 것인가 싶을 정도로 light같지 않은 light여서, 사실상 공식적으로 조명처럼 사용되는 light중 가장 가벼운 것은 Direct light라고 말해도 과언이 아닐 정도입니다. ^[각주:6]

생각해 보세요. 
Point light는 시작점이 어디인지 알고 있어야 하고, 그 점에서 내 위치가 어디인지를 알아야 빛의 각도가 나옵니다. 알아야 할 데이터가 많아요.  

Spot light는요? Point light의 데이터에다가 이번에는 제한되는 빛의 각도 정보까지 있어야 해요! 얼마나 정보가 많겠어요?

그치만 Direct light는 시작점도 없고 끝도 없고 어딜가도 같은 방향의 빛이 조사되기 때문에, 매우 계산하기 간편한 조명입니다. 그래서 그림자들이 생길 때에도 주로 Direct light 기반에서만 생기곤 하죠.

2. 태양 빛을 표현할때 많이 쓴다.

'태양은 Point light잖아요? 그럼 Point light를 써야지 왜 Direct light를 씀? ' 이라고 물으실 분도 계시겠지만...
네 , 맞습니다. 태양은 엄밀히 얘기하면 point light예요. 그치만.

크기차가 이래서야 ... 태양이 쏘는 빛이 Point light 보다는 Direct light처럼 오겠지요. 거리도 좀 머나요 ... 그럼 더 당연하죠. 그래서 Direct light로 대충 표현해도 별 상관 없는 것입니다.  

무시하면 안됩니다.

3. Direct light는 오브젝트가 어디에 있건 똑같은 밝기이다.

네.. 제가 맨 위에서 말하고 싶던 부분이 이것입니다.
당연하지요! 모든 빛이 모든 부분에서 같은 각도로 조사되는데, 가까이 있던 멀리 있던 상관 없잖아요? 빛이 확산되거나 감쇄되지 않는 완전한 '이상적인' 상태라면, 오브젝트는 어디에 있어도 똑같은 빛을 받을 수 밖에 없습니다! Point light와는 다르다는 거지요 !! ^[각주:7]

포인트 라이트 다이렉트 라이트

일단 이렇게 거리가 무시되구요.

구석에 놓아도 OK

이렇게 구석에 놓아도 상관 없습니다.
3D 게임의 맵에디터를 사용하신 분이라면 아실텐데요. Direct light는 정말 맵 구석에다가 대충 박아 놓아도 아무 문제 없습니다. (조작성때문에 가운데에 놓으시겠지만)

4. 대신 기울어지면 밝기가 떨어진다.

이건 뭐 상식적으로도 당연하게 알고 계신 것이지만, 한번 써 봤습니다.
이제 이 단순한 개념을 직접 만들어 보셔야 하거든요 우후후 :)

그리고 프로그래머들은 이 개념으로 처음부터 배운 거지요.
여기서 우리 그래픽 아티스트들의 Direct light에 대한 개념의 괴리가 생깁니다.
자, 이제 다음 시간부터는 '직접' 이 라이트의 계산을 만들어 보면서, 프로그래머가 생각하는 Light의 개념을 몸으로 익혀 봅시다!! 우리 그래픽 아티스트들은 몸으로 익히는데 능하니까요!!!

예고 (두둥)

안녕하세요? 디퍼드H 입니다. 혹시 저의 강의를 기다리신 분 있나요? (없진 않겠죠? ㅡ.ㅡa) 갑작스런 싱가폴 친구들의 등장과 함께, 남의 집에서 얹혀살기(무지 불편했다는...), 이사까지...(조만간 다시 이사를 해야하는 실정입니다. 뭔가 복~~잡한 사연으로 인해) 여러일들 때문에 강의가 늦게 올라오고, 늦게 올라온 것도 모자라, 내용이 많이 부족하거나 적을 수도 있는 사연을 이해.. 이해 해주길 바라면서, 강의를 시작해보죠.

사실 저번 강의를 올리면서, 많은 고민을 했었습니다. 그 고민의 이유는 바로 메세지 시스템인데요. 사실 메세지 시스템은 저의 강의 가장 핵심적인 부분이기도합니다. 원래, 엔진을 처음 만드시는 분들 또, 학생(막 게임 프로그래밍에 접하신분들)을 위해서 강의를 하기에는 바로 메세지 시스템을 설명하기에는 조금 무리가 있다고 판단을 했거든요. 헌데, 예상외로 메세지 시스템에 대해 많이 궁금하신분들이 많아, 이번 강의는 메세지 시스템에 대해서 한번 짚고 넘어가고자 합니다.  물론 학생 분들이나 엔진을 처음 만드시는 분들은 아, 대충 이런 이야기이구나! 하고 넘어가더라도, 문제가 없을 겁니다. 왜냐? 시간이 지나서 다시 다룰거거든요. 전체적으로, 심도 있는듯 없는듯 한번 저의 메세지 시스템에 대해 한번 보도록 하죠.

제가 메세지 시스템을 만들때, 보통 롤 모델이 필요했습니다. 어떻게 만들어야 가장 효과적일까? 그렇게 생각하다보니 제일 먼저 떠오르는것이 우체국시스템이더군요. 우체국을 모르시는 분들은 없을거라 생각합니다. 우체국의 시스템은 오랫동안 아직도 유지되어 오고 있습니다. 이것은 바로, 그 시스템이 효과적이다라는 의미이겠죠. 이렇게 생각하면서 저는 메세지 시스템의 롤 모델은 우체국에서 이용되는 시스템(편지겠죠.) 정하고 메세지 시스템을 설계했었습니다. (사실 저 같은경우 어떠한 시스템이라던가 그외 필요한 것을 구현할때에는 보통 주위를 많이 이용하는 편입니다. 크게 많이 도움이 되더군요.) 우리가 보통 편지를 보내고 또, 다른사람에 받는데 까지에는 다음과 같은 방법이 이용됩니다. 우선 우린 편지를 씁니다.(편지를 쓸때에는 보내는사람, 받는사람, 주소, 그리고 내용이 들어가죠.) 편지는 편지통으로 들어가고, 그 편지는 우체국으로 모입니다. 우체국에서는 이편지를 주소에 따라 편지를 배정하고, 마침내 편지는 받는사람에게 가죠. 설마, 이렇게 편지가 여러분들께 가는것은 모르는 사람들은 없겠죠? (있다면 큰일입니다!) 이제 이 시스템을 우리가 구현할 메세지 시스템에 알맞게 바꾸어나가보도록 하죠. 우선 아래의 그림을 봅시다.

모든걸 다 넣으려고 하니, 그림이.. 크군요. 아무튼, 위의 그림을 보시면 이상한 클래스 이름들이 눈에 띕니다. 메세지 매니저 뭐 이름 그대로 아주 직관적이라 메세지를 처리하는곳이구나 라는게 감이 오지만 ISociable 클래스는 무엇인가? 라는 의문점이 생깁니다. 제가 메세지 시스템을 구현할 때, 정말 알맞은 변수명을 찾으려고 고생을 했는데 나온것이 ISociable 이었습니다. 우리 이전에 말했던 우체국 시스템(자꾸 우체국 시스템하니 좀 많이 어색한 것 같군요. 정말로 어색하지만 양해 부탁드립니다)을 이용해서 말한다면 주소 등록본(?) 아니 주민등록본(?) 과 비슷한 메세지(편지)를 서로 주고 받을 수 있도록 해주는 클래스라고 생각하시면되겠습니다. 편지를 주고 받는다 = 대화를 한다 -> 사회적이군! 이라는 결론으로 ISociable라고 지었는데, 개인적인 의견으로는 뭐 알맞다고 생각합니다(사실 멋지다고 생각한다는...)  이 클래스에는 메세지와 관련된 메소드와 변수를 가지고 있습니다.

프로그래머는 역시 코드로 보는게, 바로 뙇(요즘 이게 대세더군요) 감이 오실겁니다. 이전에 설명한 내용이라 넘어가도록 하죠. 다음은 ISociable을 관리하는 객체인 ISociableManager가 있습니다. 우체국으로 생각한다면, 우체국의 중요부서중 하나라고 생각하시면됩니다. 나머지 하나는 물론 메세지 매니저죠. ISociableManager와 MessageManager의 상호작용으로 우체국의 역활인 메세지를 받아 저장하고, 매 프레임 마다 메세지를 Dispatch를 한다고 보시면 됩니다.  ISociableManager는 메세지를 Dispatch하는 역활을 맡고 있고, MessageManager는 메세지를 메세지 큐에 매 프레임마다 들어오는것을 보관하고 관리를 합니다. 우선 아래의 그림을 보도록 하죠.

위 그림은 그래픽 시스템에서 다이렉트x의 초기화를 위해 윈도우 값이 필요해, 윈도우 핸들값을 메세지를 요구할 경우를 가정해서 관계도를 나름 멋지게(?)그려보았습니다. 사실 그림과 간단하게 붙어있는 설명들을 읽으시면, 뙇 어떻게 MessageManager와 ISociableManager 상호작용을 해서 메세지 시스템이 구현되는지 한눈에 아실거라 생각이 들지만, 그렇지 않을 분들을 위해 설명을 시작하도록하죠. 이 예시만 이해가 되신다면, 여러분도 여러분만의 메세지 시스템 구현을 위한 준비가 되었다고 봐도 될 것입니다.

우선 윈도우 시스템과 그래픽 시스템은 ISociable클래스를 상속받아, 메세지 주고 받을 수 있습니다.(코드적으로 설명하자면, 윈도우 시스템과 그래픽 시스템은 RecvMessage 메소드를 들고 있고, ISociableManager에 등록도 되어 있다는 말이겠죠?) 윈도우 시스템에서는 메세지를 우선 메세지 매니저로 메세지를 보냅니다.  메세지 매니저는 그 메세지를 매니저가 가지고 있는 메세지 큐에 넣습니다. 다음 프레임에 메세지 매니저에서는 메세지가 Dispatch 되어야하는지 우선 확인을 합니다. 후일 메세지 시스템 구현 부분에서 자세하게 다루게 되겠지만, 메세지 클래스는 여러가지 멤버 변수들을 가지고 있습니다. 그 중 하나인, DelayTime의 멤버변수는 언제 메세지가 Dispatch되어야하는가를 가리키는 변수명입니다. 만약 DelayTime이 1.0f의 값을 가지고있다면 1초 후에 이 메세지를 Dispatch해야 한다는 것을 의미합니다. 게임 엔진이 60fps로 돌아간다고 가정했을때, 이 메세지는 약 60프레임 이후 메세지가 Dispatch 된다는 것을 의미합니다. 메세지 시스템에서는 매 프레임마다 이 변수의 값에서 -0.166666f 값을 빼주면서 0 이하가 된다면 이 메세지는 처리되어집니다. 메세지 처리가 준비되었을때, 메세지 시스템에서는 DispatchMessage 메소드를 실행시키기 시작합니다. 이 메소드는 메세지에서 수신자의 id혹은 이름을 꺼내서 ISociableManager에 등록되어있는 ISociable객체를 찾아서 RecvMessage 함수를 실행시킵니다. 예시로 돌아가서, 메세지에서는 수신자가 WindowSystem으로 되어 있었습니다. 현재 윈도우 시스템은 ISociableManager에 등록되어 있고 결국 메세지 매니저에서는 윈도우 시스템에서 구현된 RecvMessage 함수를 실행시키고 이 함수내에서 윈도우 핸들을 달라는 메세지에 알맞는 행동이 구현되어 있을 것입니다.  그럼 윈도우 시스템은 아마 윈도우 핸들 값을 동봉한 메세지를 날려주겠죠?(데이터를 어떻게 동봉하는가?는 후일 구현부분에서 다룰것입니다.)

지금까지 여러분들과 함께 메세지 시스템은 어떻게 만들것인가? 만들어지는가? 에 대해서 확인해보았는데요. 오늘은 자세한 듯하면서, 또 어찌보면 아닌듯이 알아보았습니다. 어떤분들은 지금까지의 내용으로도 충분히 여러분만의 메세지 시스템을 만들 수 있다고 생각이 듭니다. 여러분들은 충분히 할 수 있습니다! 이번강의에서 일부러 메세지 클래스를 어떻게 만드는건가? 또 MessageManager와 ISociableManager 구현과 팁은 포함시키지 않았습니다. 이 내용은 후일 강의를 진행해 나가면서, 때가 되면 다루어 보도록 하겠습니다. (많은 댓글과 열혈한 성원은 강의 진행에 무지 도움이 되어 메세지 시스템 구현 강의가 빨리 진행될 것을... 알려드립니다 ~ ㅋ^^) 사실 오늘 넘 정신이 없다보니 중간중간 여러분들이 이해 안되는 부분이 있을 수 있을거라 생각이 (엄청) 듭니다. 여러분들 중 이해가 안되거나 궁금한 내용은 댓글로 남겨주신다면 최대한 성실히 답변해드리도록 하겠습니다.

안녕하세요. 2달 동안 놀아버린 랩하는좀비, 랩좀비군입니다. 오랜만이네요. 회사에서 막히는 일이 있어서 이것에 대해서 신경쓰고 있다보니, 글을 게시하는 것을 까맣게 잊고 있기는 개뿔, 그냥 안쓰고 있었습니다(...). 아직 문제는 풀리지 않았는데, 계속 생각하고 있어봤자 답은 나오지 않을 것 같아서 머리도 정리할 겸 이제 게시하네요. 실은 5월 17일에 게시 할려고 했는데, 블리자드의 은혜가 5월 15일이어서 잠시 잠적했습니다. 글은 썩어가고 있고, 작성자는 돌아오지 않고 있고, 리플은 달리고 있고, 가정이 무너지고, 사회가 무너지고, 악마 사냥꾼의 랩은 올라가고!!

이번에 구현해 볼 기능은 Screen Space Decal(이하 SSD) 기능입니다. Deferred Decal이라고도 하지요. 언차티드에서도 사용했고, 저번에 게임테크 2012에서 발표한 KUF에서도 잘 사용하고 있더군요. 그리고 우리의 꽃미남 천재 프로그래머이신 포프님이 참여하신 스페이스 마린에서도 잘 사용하고 있는 기능입니다. 스페이스마린의 SSD기능은 포프님이 KGC2012에 소스까지 공개하신다고 하니 기대를 해 보아요. 

그만큼 싸고(많이 싸지는 않은 것 같습니다. 아직 저희도 공격적으로 사용하고 있지 않아서 측정을 안해봤습니다.), 구현하기도 쉽고 해서 앞으로 이 기능이 세상을 널리 이롭게 하지 않을까 합니다. 이건 뭐 초딩도 20분이면 구현할 수도 있는 -하지만 전 하루 걸림 음하하- 기능이니 모두 구현해 보아요.

아무튼, 잡설은 이정도로 하고, 하나하나 썰을 풀어보도록 하겠습니다.

데칼에는 다음의 4가지 기능이 들어가 있어야 훌륭한 데칼 시스템이라 할 수 있습니다.

1. Scene의 Albedo뿐만 아니라, Normal, Specular Factor 등등 다른 surface들의 값들을 변경할 수 있어야 합니다.
2. Decal은 모든 동적인 것과 정적인 폴리곤의 표면에 잘 붙어야 합니다.
3. Decal은 붙는 표면에 따라서 잘라지거나 감싸거나 할 수 있어야 합니다.
4. Decal은 복잡하게 생긴 메쉬에도 잘 붙어야 합니다.

1번은 Deferred Rendering 시스템으로 렌더링 파이프라인이 구성되어 있다면 쉽게 적용할 수 있습니다.
문제는 2 ~4번까지인데, 기존의 데칼시스템으로는 조금 힘든 문제였습니다.

우리가 지금까지 구현했던 데칼 시스템은 - 이하 Forward Decal. 정확한 명칭은 저도 잘 모르겠습니다. 아시면 알려주세요.-

1. 데칼이 붙을 장소의 버텍스 정보를 알아온다.
2. 알아온 버텍스들을 잘 연결해서 이쁜 모양의 표면을 만들어 준다.
3. Z-Fighting이 발생하지 않도록 카메라와 거리를 이용해서 잘 조절하여 표면의 위쪽에 위치시켜 준다.

이런 방식으로 하고 있었지요. 위의 문제에 대해서,

2번의 동적인 메쉬일 경우 매 프레임 갱신되는 버텍스의 위치를 알고 있어야 했으며,
3번일 경우, 버텍스의 위치에 따라서 많은 계산을 통해서 잘 일그러지 않게 만들어야 했습니다.
4번은 그냥 계산하면 되지만 버텍스의 갯수가 많아질 수록 연산량이 많으 늘어나서 성능에 영향을 끼칩니다. 거기에다가 Scene의 LOD까지 가세해 버리면 이건 뭐 아오 빡쳐! LOD 하지마! 상태가 되었습니다.

하지만 SSD에서는 완벽하지는 않지만 기존의 구현과는 다르게 2, 3, 4번의 문제를 쉽게 해결 할 수 있는 방향이 있습니다. 여기서는 그 방법에 대해서 설명하진 않겠습니다. 저도 여기까지는 구현하지 않았거든요. 저는 직접 구현하지 않은 거 아니면 썰을 풀지 않습니다. 신용100%. 필요하면 그 때 구현하기로 하고, 역시나 올 말의 잘생기신 포프님의 발표를 기대해 보아요. 흐흐

SSD의 최고 장점은 말 그대로 화면 공간(Screen Space)에서 데칼을 그리는 것에 있습니다. FD에서는 버텍스의 위치값을 참조하면서 Z-Fighting이 발생하지 않도록 이것 저것 매직 밸류를 테스트하면서 많은 시간을 소모했던 것에 반해서 SSD는 그런 문제가 전혀 없습니다. 말 그대로 이미 렌더링된 2D화면에 덧칠하는 방법이거든요. 그래서 FD와는 다르게 카메라를 눕혀서 본다고 해도 데칼이 붕~ 뜨거나 하진 않습니다. 게다가 버텍스 정보를 가지고 있을 필요도 없구요. Depth Texture를 알고 있어야 한다는 제약이 있지만, 요즘에는 기본적으로 Depth를 먼저 렌더링하지 않을까 하는 생각이 듭니다. PostEffect 만들 때 참조하면 좋기도 하구요.

그럼 어떻게 구현해야 하는지 하나 하나 스텝으로 알아보도록 하지요.

1. Depth를 화면에 렌더링합니다.
Depth를 렌더링하는 이슈는 여러 가지가 있습니다. w로 나눌 것인지, far plane 상수를 두고 나눌 것인지 등등, 이것들은 상관 없고 나중에 Depth값을 이용해서 Decal의 Local공간으로 변환을 할 수 있는 방법만 알고 계시면 됩니다. 전 far plane의 상수값을 두어서 실행했습니다.

모양은 Box나 Sphere가 주로 사용되는 것 같습니다. 여기서는 그냥 Box를 사용하도록 하지요.

3. 이제 이놈을 화면에 렌더링하면서 Local위치를 가지고 UV를 계산해 냅니다.
위치는 표면에 위치하도록 하면 되겠지요? UV까지 잘 계산하였다면 다음과 같이 화면에 데칼용 Box가 렌더링됩니다.

  

간단한 Shader코드는 다음과 같습니다.

float pixelDepth = tex2D(depthtex, vPos);     //Depth값을 알아옵니다.
float3 worldPos = ComputeWorldPos(uv, pixelDepth); //Depth값을 이용해서 WorldPos를 계산합니다.
float3 decalLocalpos = worldPos * invWorldTM; //WorldPos를 Decal의 Local공간으로 이동시킵니다.
float2 decalUV = decalLocalpos.xy + 0.5f; // 0.5를 더해서 0.0과 1.0 사이로 맵핑시킵니다.

4번째 줄에서 0.5를 더한 이유는 Decal의 Local Vertex의 위치가 -0.5 ~ 0.5로 맵핑되어 있기 때문입니다.
즉, 2번에서 Box형 기하구조를 생성할 때, Vertex의 위치값을 -0.5와 0.5를 이용해서 만드시면 됩니다.
조금만 생각해 보시면 쉽게 알 수 있으니 그냥 스무스하게 넘어가겠습니다.

5. 이제 렌더링되는 부분이 아닌 다른 모든 부분을 AlphaTest나 AlphaBlending으로 날려버립니다. 
어느 것으로 할지는 렌더링 되는 데칼에 따라 다릅니다. 뭐 쉬운 부분이니까 잘 하시면 됩니다. 간단한 셰이더 코드는 다음과 같습니다.

float dist = abs(decalLocalPos.z);        //Decal의 Local깊이를 구합니다.
float scaleDistance = max(dist * 2.0f, 1.0f); //Local깊이를 0.0과 1.0으로 맵핑시킵니다.
float fadeOut = 1.0f - scaleDistance;     //이제 FadeOut값을 구해서..
float4 Color = decalColor;                //최종 칼라를 구해주고
Color.a *= fadeOut;                       // FadeOut값을 곱해주면 표면의 부분 이외는 사라지게 됩니다.

...어라 되었네요? 이건 뭐 초딩도 30분이면 할 수 있는..
3D들도 새로 나온 기술들을 보면 어려워 보이지만 실제로 구현해보면 '와 쉽네잉' 이라는 생각이 드는 게 대부분인 것 같습니다.
좀 더 많은 정보를 원하시는 분은 게임 엔진 젬스 1권에 내용이 나와 있으니 참고하시길 바랍니다.

자 그럼 랩좀비군은 이만 총총총.