Galerie's short films

http://www.gobelins.fr/galerie#/?year=null&display=wall&filiere=255943&project=null

 Galerie라는 프랑스 아트스쿨의 학생들 졸업 작품을 올려논 학교 싸이트인것 같은데 (불어라서 이거...)정말 학생들 작품이 맞는지 의심이 갈 정도로 시원시원한 아이디어와 간결하고 탄탄한 composition은 정말 할말을 잃게 만드는 것 같다. 디즈니 스타일에 너무 쩌들어서인가 내 시력이 다시 펴지는 이 느낌은???....

The structure of DOF & 3D motion blur comparing to RenderMan & Mental Ray (2)

(아래 쭈~욱 내려가면 전글이 있으니 먼저 읽어 보시길 바랍니다. 고등학교 화학 선생님이 노트필기 한 것 보고 "너 토끼냐!" 하는 소릴 듣던 생각이 나네요^^)

전글에는 pure ray-tracing rendering에서 DOF와 3D motion blur가 추가 됐을시에 primary visibility ray 개수가 자연 스럽게 늘어나는 실제의 physical적인 구조의 문제 때문에 생기는 비용에 대해 비평(불평)을 썼었고 이제 Renderman에서 마법같이 이 두 effects를 어떻게 트릭해 나갔는지에 대해 써나갈 차례인것 같다.

이것 역시 REYES algorithm architecture의 잇점에서 오는 축복 받은 효과라 말 할 수 있겠는데 micropolygon-based Reyes의 decoupling sampling process가 이번에도 그 이유의 중심에 있겠다고 말 할수 있겠다. 이전글들을 읽어 보면 알겠지만 거의 모든 Renderman의 주요 장점들은 micropolygon-based의 decoupling shading and sampling에서 오는 것을 눈치 챘을 것이다. 그만큼 Renderman rendering algorithm의 heart라 말 할수 있는 부분이 아닐 수 없겠다.

이는 sampling까지 도달 직전, 이전의 모든 rendering 과정에서 이 motion blur를 위해 Renderman에서 해주는 것은 단지 primitives 로 부터 받은 linear moving transformation or deformation transformation만(multi motion sampling이 필요시에는 그 motion path에 key frames도 같이) sub-divided geometry 즉 a grid of micropolygons까지 positional data로 the beginning and the ending of the moving path을 전달시켜 주고 shading 조차 open shutter frame에서 한번만 해주므로 거의 전체 rendering 과정에 부담을 주지 않는 다는 것이다. 결국 beginning and ending의 positional data, 그리고 open shutter frame 때의 Ci와 Oi 값만 한입 가득 문 각각의 모든 micopolygons에대해(그렇다고 shading후 bursted 된 각각의 micropolygons에 그 positional data of motion path를 일일이 주었다고 생각지는 않는다. 예상컨데 상위단위인 a grid 그룹별로 그 데이타를 갖게하고 존속 시켰을 것 같다.)  random time으로 sampling만 해주어 motion blur 효과를 내게 되는 것이다. 오로지 rendering에 부담을 주는 부분은 오브젝트가 움직이기에 anti-aliasing을 위한 sampling 개수의 증가와 더불어 filtering 할 범위의 증가가 요구되는 것과 moving primatives를 rendering되는 bucket block안에 포함시키기 위한 motion path 만큼 bounding box가 커지는 것  뿐이겠다.

Depth of field in Renderman 역시 같은 방식으로 접근을 하는데 다른점은 motion path에 대한 information이 빠지기에 그냥 shading까지 일반 rendering처럼 가다가 shading 끝난 직후 sampling 단계에서 기존의 pinhole 방식이 아닌 lens때문에 발생된 focal length로 인한 DOF 효과를 만들기 위해 shaded micropolygons을 움직여서 효과를 내게 되는데 이는 가상 렌즈, 즉 imaginary lens surface에서 x, y축으로 random한 방향으로 focal plane로부터의 distance에 따라 움직이는 범위가 달라지면서 sampling이 이루어지게 된다. 간단히 compositing tool에서 우리가 anti-aliasing된 z-distance 버퍼를 이용해 blur정도를 콘트롤 하여 DOF를 주는 것과 비슷하다고도 볼 수 있는데 다른 점은 renderman에서는 blur effect가 아닌 shaded micropolygons를 focal plane으로 부터의 z-distance에 따라 움직여 sampling 하여 얻는 다는 것이다.

