Posted by kaoru
Trackback URL : http://kaoru.teamnop.com/blog/trackback/371
Posted by kaoru
Trackback URL : http://kaoru.teamnop.com/blog/trackback/362
소프트 파티클을 만들어주는 기술의 정확한 명칭은 Depth bias blend이다.
Depth bias blend는 스프라이트 텍스처에 가상적인 두께를 만들어서 그 두께 정보가 무엇인가와 교차하면 교차하는 객체나 표면의 픽셀의 색과 그 스프라이트 텍스처의 교차되는 부분의 픽셀 색의 최대 근사값을 구해 교차하는 부분의 파티클 픽셀의 색을 보간하는 연산을 통해 교차선을 부드럽게 만들어주어 칼날과 같은 날카로운 교차선이 나타나지 않게 하는 기법이다.
이것을 스프라이트 기반의 Emitter파티클에 사용할 시에 소프트 파티클이라고 불리게 되는 것이며 활용되는 부분은 파티클뿐만이 아니라 여러 부분에 사용할 수 있다.
기존의 게임들에서 화염, 폭포수, 연기와 같은 파티클이 화면상의 다른 3D 객체나 월드 표면과 교차하면 그 칼날과 같은 교차선이 강하게 드러나는 매우 부자연스러웠던 연출을 본적이 때때로 있을것이다.
불꽃이나 탄피같은 파티클은 매우 작은 폴리곤 덩어리들에 알파값을 준 텍스처를 사용해 표현하기 때문에 다른 면과 교차해도 교차선같은게 드러나는 일이 없지만 자욱한 연기나 뿜어져 나오는 화염, 또는 사방으로 튀기는 물방울이나 폭포수와 같은 Emitter 파티클은 그 파티클의 모양을 그린 텍스처를 앏은 사각형 텍스처에 붙인 포인트 스프라이트 를 여러개를 사용해 만들어내는 것이기 때문에 다른 면과 교차한다면 그 교차선이 강하게 드러나게 된다.
이 기술의 알고리즘은 오래전부터 구상되었었고 사용되어 왔지만 그 명칭이 불분명하였다. 예를 들어 Infinity Ward의 2005년작 Call of Duty 2는 이 기술을 옵션에서 Zfeather Smoke라는 이름으로 명명하였고 어떤 게임들에선 종종 소프트 엣지 (Soft Edge)라는 이름으로 불리기도 한다. 이번에 MS에서 DX10 D3D 10 기술표를 내 놓으면서 거기에 기본적으로 포함된것중 하나가 이 기법인데 거기서는 소프트 파티클이란 이름으로 정의하고 있으며 최근의 게임이나 엔진들도 소프트 파티클이란 이름을 사용하고 있어서 소프트 파티클이란 이름으로 굳어지고 있다.
아래의 스크린샷들은 Capcom사의 Lost Planet의 게임 화면으로 위의 것은 소프트 파티클 처리가 되지 않은 스크린샷이고 아래의 것은 소프트 파티클 처리가 되어 있는 스크린샷이다. 서로 대조하여 그 교차선이 드러나고 안드러나고의 차이가 극명하게 드러난다.
화염 파티클 (스프라이트 텍스처)이 몬스터나 오브젝트, 벽, 바닥, 천장 등에 교차하여 그 교차선이 강하게 드러나고 있다.
소프트 파티클 처리가 되어서 화염 파티클 (스프라이트 텍스처)이 표면과 교차되는 부분의 픽셀의 색이 교차되는 표면 부분의 텍스처 색과 중간으로 보간되어 그 교차선이 마치 없는것처럼 부드럽게 보인다.
이 Depth bias blend처리를 물가의 부드러운 교차선 처리 (이것을 잘 활용한 예로는 2006년에 출시한 Ubisoft의 Splinter Cell: Double Agent가 있으며 곧 출시 예정인 Crysis에서도 구현)에 사용하는 것도 가능하며 특히 디자이너가 응용하기에 따라서 기존에 표현하기 힘들었던 것들을 부드럽게 표현 가능하다.
기본의 Depth bias blend처리를 하지 않은 상태에선 스프라이트 텍스처를 여러장을 사용해서 서로 겹치지 않게 정렬하면 자욱한 연기따위는 만들수 있었지만 어느 방향에서 바라보아도 입체적인 연기나 구름따위를 만들려면 그 스프라이트 텍스처들이 서로 교차해야하기 때문에 교차선이 드러나서 만들어도 비정상적인 모습으로 보이게되어 제대로 된 표현이 불가능 했었다.
Depth bias blend처리를 하고 스프라이트 텍스처를 여러장을 사용하여 서로 교차시키면서 입체감이 있게 구성한다면 볼륨감이 있는 연기, 혹은 구름 등을 만들어 낼수 있게 된다. 이것은 Volumetric Particles (볼류메트릭 파티클)이라고 불리기도 하는데 볼류메트릭 파티클이란 기법은 사실은 별도로 존재하는 것이 아니며 소프트 파티클을 6방향면체 혹은 그 이상으로 둘러싼 것에 불과하다.
이것을 응용하면 볼류메트릭 파티클에다가 광원과 음영처리도 보다 자유롭게 사용이 가능 하다. 왜냐하면 교차선이 드러나지 않고 부드럽게 보간되어 자연스러운 음영처리가 가능해지기 때문이다. 이를 응용하면 광원이 반사되는 연기, 햇빛이 반사되거나 투과되는 구름, 구름 아래로 뻗어나오는 구름 등의 그림자 등이 구현 가능하다.
그리고 이 Depth bias blend기법을 사용해서 안개속이나 수중에서의 부드럽게 보간되는 빛의 변화 (이것을 잘 활용한 예로 역시 2006년에 출시한 Ubisoft의 Splinter Cell: Double Agent가 있으며 앞으로 출시될 Crysis에서도 구현)가 표현이 가능하다.
이 기법들은 DX10의 D3D 10에 예제로 포함된 것들이며 복잡한 응용 단계는 DX9급 이상은 되야 가능하지만 기본적인 보간법 (위의 스크린샷에서 소프트 파티클 처리) 구현자체는 DX7 이하급의 고정 파이프라인 상으로도 구현이 가능한 매우 단순한 기술이다.
소프트 파티클을 최초로 구현해 출시한 게임은 2005년에 출시한 Ubisoft의 Splinter Cell: Chaos Theory이며 같은 해에 출시한 Call of Duty 2가 있었고 이후 게임들에선 거의 기본적으로 채용하고 있다.
최근에 발매된 게임들은 이와 같은 소프트 파티클 처리는 기본적으로 지원하는 단계에 이르렀다.
이를 응용해 볼류메트릭 파티클이나 음영 처리 등의 더 복잡한 기법들의 사용도 언리얼 엔진 3와 같은 최신의 게임 엔진들이라면 모두 지원하고 있는 기술들이다.
소프트 파티클에 대한 설명
Posted by kaoru
Trackback URL : http://kaoru.teamnop.com/blog/trackback/352
역시 불펌.
오늘은 심심해서, 파티클을 (뭐 이야기 하자면, 알파객체들이라고 할 수 있겠지.) 사용하면서 나타나는 문제에 관해서 이야기 해볼까 한다.
이걸 보고 도움이 되는 사람이 있을지 좀 의문이기는 하지만, 초보자들에게는 도움이 될거라고 생각한다. 내가 쓰는게 좀 하는 사람들은 다 아는 내용만 쓰는 거니 새삼스럽게 뭐라하지 마시고 아시는 분은 패스~!
뭐 하여간 이야기를 시작해보자.
일반적으로 파티클들은 쿼드(사각형)로 만들어서 안에 텍스쳐등을 사용해서 효과를 만든다.
그리고 그 파티클들은 아티스트들이 툴에서 자기 마음대로 알파블렌딩함수를 설정해서 멋지게 만들어 게임에 사용하게 된다.
문제는 이때 툴상에서 보이는 문제와, 실제 게임상에 올렸을때 (뭐 월드툴 정도라도 나타날 수 있다고 생각 되지만..)나타 날수 있는 문제들이 있다.
일단 툴 (여기서는 이펙트 툴을 말한다.)에서 나타날 수 있는 것은 객체 가림현상이다.
우선 우리가 일반적으로 렌더링 할때, Z버퍼를 사용한다.
Z버퍼를 사용한다는 것은 두가지로 나눌수 있다. Z버퍼를 참고하는 것과 Z버퍼를 갱신하는것.
그리고 일반적인 객체를 그릴때는 두가지를 다 사용한다.
하지만 알파객체들은 그렇지 않다. Z버퍼를 참고하기는 하지만, Z버퍼를 쓰지 않는 것이다.
(이후부터는 갱신이라고 하겠다.)
이것은 객체의 알파부분이 Z버퍼를 갱신해버리면, 실제 구멍이 난 부분까지도, Z버퍼는 모두 갱신해버리기 때문이다. (일반적인 구멍일때는 알파테스트를 사용하는데, 이것은 알파검사해서 미달되는 부분을 아에 그리지 않는 것이라 Z버퍼도 역시 갱신하지 않는다.). 이것은 잘못하면, 그객체 뒤에있는 것이 안보이고, 가려지는 것을 보이게 된다는 것이다.
이것을 해결하기 위해서, 알파객체는 Z버퍼에 값을 갱신하지 않는 것이다.
지금 설마 아에 [Z버퍼를 안쓰면 되지 않는가?] 하는 생각을 가진사람이 있는가?
도전정신은 좋다. 하지만 틀렸다고 이야기 해주고 싶다.
알파객체는 우선 불투명객체 이후에 렌더링을 한다.
그래야만 알파블렌딩이 똑바로 되기 때문이다. 그런 상황에서 Z버퍼를 쓰지도 않는다면, 어떻게 될것인가? 불투명 객체 뒤에 있는 알파객체들이 다 덮고 나타나는 사태가 발생해 버릴것이다.
자 그럼 이제 알파객체는 모두 Z버퍼를 쓰면 우리가 원하는 (정확하게 아티스트들이나, 디자이너들) 알파객체가 되었는가? 그것 또한 아니다.
알파블렌딩은 이전색과 어떻게 합성하는가를 결정하여 결과물을 나타내는 것이다.
이것은 결국 이전색이 무엇인가에 따라서 결과물이 달라질 수 있다는 것이다.
즉, 그리는 순서가 중요하다는 것이다.
이점에 대해서 의문을 품고, 어째서냐는 생각을 가질 수 있을 것이다.
나도 그랬으니, 그 마음 이해 한다.
그리는 순서가 중요하지 않는 알파블렌딩 함수는 Src나 Dest가 one 이 되는
ADD 형태의 알파블렌딩만이 가능한 것이다. 수학적으로도 생각해보면 간단하다.
덧셈과 뺄셈은 앞뒤 순서 아무리 바꿔도 결과는 같다. 하지만, 곱하기가 끼면 어떻게 되겠는가?
결과는 순서에 따라서, 완전히 달라지는 것이다. 이것은 즉 알파블렌딩도 마찬가지라는 것이다.
결국 카메라 기준으로 멀리있는 것부터 그려야 올바른 결과가 나올 것이다.
자 여기서 또 의문.
그럼 소트만 하면 되는 것 아닌가? 또한 알파객체라도 Z버퍼를 갱신해야 하는 상황이 있지 않은가?
틀린 말은 아니다. 여기서 부터는 선택에 문제이다.
일단 소트만 하면 되는 것 아닌가에 대한 문제부터 이야기 해보자.
소트를 하면 [망고 끝. 다리 쭉펴고 자자!] 라고 생각하기 쉽지만, 세상사는게 그리 쉽지 않은 것을 보여주기라도 하듯이, 알파객체가 그냥 쿼드만 있는게 아니고, 다양한 모양을 가지고 있고, 부피를 가진 형태로 있을때, 소트를 뭘로 기준으로 하는가 하는 문제가 발생한다.
대체로 소트는 그객체의 중심점을 기준으로 해서 하는데, 결국 부피를 가진 녀석은 먼저그려지고 나중에 그려질 알파객체가 못그려지도록 Z값이 갱신시켜버리는 사태가 발생 할수 있다는 것이다.
(사실 이것은 Z버퍼가 필요로 한 이유와도 유사하다.)
그래서 Z버퍼 갱신은 하지 말야 한다.
하지만 Z버퍼를 갱신을 해야하는 알파객체가 존재할 수 도 있다.
예를 들면, 큰 바위가 있는데, 천천히 투명해지면서 사라질때, 그 바위뒤에 있는 알파 객체들이
갑자기 앞으로 나와버리는 사태가 (중심점은 앞에 있지만, 객체부피로 봤을때는 뒤에 있는 알파객체) 발생할 수 있다는 것이다. 더 간단한 예는, 객체의 반은 불투명이고, 반은 알파인 객체.
뭐 그게 아니고, 일부분이라도 알파로 그려야 하는 객체들. 그런것이 있을때 분명 Z버퍼를 갱신해야 한다. 그래서 이것은 선택의 문제라 할 수 있다.
그런 상황을 아에 만들지 않게 만들던가. 아니면 빠르게 해서, 해결하던가, 그냥 Z값을 쓰던가.
선택에 남은 것이다.
다음은 게임상에서 발생할 수 있는 문제인데....피곤하니 다음에 하도록하겠다.
글만 잔뜩쓰고, 그림한점 없어서 매우 미안하게 생각하지만, 알아두면 실제 알파문제를 보면 바로
[아~! 이걸 말하는거였군!] 할 것이다.
그럼.
추가글 : 결론은 알파객체는 Z버퍼를 사용하지만 갱신은 하지말고, 소트는 필수다.
Posted by kaoru
Trackback URL : http://kaoru.teamnop.com/blog/trackback/351
kaoru 의 일기장 입니다.
- kaoru
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
