블로그 이미지
Every unexpected event is a path to learning for you. blueasa

카테고리

분류 전체보기 (2797)
Unity3D (853)
Programming (479)
Server (33)
Unreal (4)
Gamebryo (56)
Tip & Tech (185)
협업 (61)
3DS Max (3)
Game (12)
Utility (68)
Etc (98)
Link (32)
Portfolio (19)
Subject (90)
iOS,OSX (55)
Android (14)
Linux (5)
잉여 프로젝트 (2)
게임이야기 (3)
Memories (20)
Interest (38)
Thinking (38)
한글 (30)
PaperCraft (5)
Animation (408)
Wallpaper (2)
재테크 (18)
Exercise (3)
나만의 맛집 (3)
냥이 (10)
육아 (16)
Total
Today
Yesterday

체인 라이트닝 참 재미있는 이펙트이다.

 

MMORPG 에서 사용되는 대부분의 이펙트는 공격자->발사체->피격자 의 형태에 맞아 들어가는데

 

체인라이트닝은 이러한 구조가 여러가 엮어져 있는 형태이다.

 

 

 

 

100% 코드로 하기도 애매하고,

 

그렇다고 디자이너가 만들기도 애매한데,

 

결국 코드와 디자인을 반씩 섞어서 만드는 대표적인 이펙트가 "체인 라이트닝" 이펙트이다.

 

워크래프트3 와 와우를 보고서는 체인라이트닝 집어넣자고 기획자가 하루가 멀다하고 징징거린다.

 

참으로 큰일이지만 다른게임에서 되는거 안된다고 하기에는 내가 너무 무능해 보인다.

 

 

1) 첫 시도 -> 코드로 100% 생성을 시도하다.

 

체인라이트닝의 저러한 연출을 디자이너가 하기는 힘들다고 생각하고

코드로 연동하는것이 좋다고 생각했다.

 

게임 엔티티와 연동하는 저런 부분을 3dsMAX 에서 처리하기는 매우 힘들다고 생각했기 때문이다.

 

그래서 체인라이트닝의 번개부분을 노이즈함수 코드를 분석하면서 만들었는데

 

결과는 처참했다.

 

그냥 습작으로는 쓸만했지만 게임상에서 쓸만한 퀄리티가 아니였다.

 

솔직하게 말해서 프로그래머가 3dsMAX 로 번개를 만들어도 퀄리티가 엉망일텐데,

 

코드로 SetPosition 하면서 만든 번개가 퀄리티가 좋을리 없었다.

 

결국 코드로 100% 생성한 체인 라이트닝인 폐기 되었다.

 

 

2) 2차 시도, 체인라이트닝을 생각해보자.

체인 라이트닝 이펙트 자체를 분석하면서

 

체인라이트닝에서 실질적으로 연동해야 하는 부분은

결국 A->B->C->D 로 개별 장거리공격이 연장되는 요소밖에 없다는것을 알게 되었다.

 

그렇다면 개별요소 A->B, B->C, C->D 로 가는 개별 이펙트 자체는

얼마든지 맥스에서 제작할수 있었다.

 

맥스에서 체인라이트닝의 한토막만 만들고 코드로는 연결시키는것이다.

 

 

 

체인라이트닝의 애니메이션은 3부분으로 구성된다.

 

팽창기 : 번개가 공격자에서 피격자로 팽창하는 부분.

지속시간 : 번개가 지글지글 거리는 부분

수축기 : 번개가 공격자부분에서 소멸하기 시작하여 소멸하는 부분.

 

 

문제는 지금까지의 이펙트 렌더링 모듈이 키프레임 애니메이션밖에 지원하지 않아서

번개의 표현하기 위해서는 VertexAnimation 과 텍스춰 애니메이션을 추가로 지원해야 했다.

 

다른게 아니라, 디자이너가 번개를 표현하기 위해서는 맥스에 있는

Noise Modifier 를 반드시 사용해야 하는데 이를 추출할 방법이 VertexAnimation 밖에 없었다.

 

 

 

몇가지 문제가 있었다.

 

맥스에서 만든것을 단지 단순하게 공격자->피격자 거리에 따라서

늘려주기만 할뿐이니 거리에 따라서 이펙트가 왜곡되는 문제도 있었다.

 

이를 해결하는 꽁수 비슷한 방법으로

거리에 따라서 아예 이펙트를 3벌 만들었다.

 

근거리/중거리/원거리 이렇게 미리 이펙트를 3벌 만들어서 거리에 따라서

가장 비슷한 형태의 이펙트를 공격자->피격자를 연결하는데 사용했다.

 

물론 이러한 문제는 이펙트를 "코딩" 으로 제작했다면 발생하지 않는 문제이다.

하지만 "코드" 로는 디자이너의 섬세한 디자인역시 기대할수 없다는 점이 문제이다.

 

결국 맥스로 만든 이펙트를 여러벌 들고 있는것으로 타협을 보았다.

 

체인 라이트닝 이펙트는 좀 "랜덤"스러운 맛이 있어야 하는데,

 

이 부분역시 그냥 이펙트를 여러벌 들고 있는것으로 해결했다.

실제로 체인 라이트닝 이펙트는 거리당 3개, 랜덤속성을 묘사하기 위해서 추가로 3벌씩

도합 3*3 = 9 개의 이펙트가 존재했다.

 

실제로 체인라이트닝이라는 이펙트 하나를 만들기 위해서 상당한양의 리소스가 소비되었지만

그만한 가치는 있다고 판단한다.

 

내가 과연 옳은 방향으로 해결한것일까?

 

이펙트 제작에 있어서 모범 해답은 없다.

결과를 만드는것 자체가 빠듯한 상황에서 모범해답까지 찾을 사치까지 누리고 싶지는 않다.

 

글로는 한방에 스윽하고 적었지만, 게임에서 쓸수 있는 상태의 "체인라이트닝" 을 만들기 위해서

"한달" 동안 디자이너와 삽질을 해야했다.

 

디자이너가 맥스파일을 넘기면 시험삼아서 적용해보고 수정요청하고 다시 코드수정하고

맥스파일 다시 수정요청하고, 이런식으로 10번정도 반복하면 되는데,

 

아무 체계도 없는 막막한 상황에서 삽질로 하나씩 하나씩 완성하는것이니.

디자이너 입장에서도 고역이다.

 

"체인라이트닝" 한번 만들더니 "이펙트 담당할사람 따로 뽑아라" 라고 파업선언을 하더니

더이상 이펙트작업을 하지 않았다.

애니메이터에게 이펙트작업을 시킨것부터가 약간은 무리수가 있었지만 빠듯한 상황에서는 어쩔수가 없다.

 

다른사람들은 어떻게 작업하는지 궁금하다.


출처 : http://blog.daum.net/gdocument/29

반응형
Posted by blueasa
, |