최근 Renderman 버전에는 기존 depth of field 효과에 lens의 physical 적인 구현이 안됐었던 Bokeh effect가 추가 된것으로 알고 있는데 아직 사용해 보지 않아 뭐라 얘기 하기는 그렇지만 기존의 renderman의 depth of field계산 시간과 그리 차이 나지 않을 것이라고 예상 할수 있겠다.

사실 많은 3D studio들이 비쥬얼적으로 편리한 compositing tool에서 post-process로써 depth of field 효과를 내지 3D rendering에서 같이 쓴다고 생각지는 않는다. Pixar에서 발표한 문서중에 GPU와 연동하여 리얼 타임으로 DOF를 콘트를 하는 것을 얼핏 본 것 같은데 아마도 Pixar는 3D rendering에서 DOF 효과를 주지 않나 싶다.

Comparing Shadow Algorithms including deep shadow maps, traditional shadow maps, and ray-tracing shadow.

Lighting 하면서 가장 많은 문제를 일으키는 부분중에 하나가 shadow가 아닐까 생각 한다. 그런 부분일수록 그에 따른 원리를 이해하고 있다면 문제 발생시 배를 산에 올려 고치는 일은 없을 것이다.

먼저, 가장 오래되고(시대에 처진 느낌은 들지만) 아직도 유용하게 쓸 수 있는 Depth map shadow방식을 얘기한다면, 이는 shadow를 생성할 light를 shadow camera origin으로 놓고 그 camera로부터 해당 object사이의 distance 값, 즉 camera depth 값을 single sample per a pixel, image based buffer로 rendering 후 저장하여 해당 light에서 shadow 계산시 이를 real render camera에서 얻은 depth값을 같은 coordsys로 전환시키고 shadow bias 값만큼 z 방향으로 살짝 밀어 넣어 light에 hit 당한 object의 P 점에서 real render camera에서 본 z values와 대조하여 보다 멀면 light color값을 보다 보다 가까우면 shadow color 값을 가지게 하는방식이다.

70년대부터 쓰던 구닥다리 방식이라 여러 단점을 가지게 되는데 그 중에서도 single sample per a pixel로 비교 해야 할 sample 수의 부족으로 soft shadow를 갖기 위해선 일반적인 texture의 pre-filtering과 달리 선 대조 후 filtering(post-filtering) 과정을 percentage Closer filtering방식으로 aliasing 한 그 depth map 값에서 anti-aliasing 끌어 내어 soft한 shadow를 가지게 만든다는 것이다. 그래서 image based caching임에도 불구하고 위에 얘기 했듯이 sample 수 부족으로 선대조를 해야 하기에 pre-filtering (mip-mapping)의 이점도 못 얻어 먹어 불필요한 메모리 소모에서 대응 하질 못 하고 오직 tiling 효과만으로 미흡적인 메모리 사용에 대용 해야 했다. 그리고 라이팅 아티스트의 최대적인 매번 bias(depth map pixel + bias value)을 상황에 따라 적절하게 조절해야 한다는 것이다. 물론 과거의 하드웨어에서 오는 한계점을 극복한 많은 장점도 (camera view independent, re-usable, simple calculation, decoupling during rendering process, and cinematic flexibility) 많았기에 과거부터 쭈욱 잘 써왔던 것도 사실이다.

(참고로 만약 directional(distance) light shadow depth maps을 렌더링 할때 Auto focus 기능을 썼을 경우 자동으로 geometry의 bounding box를 체크하여 shadow map fame의 범위를 정해 주므로 만약 어떤 지오메트리가 큰 모션으로 shadow 영역에서 크게 움직이거나 필요 없이 멀리 있는 물체가 포함되어 있다면 shadow에 여러 문제점을 일으키는 원인이 될 것이다. renderman을 쓴다면 꼭 local coordsys를 shadow camera와 연결시켜 영역과 위치를 제어하여 쓰길 바란다. 생각외로 이 auto focus기능 때문에 많은 이들이 shadow를 생성 못해 불평하는 소리를 많이 들었다.)

하지만 현시대에 유행처럼 모든 것이 복잡해지고 photoreal로 가는 상황에서 high quality shadows로 가기에는 여러모로 부족하기에 기존의 traditional depth maps방식의 절차상의 장점들을 유지하면서도 상당히 파워풀하게 발전 되어 나온 것이 renderman의 deep shadow maps 방식이다.

