Monday, May 3, 2010

Memory considerations for speed/memory trade-offs in RenderMan

우연히 모 CG싸이트에 답글을 올리다 생각난 김에 memory consumption in renderman에대해 구체적으로 정리를 해 보겠다. 구체적인 주제는 renderman에서 rendering 과정시 motion blur가 memory consumption 측면에서 어떻게 영향을 미치는지가 되겠는데 motion blur는 상황에 따라 너무 다르기에 rendering 외적인 요소는 제외하고 시작 하겠다.

또 하나 일반적으로 알려져 있는 bucket size/maximum grid size를 통한 deal은 어디서나 쉽게 찾아 참조 할 수 있으니 넘어 가겠는데 참고로 하나만 얘기 하자면 bucket size는 rendering 시작부터 끝까지 전반에 걸친 기준이 되지만 grid size는 shading 과정에서 SIMD execution시 계산하는 unit이 되어 shading 속도와 밀접한 관련이 있겠다. (물론 dicing 후의 sub-geometry, 즉 a grid size와도 연관되지만 그리 shading에서의 영향력과 비교 될 정도는 아니기에....) Larger grids require larger temporary variable buffers for shading and produce large increases in the number of active micropolygons.

직접적으로 motion blur와 관련된 유일한 option으로 motion factor가 있겠는데 이는 blur되는 현상에 high frequency shading rate가 그만큼 필요로 하지 않기에 motion path 길이에 따라 shading rate를 높여 shading에 드는 memory, CPU, 비용을 optimization 한 것이다. (Increases shading rate based on length of primitive blur in screen space.) shading rate를 높이면 생성해야 하는 micropolygons 개수는 줄어 들어 shading processing을 좀 더 가볍게 가겠지만 sampling processing에서 생성되는 또 하나의 memory 포식자인 visible-point lists에는 아무런 영향을 주지는 않을 것이다.

무엇보다 간단히 memory consumption during rendering이 많이 이루어지는지 processing 별로 간단히 살펴 보면, 먼저 geometry processing에서는 grids and micropoygons의 개수가 가장 큰 영향을 끼칠 것이고, shading process에서는 각종 image-based caches(예:textures, shadow, etc) and point-based caches(예:point cloud, brick map, etc)와 shading code and variables이 있겠고 마지막으로 memory  포식자인 sampling & hiding 과정시에 생성되는 visible-point lists가 있겠다. 여기에서 rederman의 강력한 특징증에 하나인 Grids and micropolygons are discarded in memory as soon as processed 효과는 memory 공간을 많이 잡아 먹는 visible-point lists를 위한 공간 확보로 이어지면서 renderman만의 효율적인 memory 사용이 가능해 지게 되는 것이다.

자, 그럼 motion blur가 어떻게 memory에 영향을 주는지 살펴보면 우선 shutter angle내에 움직이는 motion path만큼 geometry의 bounding box가 커지면 displacement bounding box가 커지는 것과 같은 이치로 memory를 잡아 먹게 되는데 이는 더 많은 geometry를 dicing과정에 끌어들이게 되면서 memory consumption이 오게 되는 것이다.

여기서 또 하나의 renderman만의 강력한 매력이 있겠는데 shading 과정내에서는 motion blur와 상관없이 똑 같은 계산이 이루어진다는 것이다. shading processing에서 motion blur 때문에 엄청 버거워지는 pure ray-tracing based renderers와 상당히 비교되는 부분이 아닐수 없다.

마지막으로 위에 언급 했던 visible-point lists의 증가가 있겠는데, 이는 motion blur을 쓰게 되면 자연스럽게 sampling rate를 감소 시키면서 samples의 개수가 늘어 나게 되는데, 늘어나는 sample 개수 마다 visible-point lists도 덩달아 늘어 나게 되면서 memory usage를 증가 시킬 것이다. 만약 그 geometry에 transparency가 많이 쓰였다면 기하 급수적인 visible-point lists의 증가는 막을 수 없을 것이다. 이런 transparency geometry가 층층히 쌓이는 대표적인 예가 hair나 fur가 있겠는데 이런 memory 소모를 막고 싶다면 opacity culling threshold로 낮게 설정해 hider에서 opacity culling을 시켜 주어야 한다. 다만 hair에 있는 transparency 효과는 줄어 들 것을 감수해야만 할 것이다. 그렇치 않으면 bucket size를 줄여 주는 수 밖에....

이외에도 memory consumption을 optimization 하는 방식은 rendering 과정 밖에서도 여러가지 찾을 수 있겠는데 간단히 예를 들면 geometry 자체의 optimization, 불필요한 textures and shadow maps의 제거,  mip-map과 tiling이 가능한 caching의 사용 등등등....

hardware, software가 눈부시게 발전하여 rendering 시 더 많은 memory 사용이 가능한다 할지라도 지금까지 보왔듯이 날로 복잡해지는 scene과 photorealistic으로 가는 illumination 방식의 발전으로 지금이나 앞으로도 The issues of running out of memory during rendering은 모든 renderers가 늘 가지고 가야 하는 짐이라 말 할 수 있겠다. 이에 memory usage를 rendering 과정별로 이해하고 있다면 그에 따른 right solutions을 그때 그때 내릴 수 있게 될 것이라 생각한다.

2 Comments:

Blogger shrmrxo said...

안녕하세요. 예전에 인사드렸던 노극태 입니다. 짬짬이 들러 좋은 글 잘 보고 있습니다. 혹 괜찮으시면 Pipe-Line에 대한 견해도 듣고 싶네요.

July 16, 2010 at 11:52 PM  
Blogger horizonfisher said...

헉 죄송! 이제서야 극태씨 코멘트를 봤네요. 파이프라인은 또 다른 큰 세상이라 제가 깊게 접근하기에는 쉽지 않지만 간단한 소개 정도는 언젠가(?) 할까 합니다. ^^

December 7, 2010 at 10:45 AM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home