lighting! lighting!

http://c0de517e.blogspot.com/2009/12/lighting-compendium-part-1.html

위의 글은 간단히 라이트 방식에 대해( 포워드/디퍼드/라이트 프리패스) 간단하게 설명하고 있습니다.

요즘  MMO 들도 슬슬 디퍼드라이팅을 적용하는 거 같은데요(타뷸라라자가 처음인가요?).

일단 제일 큰 장점은 라이트 갯수보다도 라이트맵을 매번 굽지 않고 테스트해볼 수 있는게 크지 않나 싶습니다. 디자이너가 프로그래처럼 빌드해야 되는 건--안타깝지요.(우리(프로그래머?)도 언제가 빌드 없는 세상이 되면 엄청나게 생산성이 높아지겠지요?).

1. 포워드 렌더링
   => 기본적으로 라이트를 많이 쓴다는 가정하에 => 열심히 baking 해서 쓰게 됩니다.
   => 물론 미리 구워진 녀석이니 다이내믹으로 뭔가 연동하기는 쉽지 않겠지요;;;
   일단 아티스트 분들의생산성이 지형이 클수록 뚝뚝 떨어지니(엄청난 빌드타임으로);
   그리고 덤으로 라이트 문제가 생길때마다 데이타가 제대로 구워졌는지 한번씩 체크해봐야되는 문제가 있지요.
  => 그래도 다이내믹 환경이 필요없고, 편하게 라이트 스태이틱으로 마구 넣어서 적절한 크기의 맵에 쓰기는 좋은 솔루션이 아닌가 싶습니다.
  일단 Beast 같은 미들웨어의 경우 최신 버전에서는 매우 Scalable? 해서, 사용성이 좋아보입니다. 포워드로 수십명의 아티스트와 일할 계획이라면 당연히 써야 되는 거 아니라는 생각이 들 정도입니다.(물론 비싸니, 소규모 프로젝트에서 쓰기는 좀 그런 거 같습니다.)

2. 디퍼드 렌더링.
   => 이런 류의 솔루션은 이상하게 관심이 안가서,  안 보고 있었습니다만, 시대의 흐름을 무시할 수 없어서,(질문도 많이 들어오고-  기존 블로그 참고;;) 공부하고 있습니다.
   => 뭐 장점은 많은 수의 라이트를 다이내믹하게 사용할 수 있다 일테이고,
   => 기타 g-buffer 를 이용해서 포스트 프로세싱시에 이것저것 해볼 수 있는 점도 있겠습니다.;
   => 아직 하드웨어적으로 지원되지 않는( MSAA?) 기능이 있어서, 좀 더 발전할 구석이 있는 거 같습니다.
   => 알파블렌딩 이슈 - 요즘 많은 질문으로 저를 괴롭히고 있습니다.(원래 전 렌더링이 아니라서요-_-;; 이제 흰띠를 메었는데..흐음) 해결방식도 다양해서 어렵네요. 일단은 디퍼드라이팅을 즐하거나, 포워드로 렌더링하거나-ㅁ-

3. 라이트 프리패스/인퍼드 라이팅
   => 뭐 쓰질 않아서 잘 모르겠습니다만, 일단 3 패스로 라이트를 적절히 미리 계산해두거나 하는 거 같습니다.
   => 어차피 디퍼드의 알파블렌딩 이슈등을 처리하기 위해서 등등 디퍼드의 단점은 어떻게든 메꾸어야 되니 비슷한 여러가지 알고리즘이 생기는 거 같습니다.!
  

라이팅하니까 또 다른 문제인 쉐도우쪽도(이쪽은 이제 공부중이라서-ㅁ-)
그래도 이쪽은 카스케이드 쉐도우 맵으로 거의 하고 있는 거 같습니다.

몇몇 분은 그래픽스 쪽은 이론 쪽으론 정립이 끝난다고도 하시는 듯, 전 그런 걸 잘 모르겠습니다만, 하드웨어의 변동에 맞추어서 앞으로도 쭈욱 변화가 지속될듯 하네요. 따라서 엔진 개발은 쉽지 않은 일일 거 같습니다. 그러니 한동안은 이렇게 미들웨어와 엔진에 의존해서 개발해야 되겠지요. 렌더링 엔진도 로직 부분 처럼 점점 컴포넌트+그래프(언리얼의 그래프로 연결 만능-_-) 세상이 되는 거 같습니다.