이는 위의 traditional depth maps방식에서 거의 모든 단점들을 보완 했다고 보면 될 듯 싶다. x,y plane으로써 보면 무엇보다 single sample per a pixel 였던게 multi sub samples per pixel on a jittered grid가 가능해지므로 pixel보다 작아지는 detailed geometry상황(예: hair)에서 self-shadowing까지 noise artifacts 없이 정확성을 갖게 되었고 z 축으로 보면 z-depth로부터 sampling이 가능해져 visibility functions for each pixel을 계산해 내서  (The visibility function for each pixel is computed by taking a weighted combination of the transmittance functions as nearby sample points) 이를 different visibility function을 각각의 color channel과 함께 저장이 가능하기에 semitransparent surfaces and volumetric primitives(volumetric위한 transmittance functions은 따로 계산 후 합침)의 shadow가 가능하게 되었다. 그리고 traditional shadow depth maps에서 못 하던 prefiltering 즉 Tiling Mip-mapping으로 compression 시켜 caching을 하기에 lookup costs를 효과적으로 줄이게 되며 자칫 늘어나는 데이타량과 메모리관리에 효율적으로 접근 할 수 있게 되었다. 그외에서도 motion blurred shadow 지원 그리고 shadow bias에 좀 더 자유로워진 것 등등이 있겠다.

이런 advanced shadow가 가능하게 된 것은 micropolygon과 함께하는 Reyes Algorithm 있기에 가능 하다고 말 할 수 있겠다. 다수의 samples per pixel과 다수의 depth samples이 요구되는 deep shadow maps에서 shading과정이 없는 한 이런 scanline renderer에서는 traditional shadow depth maps과 비교 했을시 그리 힘든 것이 아니다. decoupling 된 sampling과정과 rendering과정에 이미 생성된 각각의 micropolygons의 z값을 갖다 쓰면 되기 때문이다. Mental ray도 detail shadow라고 말을 조금 바꿔서 나오긴 했는데 아무래도 ray-tracing based라 multi sampling에 한계가 있는 듯하고 자신들도 명확하게 설명을 못해 논것 같다. (써보니 정말 한숨만....)

이 deep shadow maps을 처음 나왔을때 써보고 space chimps에서 다시 사용하게 되었는데 놀랬던것은 traditional shadow map처럼 renderman viewer에서 preview가 가능 했던 것이다. 물론 visibility function value를 볼 수 있는 것은 아니지만 이것으로 troubleshooting에 쉽게 접근 할 수 있게 되었다. 사실 좀더 깊이 있게 이해하고 싶었지만 자료 부족과( 달랑 몇장짜리 픽사의 논문 하나) 이해력 부족, 특히 visibility function를 transmittance function이 어떻게 해나가고 filtering은 거기에 어떻게 적용 되는지 아직도 모르겠다.

위의 shadow map based 방식과 가장 많이 비교되는 Ray-tracing based shadow 방식은 빛과 그림자의 물리적인 성질에 가깝게 직관적으로 만들었기 때문에 코딩자체가 보다 간단하고 straight-forward 하다고 볼 수 있다. 가장 정확한 shadow를 얻지만 그런 만큼 이런 저런 단점 또한 갖게 되고 때론 너무 정확해서 문제가 된다. 원리를 간다히 얘기하자면 빛이 닿은 surface의 P점에서 역으로 ray를 light source를 향해 쏠 때 만약 다른 object에의해 block 되었다면 shadow color 값을,아무 거침 없이 light source까지 도달 한다면 illuminated shading 절차로 넘어 가게 될 것이다. soft shadow를 위해서는 distributed multi-sample rays를 쏴서 hit test를 해야 하는데 전에 언급을 했기에 생략 하겠다.

간단히 point light emitter에서 single ray만 쏠 경우는 지나치게 비현실적인 sharp한 shadow가 생성될 것이고 area light emitter에서 soft한 shadow를 생성하고자 할 경우는 콘볼륨의 다수의 rays를 light emitter를 향해 쏘아 blocking hit test를 해야 하기에 rendering time은 드라마틱하게 늘어나게 될 것이다.(전에 area light shadow의 계산 방식에 대해 얘길 했기에 여기선 생략 하겠다.) 게다가 ray-tracing shadow 연산은 rendering과정에서 구조상 가장 복잡한 shading 과정 내에서 계산을 하게 되므로 rendering시 메모리부터 CPU에까지 상당한 무리를 주게 되고 cinematic lighting flexibility에 자유롭지가 못하고 재사용이 가능한 상황에서도 재계산을 해야 하므로 비효율적인 소비가 이루어 지게 된다.

