2009년 05월 04일
게임을 위한 라이팅 솔루션
아래 포스트에서 라이트맵 이야기가 나온 김에 게임을 위한 라이팅 솔루션 미들웨어들을 한번 정리해 봅니다.
먼저 DCC툴을 이용한 라이트맵 솔루션으로는 다음의 두 가지가 있습니다.
DCC 툴을 이용한 라이트맵 베이킹 솔루션의 경우 스튜디오의 아트 파이프라인과 각각의 작업 그룹에 대한 고려도 필요합니다. 레벨을 DCC 툴에서 모델링하고 텍스쳐링하는 그룹과 게임의 레벨을 디자인하는 그룹이 분리되어 있는 경우 라이트맵의 베이킹은 아트 그룹에서 처리하게 됩니다. 그런데 레벨 디자인 그룹에서 레벨 디자인에 대한 변경에 따라 수시로 라이트맵을 다시 베이킹해야 하는 일이 발생하게 됩니다. 작업의 비효율성이나 시간적 부하는 말할 필요도 없거니와 그룹간의 불화로 번지는 일도 일어납니다. 이런 이유로 DCC툴의 라이트맵 베이킹을 사용하고자 한다면 나름의 세심한 주의(?)가 필요합니다.
라이트맵 솔루션이긴 하지만 DCC 툴이 아닌 오프라인 툴로는 Beast가 있습니다.
그런데 이상의 방법들은 베이킹(프리 프로세싱)을 하는 솔루션이기 때문에 계산에 따른 시간이 필요하다는 단점이 있습니다. 레벨 에디팅이 반복적인 작업인 것을 생각하면 전체 개발 시간에서 상당 부분을 차지한다는 것을 감안해야 합니다. (Beast의 경우 Incredibuild를 통한 분산 처리가 가능하긴 합니다)
이런 이유로 런타임 때 처리할 수 있는 방법이 있다면 생산성 향상에 도움이 될 것입니다. 최근에는 프로세스의 발전에 힘입어 이런 솔루션들도 등장하고 있는데 그 중 하나로 Lightsprint가 있습니다.
비슷한 솔루션으로 Fantasy Lab의 Radium SDK가 있는데 어쩐지 최근에 변경된 Fantasy Lab의 사이트에서는 볼 수가 없군요. (이 솔루션이 Lightsprint보다 훨씬 더 관심이 갔는데 말입니다.)
...다소 시간적인 여유가 있다면 NHN의 오픈 소스 프로젝트 중에 분산 컴퓨팅 프로젝트인 coord 프로젝트를 이용해서 GI 프로세싱 솔루션을 한번 시도해 보는 것도 좋을텐데...라고 생각만 하고 있습니다... ^^; (혹 관심 있으신 분??)
ps.1 최근에 뜯어 보고 있는 게임인 Fallout3의 경우에는 라이트맵이 보이지 않습니다. 물론 리얼타임 G.I.도 없습니다. 작년 최우수 게임 수상에 빛나는 게임이죠. 그래서 훌륭한 게임과 라이트맵은 큰 상관 관계가 없다고 말할지 모르겠습니다만 우리 대부분은 이와 같은 위대한 게임을 만들지 못하기 때문에 라이트맵이라도 만들어야 하는 것이 아닌가 하는 다소 역설적인 생각도 해 봅니다...네, 웃자고 한 이야기예요 ㅡㅡ;
ps.2 물론 아래 포스트한 글에서 팀스위니 형님이 이야기대로 소프트웨어 렌더링의 시대가 오거나 최근에 32 코어 머신 등으로 Quake4를 레이 트레이싱하는 프로젝트도 나오던데 이런 것이 보편화 되면 이 포스팅의 이야기도 다 닭질이긴 합니다. ㅡ,.ㅡ
먼저 DCC툴을 이용한 라이트맵 솔루션으로는 다음의 두 가지가 있습니다.
DCC 툴을 이용한 라이트맵 베이킹 솔루션의 경우 스튜디오의 아트 파이프라인과 각각의 작업 그룹에 대한 고려도 필요합니다. 레벨을 DCC 툴에서 모델링하고 텍스쳐링하는 그룹과 게임의 레벨을 디자인하는 그룹이 분리되어 있는 경우 라이트맵의 베이킹은 아트 그룹에서 처리하게 됩니다. 그런데 레벨 디자인 그룹에서 레벨 디자인에 대한 변경에 따라 수시로 라이트맵을 다시 베이킹해야 하는 일이 발생하게 됩니다. 작업의 비효율성이나 시간적 부하는 말할 필요도 없거니와 그룹간의 불화로 번지는 일도 일어납니다. 이런 이유로 DCC툴의 라이트맵 베이킹을 사용하고자 한다면 나름의 세심한 주의(?)가 필요합니다.
라이트맵 솔루션이긴 하지만 DCC 툴이 아닌 오프라인 툴로는 Beast가 있습니다.
- Beast - Mirros's Edge에 사용
그런데 이상의 방법들은 베이킹(프리 프로세싱)을 하는 솔루션이기 때문에 계산에 따른 시간이 필요하다는 단점이 있습니다. 레벨 에디팅이 반복적인 작업인 것을 생각하면 전체 개발 시간에서 상당 부분을 차지한다는 것을 감안해야 합니다. (Beast의 경우 Incredibuild를 통한 분산 처리가 가능하긴 합니다)
이런 이유로 런타임 때 처리할 수 있는 방법이 있다면 생산성 향상에 도움이 될 것입니다. 최근에는 프로세스의 발전에 힘입어 이런 솔루션들도 등장하고 있는데 그 중 하나로 Lightsprint가 있습니다.
비슷한 솔루션으로 Fantasy Lab의 Radium SDK가 있는데 어쩐지 최근에 변경된 Fantasy Lab의 사이트에서는 볼 수가 없군요. (이 솔루션이 Lightsprint보다 훨씬 더 관심이 갔는데 말입니다.)
...다소 시간적인 여유가 있다면 NHN의 오픈 소스 프로젝트 중에 분산 컴퓨팅 프로젝트인 coord 프로젝트를 이용해서 GI 프로세싱 솔루션을 한번 시도해 보는 것도 좋을텐데...라고 생각만 하고 있습니다... ^^; (혹 관심 있으신 분??)
ps.1 최근에 뜯어 보고 있는 게임인 Fallout3의 경우에는 라이트맵이 보이지 않습니다. 물론 리얼타임 G.I.도 없습니다. 작년 최우수 게임 수상에 빛나는 게임이죠. 그래서 훌륭한 게임과 라이트맵은 큰 상관 관계가 없다고 말할지 모르겠습니다만 우리 대부분은 이와 같은 위대한 게임을 만들지 못하기 때문에 라이트맵이라도 만들어야 하는 것이 아닌가 하는 다소 역설적인 생각도 해 봅니다...네, 웃자고 한 이야기예요 ㅡㅡ;
ps.2 물론 아래 포스트한 글에서 팀스위니 형님이 이야기대로 소프트웨어 렌더링의 시대가 오거나 최근에 32 코어 머신 등으로 Quake4를 레이 트레이싱하는 프로젝트도 나오던데 이런 것이 보편화 되면 이 포스팅의 이야기도 다 닭질이긴 합니다. ㅡ,.ㅡ
# by | 2009/05/04 23:51 | Development | 트랙백 | 덧글(2)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
그래도 기술 담당은 일단 기술쪽 최고를 목표로 해야 하는 것은 당연하지요.
... 저도 저 파이프라인에 동의합니다. 저라면 저정도 금액은 투자하는 것이 몇 백배 싸다고 말하겠어요.
그리고 혹시나 큰 것 한장에 대해서 착오가 있을까 해서...한장은 억-소리 나는 금액입니다. ^^