Ray Differentials for ray-tracing in Renderman.

It uses a multiresolution geometry cache and a multiresolution texture cache and uses ray differentials to select the appropriate resolutions.

 
사실 과거 철없던 생각에 renderman에서 ray-tracing이 된다는 것은 불가능하다고 생각 했었다. 지금은 그런 나의 어린 생각을 비웃듯이 renderman에서 ray-tracing이 빵빵하게 잘만 돌아가고 있다. 초창기 버그도 많이 줄어 든것 같고.

그럼 왜 그렇게 불가능하다고 생각했고 이제는 가능해 졌는지 얘기 안할 수가 없겠다.

사실 이제는 renderman을 어떤 renderer라고 딱히 정의하기가 점점 어려워 진것 같다. hybrid reyes algorithm renderer라고나 할까? 이것도 시대적인 흐름인지라...

다들 알고 있겠지만 우선 간단히 ray-tracing에 대해 소개 하자면 ray-tracing은 정의 된 한 지점 point에서 방향을 같은 Ray를 쏘아 물체에 hit했는지 여부와 필요에 따라 hit 했으면 그 intersection point에서 normal값 그리고 u,v값을 토대로 shading 하고 경우에 따라 secondary ray(반사,굴절)를 shader 내에 정의 된 방향으로 다시 여행을 시켜 최종 color와 opacity 값을 찾아내어 pixel까지 가게 되는 다음 프로세스로 전달해 주는 것이다.

이 모든걸 가능하게 해주는 ray-tracing intersection algorithm을 크게 ray 성격에 따라 나눈다면
첫번째, ray for visibility determine,
두번째, ray for reflection and refraction,
세번째, ray for shadow
로 나눌 수 있겠고 또한 hit했는지 여부만 확인할 것인지, hit했을시 shading color값이 요구되냐 아님 opacity값만 요구되냐, ray의 개수를 한개만 쏘느냐, 여러개를 쏘냐. 뭐 이리저리 나눠질 수 있겠다. (이런 얘기 너무 반복해서 한 느낌이...)

이렇듯 ray tracing 엔진은 ray를 objects 사이를 비비고 들어가며 어디로 튈지 모르게 travel 해 된다. 이렇게 되면 모든 objects가 camera view 안 뿐만아니라 밖에도 scene file 안에 데이타로 존재해야만 hit했을때 정보를 해당 geometry 빼올 수 있게 되는데 renderman으로 치면 rendering bucket 밖에 뿐만아니라 camera view 밖에 또한 모든 geometry가 micropolygon으로 전환 된 상태로 메모리에 존재해 있어야 할텐데, 그리고 textures는 어떻게 하고, 이렇게 하다가는 거의 rendering이고 뭐고 micropolygon으로 convert 하다 세월 다 보내야 하는(조금 과정이....^^) 상황이 오기에 나름 심지있게 불가능 하다고 생각 했었다. 물론 BMRT가 있었지만 당시 너무 느려 공짜 학술용 렌더러로는 좋았겠지만 현실적인 프로덕션에서는 무리가 따랐다.

그럼 무엇이 이처럼 가능하게 했냐에 대한 얘기를 시작하면 눈부시게 빨라진 하드웨어의 발전에 대한 얘기는 빼도라도 camera view, 아니 render bucket block 밖의 세상의 효율적인 geometry and texture의 cache가 가능 했기 때문이다. renderman은 bucket 단위의 독립적인(localized말이 더 나을 듯...) renderer이다. 이는 그 bucket block밖의 모든 것들은 거들떠 보지 않아도 된다는 말이다. 독립적이라는 말에 특히 주목하기 바란다. 가능한 절차들을 독립적으로 만들어 쉽게 그 필요되는 부분만 접근할수 있게 여러 방식의 cache화를 통해 구분해 놓았다는 얘기다. 쉬운 예로 depth-map for shadow, env map for reflection and refraction, brick maps, 그리고 rendering 과정 안에서는 sampling의 독립화 등등... 그 'bucket 독립 만세'를 부르기 위해서 앞만 보고 달려온 듯한 느낌이든다. (물론 예외도 있다. 예를 들면 rendering 제일 마지막 단계인 super sub-samples을 a pixel로 weighted average, 즉 weighted filtering하는데 있어 한 render bucket block 경계면에서는 filter width 값의 범위만큼 이웃한 다른 render bucket block의 경계면의 sub-samples information이 필요한 부분이 그 경우에 해당하겠다.) 그 모든 이유는 효과적인 메모리를 통해 renderman의 독특한 독립성은 그 정말 작은 단위인 micropolygon으로 쪼개어 shading이 가능해졌기에 좋은 양질의 파이널 렌더링을 얻게 되는 것이다. 이런 독립적인 성격을 camera view 밖의 geometry and texture에도 부여 해야만 renderman에서 ray tracing의 성공 할 수 있었던 것이다.

참고로, renderman은 전적으로 visibility를 부분은 primary ray가가  아닌 기존의 REYES algorithm의 scanline rendering방식을 그대로 고수하고(그래서 ray-tracing방식의 lens shader 지원 안함) 옵션으로 ray-tracing이 secondary ray로써그때 그때 요구되는 기능이 필요할때 상황에 맞게 붙어 들어온 것으로 서로의 장점을 정말 잘 조합한 hybrid renderer가 되었다.

다시 돌아와서,
그래서 Renderman에 맞게 ray-tracing을 쓰기 위해 선택하게 된 것이 multiresolution tessellation, multiresolusion geometry cache and multiresolution texture tile cache가 되겠다. 여기서 두가지를 주목 할 수 있겠는데 그 꼭 필요한 데이타들의 multiresolution화 그리고 cache화 일 것이다. multiresolution은 그때 그때 상황(depend on vewing distance, surface curvature, and optionally also view angle)에 맞게 최적화된 데이타를 얻을 수 있겠고 cache를 통해 효율적으로 조직화된 데이타는 memory사용과 lookup에 용이 할 것이다. 다른 것들처럼 bucket block을 위해 완벽한 localization을 하지는 못했지만 제 멋대로 이리 저리로 날아다니는 rays를 생각 했을때 최고의 선택이 아니였나 생각한다.

그럼 이제 Renderman ray-tracing의 꽃이라 개인적으로 부르는 Ray differentials가 나올 차례인것 같다. (이 얘기 하려 쓰기 시작 한것 같은데 서두가 넘 길어진 느낌이....)

위에 그림이 바로 ray differentials을 설명 한 그림으로써 ray를 travel 시킬때 출발지 P점에서 u, v 방향으로 살짝 shift한 각각의 이웃한 두개의 rays를 메인 ray와 함께 travel 시키면 beam의 형태를 가지면서 hit한 지오매트리의 curvature differential 값을 추적해 얻을 수 있게 된다. 이는 curvature-dependent differential로 출발한 지역과 hit한 지역의 geometry curvature differential을 beam size로 얻어 내어 이미 multiresolustion으로 cache화 된 geometry와 texture 데이타에서 각각의 ray에 맞는 최적의 optimization된 싸이즈의 데이타를 끌어다 쓸 수 있고 더 나가 texture filtering까지 얻은 differential value 얻어 쓸 수 있게 만드는 현재로써는 renderman같은 renderer에 가장 이상적인 ray-tracing algorithm for optimization이 아닌가 싶다.