알겠지만 camera view dependent로 illuminated된 object가 camera가까이 오기라도 한다면 계산해야할 P점 개수가 늘어나기에 당연히 느려지겠고 반면 camera에서 멀어져 작은 빛 받는 면적이 적어 지면 depth shadow 방식보다 더 빨른 계산을 할 수 있게 될 것이다.

마지막으로 shadow의 종류라고 개인적으로 주장하지만 light emitter와 상관없이 독립적으로 계산되는 ambient occlusion과 reflection occlusion을 얘기 하면 원리는 multi-samples로 hit test를 하는 area light shadow algorithms과 비슷하겠지만 light emitter를 향해 쏘는 대신 전자는 surface normal을 중심으로 즉 R= normalize(faceforwad(N, I):을, 대신 후자는 R=reflection (I, N):를 써서 마지막에 hit한 ray의 개수를 총 ray 개수로 나누기 해서 얻은 퍼센트지 값의 invert 값을 luminance 값으로 쓰게 하는 방식이 되겠다. (개인적으로는 wrap light의 shadow를 위해 ambient occlusion 계산 방식으로 쓰고 있다. intersection test시 shading의 Oi 계산이 없기에 더 빠르다.)

(에고~ 이거 숨차네.)

26 gigapixel Paris

http://www.paris-26-gigapixels.com/index-fr.html

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이 아닌가 싶다.

故 법정스님 삼가 명복을 빕니다.

모든 분들에게 깊이 감사드린다.

내가 금생에 저지른 허물은 생사를 넘어 참회할 것이다.
내것이라고 하는 것이 남아있다면 모두 맑고 향기로운 사회를 구현하는 활동해 사용해 달라.

이제 시간과 공간을 버려야겠다.

법정스님은 머리맡에 남아 있던 책을 약속한 대로 스님에게 신문을 배달한 사람에게 전해줄 것을 상좌에게 당부했다.

절대로 다비식 같은 것을 하지 말라.
이몸뚱아리 하나를 처리하기 위해 소중한 나무들을 베지 말라.
내가 죽으면 강원도 오두막 앞에 내가 늘 좌선하던 커다란 넙적바위가 있으니 남아 있는 땔감 가져다가 그 위에 얹어 놓고 화장해 달라.
수의는 절대 만들지 말고, 내가 입던 옷을 입혀서 태워 달라.
그리고 타고 남은 재는 봄마다 나에게 아름다운 꽃공양을 바치던 오두막 뜰의 철쭉나무 아래 뿌려달라.
그것이 내가 꽃에게 보답하는 길이다.

어떤 거창한 의식도 하지 말고,
세상에 떠들썩하게 알리지 말라.
그동안 풀어놓은 말빚을 다음 생으로 가져가지 않겠다.
내 이름으로 출판한 모든 출판물을 더 이상 출간하지 말아주기를 간곡히 부탁한다
사리도 찾지 말고, 탑도 세우지 말라고

당부하셨습니다....

What is Micropolygon?(2)

(밀린 글 쓰는 느낌이.....)
전 글에서 micropolygon은 사변을 가지고 있는 bilinear patch라고 했다. 보통 ray-tracing기반의 renderer에서 빠른 intersection test를 위해 triangle mesh을 shading & rendering 최소 단위로 쓰는 것과 상반되는 부분이 아닐 수 없다. 삼각 폴리곤은 언제나 절대적으로 구부러짐 없이 flat 하기에 intersection 된 point에서 한결같은 color값을 shading에서 얻을 수 있는 반면, 사각의 micropolygon은 ray-tracing을 위한 intersection test가 필요 없었기에(지금은 아니지만) parametric geometry에서 sub-divide가 더 용이한 사각을 선택 했고 경우에 따른 non-flat 상황 즉 구부러지면서 생성되는 error는 pixel보다 작아지는 상황에선 아무런 영향을 미치지 못 하기 때문에 그냥 무시하게 된다.

참고로, ray-tracing의 심장인 intersection test는 세 점으로 구성된 triangle mesh상태에서 가장 효율적인 계산이 이루어지기 때문에(참고로 triangle mesh보다 더 빠른게 ray-tracing 계산이 이루어 지는 곳은 normal과 distance, 즉 disk 형태로 구성된 point cloud에서 가장 빠른 계산이 이루어진다고 한다. 이렇게 따지면 bounding box 상태에서가 가장 빠르겠지만....) 다소 투자가 이루어져도 preprocess로 convert to triangle mesh or polygon을 하게 되는 것이다. intersection test 계산시 메모리, 그리고 시간적인 부담감은 모든 geometry를 큼직한(?) 삼각 폴리곤으로 전환해서 쓸 수 밖에 없게 되면서 부족해진 곡율적 부담감은 shading interpolation에 의지하게 되는 것이다.  

다시 micropolygon으로 돌아와서, 위에서 sub-divide에 가장 효율적이기에 bilinear patch를 쓰게 되었다고 했다. 이는 모드 종류의 geometry에 해당하는 것은 아니고 parametric geometry 즉 u.v을 기준으로 쉽게 divide가 가능한 것과(나무 결을 따라 자를때 가장 쉽게 잘라 지는 것과 같은 이치라고 생각하면 좋을 듯^^) 그리고 quad based로 가장 renderman과 궁합이 잘 맞게 쪼개버리는 catmull-clark sub-division meshes가 이에 해당 될 것이다.

여기에 시대의 반항아 같은 존재인 삼각 polygon은 micropolygon으로 전환 시키는데 가장 골치 덩어리로 다른 것에 비해 계산이 가장 오래 걸릴 뿐더러(결국 어거지로 가운데 중심점을 만들어 거기서 부터 각 세개의 포인트와 연결해 3개의 micropolygon으로 쪼개 나감) 기술적으로 곡율적인 형태를 지원 안하기에 쪼개는 의미도 없어 진다. 이런 저런 단점이 있음에도 아직까지 polygon이 많이 쓰이는 이유는 modeling tool에서 다루기 쉽고 연관된 다른 작업에 용이 하기 때문이다.

위의 글을 잘 읽어 봤다면 renderman에서 어떻게 해야 가장 효율적으로 geometry를 rendering까지 잘 이끌어 갈 수 있는지 이해 했으리라 생각한다.

Micropolygon processing은 무엇보다 sampling과정을 shading으로부터 독립 시켜주는 중추적인 역할을 하는 일등 공신으로 RenderMan같은 micropolygon-based renderer에 그들만의 독특하고 강한 특징들을 가질 수 있게 해 주었을 뿐만아니라 deep shadow maps이라든지 최신의 point-based 방식의 illumination 계산을 위한 caching 까지 다 micropolygon processing이 받쳐 주기에 가장 효율적으로 사용이 가능해 졌다고 말 할 수 있겠다.

RenderMan is very efficient at generating point clouds because of the way the REYES algorithm dices geometry.

Good explanation of a traditional scanline rendering

A traditional scanline renderer begins by projecting the bounding box for each primitive onto the screen to determine the rectangle of pixels potentially covered by that primitive. A pointer to the primitive is stored in the first scanline in the bounding rectangle. Rendering takes place one scanline at a time, starting at the top. At each row, new primitives are added to an active Y list. The primitives in the Y list are then bucket-sorted in X. To render a row, the renderer marches from left-to-right, maintaining an active list of primitives as it goes. At each pixel any new primitives are added to the active list, which is maintained in Z-order. The pixel is then rendered by processing primitives in order from front-to-back.


이 짧은 글안에 traditional scanline renderer의 전체 프로세스를 정말  잘 정리해 논 글이기에 올려 본다.

Digital Painting (2)

  Dancing light in the bathroom in 2006

Digital Painting (1)

At the English Bay in 2005

아직까지 유화 냄새가 더 익숙한(익숙함보다는 이젠 향수적인 그리움에 더 가깝지 않을까나?) 나에게 디지탈 페인팅은 또 다른 도전보다는 편리의 의해 그리고 환경의 요구에 의해 가게 되는 것 같다. 이런 저런 기능의 매혹되기 보다는 손끝 감각으로 부터 오는 건조한 답답함이 불만으로 다가오게 하는 것 같다. 

지금 회사에서 기회가 되어 잠깐동안 matte painter로써 도와 준적이 있는데 타블렛 펜 끝으로 이어지는 나의 감각이 간질거림으로 내 손바닥을 자꾸 자극했었던게 기억난다. 디지탈세상에 아날로그의 감수성을 기대한 내 탓도 있겠지만 그리 유쾌한 느낌은 아니였다. 게다가 강한 붓터치를 좋아 했던 내게 photorealistic의 붓 질, 아니 타불렛 펜 질을 요구하는 matte painting은 익숙하지 않은 부분이였다. 나름 많은 매리트가 있는 부분이고 계속 진행 하고 싶은 부분이라 생각하지만 아직까지는 디지탈 붓에 적응 하기에는 시간이 더 필요한것 같다. 다른 한편으로는 기술적으로 더 빠른 Digital painting 환경의 발전을 기대하고 있다.