Happy New(설) Year with the 2012 Resolution!

아직까지 나를 대표 한다는 몇 분짜리 영상은 회사에서 셋업해준 텍크닉이 범벅되어 그들 보기 좋게 포장된 데모릴뿐이라는게 안타깝다. 내가 평가 될 때 내가 속 한 /그 /곳/이 평가 기준이 된다는 것 또한 거절 하고 싶다. 달콤한 그 알을 깨고 나와 알몸으로 스스로를 먼저 평가하는게 순서 이기에 이제 두손 모아 금간 자리를 두둘겨 볼까 한다. 새 둥지를 튼 이곳 뉴욕에서 나와 같은 생각 하는 사람들을 만났다는 것만으로도 앞으로 벌어질 일들에 흥분하기 시작했다.

131년 역사의 코닥

131년역사의 코닥이 위태롭다고 한다. 디지탈 시대에 빠른 대응을 못 했서라고 하지만 코닥이 가진 100년된 항아리에 서식하는 곰팡이에서 깊게 우려 나온 칼라재현기술을 아직 디지탈이 대체하기에는 넘 빠르지 않나 싶다. 디지탈 칼라발전을 위해서도 늘 같이 공존하며 함께 가야 하는데 많이 많이 안타갑다.

Radiance knowledge database

http://www.radiance-online.org/

Radiance is a quantity in Physics (like voltage or length), specifying the amount of energy radiated in a given direction from a surface. Mostly used with non-ionizing, electromagnetic radiation in the visible spectrum (light), ultra-violett (UV) or infrared (IR). More precisely, it's defined as radiated power over solid angle and "projected" area, the SI unit being [Watt/(m2 sr)].

Radiance is also the name of a physically based rendering package written largely by Greg Ward, initially at LBNL, EPFL, then SGI, now running Anyhere Software. It is a physically-based, image-generating, backward raytracer with very a powerful rendering engine. It is used worldwide for lighting analysis and can generate accurate values for radiance/luminance (W/sr.m²,cd/m²) and irradiance/illuminance (W/m,Lux).

Radiance라는 physically-based spectral rendering으로 방식을 추구하는 renderer를 중심으로 spectral color rendering 전반에 대한 학술적인 정기모임에서 발표 했던 자료들을 정리 해 올려 논 싸이트다. 프로덕션에서 굴리기에는 아직 너무 앞선 방식이지만 멀지 않은 미래의 거의 모든 renderer들의 목표가 되는 physically-based accurate color reproduction의 구심점이 되지 않을까 한다.

Two important notes for shading:'Surface Reflectance Recognition and Real-World Illumination', and 'Making Shaders More Physically Plausible

Surface Reflectance Recognition and Real-World Illumination:
http://ssg.mit.edu/ssg_theses/ssg_theses_2000_2009/Dror_PhD_8_02.pdf

Making Shaders More Physically Plausible:
http://www.tricity.wsu.edu/cs/boblewis/pdfs/1993_plausible.pdf

Illumination shading models에 관심이 있다면 위의 두 노트는 /반/드/시/ 읽어야 할 목록이 될 것이라 본다. 1993년에 쓰여진 두번째 노트는 이제서야야 ILM을 선두로 바꾸기 시작한 Physically-based shading models in terms of Energy Conservation에 대한 토대가 된 노트이다. 듣기로는 이번 RenderMan Pro Server 16.0에도 추가 된 것으로 알고 있는데 앞으로 거의 모든 Renderer들의 energy conservating shading model의 형태로 발전 되어 진다는 것에 의심의 여지가 없다고 본다. 아쉽게도 이 노트는 너무 원리 위주의 수학적 풀이로만 설명해 나서 보다 쉽게 설명한 'Crafting Physically Motivated Shading Models for Game Development' by Naty Hoffman와 같이 보는게 좋을 것 같다. 사실 기존의 phong, blinn에서의 specular BRDF 방식과 a normalization factor를 사용한 Energy Conservating shading models에서 수학적 계산의 차이는 그리 크지 않아 보인다.

우리의 무지에서 못 쓰고 있었던 것이 분명한 것 같은데.... 17년전부터 Robert Lewis가 고치라고 얘길 했건만.... 이유는 아티스틱 관점의 작업 방식이 주를 이르며 만든 그럴 듯한 결과물에 만족해 왔었고 low dynamic range가 illumination 시작점부터 rendering equation을 지배 했었기 때문에 골치 아프게 쓸 필요성을 못 느끼고 있었던 것이다. 지금같이 반토막짜리이긴 하지만 HDRI를 input의 한 영역으로 쓰는 이 시대에선 아티스틱 방식으로 풀기에는 오류의 범위가 점점 커져 가기 때문에 점점 이슈가 되어가는 것이다. 당연 과학적인 접근 방식이 전적으로 필요로 한 부분이라는 것을 명심하길 바란다.

Visualizing the XYZ Color Space by Sony imageworks

http://www.youtube.com/watch?v=x0-qoXOCOow&feature=BFa&list=FLq3PIgs1JABA&index=19

Color space의 standard는 RGB-based가 아니다. RGB color space는 final output for a display를 위한 것이지만 아이러니하게도 다루기 편하고 직관적이라는 이유로 지금 거의 모든 2D뿐만 아니라 3D CG imaging systems을 장악하고 있다. 게다가 사무용 컴퓨터 모니터에 맞춰 HP와 MS에 의해 표준화된 sRGB의 무서운 보급은 알게 모르게 우리가 그 좁은 color gamut에 놀아 나게 된다는 것이다. output-referred RGB color space 상황에서 작업의 최대 단점은 터치를 하면 할 수록 realistic look에서 멀어져만 간다는 것이다. 이유인즉, 이미 칼라로써 고유의 빛 성질을 잃어버려 display에 맞춰 mix 되어 버린 최종 output용 color values이기 때문이다. 다시말해 위해서 말했듯이 output-referred, 혹은 device-dependance이기 때문이다. 후반작업에 있어 아트스트들의 무모한 열정에 적절한 제한이 필요한 이유이기도 하다.

예를 들면, 흔히 photoshop 혹은 typical compositing tools 같은 RGB color space based에서 contrast를 조절하는 방식이 잘 못 되어 있다면 믿을 수 있겠는가? illumination 관점에서 contrast는 light photon의 총 amount를, 즉 luminance value의 range만을 특정한 중간값을 기준으로 줄여 만들어야 하지만 RGB color space에서는 RGB values 전부를 동시에 바꾸므로 color의 saturation 까지 영향을 받게 만드는 것을 쉽게 볼 수 있다. 게다가 sRGB상태라면 숨은 gamma 값까지 영향을 끼칠 것이다.

반면 CEI XYZ color space는 absolute device-independance로 color spaces의 standard라고 볼 수가 있겠는데 특히 우리 눈이 볼 수 있는 color gamut 전 영역을 표현 할 수 있고 다른 color space로 conversion이 쉽다는 장점이 있다. 특히 또한 spectral energy가 RGB color로 전환시에 생기는 negotive color values에서 자유롭고, 그리고 output-referred representations가 아닌 scene-referred라는 것. 이런 저런 이유에서 color enhancement가 요구되는 후반작업시, 특히 color grading for digital film 작업시  RGB color space 보다 효율적인 작업 환경이 아닌가 싶고 몇몇 하이엔드급 툴들과 거의 모든 digital camera의 image processing은 XYZ color space를 쓰고 있는 것으로 알고 있다.

FilmLight Color Workshop

http://www.youtube.com/watch?v=LuPTmpioROk&feature=related
http://www.youtube.com/watch?v=jd2sawwHpQI&feature=related
http://www.youtube.com/watch?v=ONH8VrlesRA&NR=1

몇년전 인터넷 뉴스에서 위 workshop동영상 회사인 FilmLight의 truelight color management system을 ILM에서 쓰기 시작 했다는 소식을 들었다. color system은 처음 light가 spectal color를 as input으로 보내는 시작점부터 그 light photon과 wavelength가 coloring 과 imaging 그리고 color enhancement 과정을 거쳐 마지막 final output for a particular display로 손실 없이 안전하게 color gamut과 tone을 RGB values로 전환 될때까지 전체 과정을 관장해야 하는 중요한 base system중에 하나가 아닐까 한다. 아쉽게도 아시아에 있는 CG 스튜디오들이 이런 부분에 상당히 약하다는 것을 알고 있다. 뭐 여기도 큰 스튜디오 빼고는 상황이 같다고 본다. 그런 중요성을 누구보다 더 잘 알고 있는 ILM이 쓴다는 얘기는 그만큼 믿음을 주지 않을까 한다. 출처는 모르지만 그 회사에서 했던 color workshop 동영상 인것 같다. 이쪽 공부를 하면 할 수록 coloring pipelines & systems이 얼마나 중요한지를 인지 안할수가 없고 반면 3D CGI에서 그간 얼마나 무성의하게 해 왔는지도 알게 되는 것 같다.

The lost thing (short film)

http://www.thelostthing.com/

한국을 떠나기 전에 마직막으로 샀던 그림 책이 이 The lost thing 이였었다. 그간 까맣게 잊고 지내다 요 며칠전 오스카 단편 부분 수상작이라기에 봤더니 그 잊고 지냈던 그림들이 움직이고 있었던 것이다. 색다른 감동이랄까? 내게 the lost thing은 한국에 두고 온 책이 아닐까 한다.

애니메이션에서 정말 무엇이 중요한지를 다시금 일깨워 주는 듯 하다. 무엇보다 헐리우드의 뒷 모습만 쫓으려 하는 세계적인 추세에 우리에게 좋은 방향을 제시 해 주지 않았나 싶다.

Radiometry and photometry (from light to color)

Radiometry is the science of physical measurements of electro-magnetic quantities such as the energy or power of radiation. It measures the amount of light at each wavelength using the SI unit of power[watt =W] and is concerned with the flow of light through the environment.

Photometry is the name for the science that deals with this psychophysical perception of light. Radiometry only deals with objective quantities which can be measured in standard SI units. On the other hand, the response of the human visual system varies strongly with the wavelength of the radiation.

Because the eye has a different relative sensitivity for radiation at different frequencies, we must translate radiometric quantities to the equivalent photometric quantities. This mapping is described by the luminous efficiency function V. It translates between the radiant power measured in watt[W] and the luminous power measured in lumen[lm]. The units of the function V are therefore [lm/W].


"light는 color다! color도 light다!."
과거 내 머리속을 지배해 왔던 정의 중에 하나 였다. 처음 lighting을 이해하는데 도움을 줄지는 모르지만 위의 글에서도 볼 수 있듯이 오류를 유도 할 수 있는 잘못 된 정의이다. CGI 관점에서 바라 봤을때 자칫 크나큰 오류를 안고 가게 되는 것도 같다.

color space와 light(illumination) space는 서로 다른 공간이며 존재하는 방식 또한 다르다. 하지만 sensors라는 conversion을 통해 연결되는데 그냥 linear하게 전환 되는 것도 아니다. 이런 미묘한 response & transfer functions in terms of human visual perception을 알아내는 것이 foundation of color science의 묘미 중에 하나가 아닐까 생각 한다.

Unit Problems with tone-mapping in RenderMan

from 'Using procedual RenderMan shaders for global illumination'


All color and illumination quantities are unit-less and are supposed to lie between zero and one. It makes all computations context dependent and may introduce inconsistencies when combine shaders that assume a different environment.Secondly, all specifications are relative to an implicit unit system imposed by the creator of the scene. For example, it's impossible to add a light source with a particular lighting effect to a scene without knowing the overall scale factor of the other light sources.

RenderMan currently only deals with unit-less color values to describe illumination. In order to make shaders compatible with each other and with any renderer we suggest that all quantities used in the RenderMan interface are assumed to be given in international standard SI units. This means that all geometric quantities are in meters and that radiance or irradiance is used for all illumination quantities.A light source shader for a point light source must scale the light flux with the square of the distance to the receiver. The effect of the light source is now independent of the assumed scale of the scene model.

For illumination quantities the photometric units luminance and illuminace would have been an alternative. However, they are a subjective measure and are simply scaled versions of the radiometric units, weighted with the spctral response function of a standard observer.

The current definition of the imaging pipeline of RenderMan must also be modified in order to perform post-processing on the image in physically well-defined units. These extensions are necessary to support the current state-of-the-art in physically-based image synthesis. This includes tone-mapping operators and image filtering.

In the current definition of the RenderMan interface the imaging pipeline can only execute a set of standard filter algorithms. Also, image shaders currently operate on the already filtered and gamma corrected pixel values and image shaders operate on the value of a single pixel at a time. A tone reproduction step which converts the radiance values into pixel values through luminace values for display is unavoidable. For rendering scenes with physically-based light sources descriptions and reflection functions, the large dynamic range of the input distribution must be matched to the rather small dynamic range displayable by a CRT.


RenderMan에서 전체 color processing을 좀 더 physical하게 접근 한 시점에서 봤을때 안고 있는 몇몇 문제점을 제시한 중요한 노트 중에 하나가 아닐까 생각한다. 제목만 보면  procedual shader와 연관된 GI에 대한 내용일거라 생각 했지만 안의 내용은 오히려 내가 원했던 부분이 한가득 들어 있었다.

How bright is the sun?

46,334 times brighter than “white”

What do you think? Have you ever considered why we use normalized light intensity value in 3D rendering? The answer is not as simple as it seems like. This is one of my challenges these days. Good luck myself!

이해와 앎,

교육에서 '무엇'과 '어떻게'의 결별은 곧 어떤 것을 '안다'는 것과 '이해한다'는 것이 분리되는 결과로 나타난다. 학생들은 이해함으로써 앎에 이르는 게 아니라 외움으로써 알게 되는 것이다. 어떤 것을 '이해'하지 못한다는 것은 그것을 실제로 '어떻게' 응용해야 할지를 모른다는 것이며 그것을 '어떻게' 다루어서 새로운 것을 만들어내야 할지를 모른다는 것이다. 그런 지식은 실로 허약하며 쓸모없고, 교육적 실패의 결과물에 불과하고 겉만 번지르르한 '학문적 성취'의 외장일 뿐이다.
-출처 미상-

Photographic Optics

http://toothwalker.org/optics.html

Here is a collection of illustrated articles on the chief causes of image degradation in photography. Currently available pages can be accessed via hyperlinks. The reader should keep in mind that the articles are about principles of photographic optics and not about tests of specific lenses. Also, most of the phenomena have been captured on film. Since a film acts as no more than a light-sensitive medium, the examples equally apply to a digital recorder array. In the few cases where the nature of the recording medium is important, this will be emphasized.

Everything is linked.

http://www.youtube.com/watch?v=jqxENMKaeCU

이 시대에 사는 모든 이들이 꼭 봐야 할 영화가 아닌가 싶습니다.
인간이 주인이 되어서는 안 될 우리의 /Home/ 입니다.

SIGGRAPH 2010 Course: Physically Based Shading Models in Film and Game Production

http://renderwonk.com/publications/s2010-shading-course/

Physically grounded shading models have been known for many years, but they have only recently started to replace the "ad-hoc" models in common use for both film and game production. Compared to "ad-hoc" models, which require laborious tweaking to produce high-quality images, physically-based, energy-conserving shading models easily create materials that hold up under a variety of lighting environments. These advantages apply to both photorealistic and stylized scenes, and to game development as well as production of CG animation and computer VFX. Surprisingly, physically based models are not more difficult to implement or evaluate than the traditional "ad-hoc" ones.

특히, ILM & Sony Pictures Imageworks course notes는 현재 production rendering과 관련해 우리가 어디에 위치해 있는지와, 앞으로 어떤 길로 갈지를 가늠하는데 있어 꼭 읽어 봐야하는 필수 노트라 할 수 있겠다. 

Ideal texture filtering,

Ideally, computing a textured value for a pixel involved perspective projecting a filter from screen space (indexed by x and y coordinates) to obtain a warped prefilter. Since the texture data are discete samples, we also require a reconstruction filter to interpolate between texel samples. For mathematically tractable warped and reconstruction filters, we can combine the two to create a unified filter in texture space. Each texel inside the unified filter's footprint is weighted according to the unified filter's corresponding value in screen space, the weighted samples are accumulated, and the sum is divided by the filter's volume in texture space.


rendering 과정의 거의 모든 부분이 point sampling process이기에 aliasing은 늘 동반되는 문제이다. 그중 texture pre-filtering 부분은 rasterizing과정인 rendering sampling process와 달리 세개의 공간을 오가며 sampling이 이루어 지는데, 즉 screen space, uv parameter space on the surface 그리고 st texture space이 되겠고 서로 다른 두개의 sampling processes인 the screen space samples and the shading samples in parameter space on the surface을 통해 얻는 모든 결과물이 texture space function에서 이루어 져야 한다는 문제점을 가지게 되겠다.

故 콘 사토시 감독

http://oppicul.tistory.com/1291

일본도 열약한 애니메이션 환경의 현실에 재능 있는 애니메이터가 점점 줄어 드는 상황에서, 그나마 일본 애니메이션을 이끄는 몇몇의 재능 있는 감독중에서 한명인 그의 비보는 본적도 만난적도 없지만 그가 불어 넣은 숨결의 애니메이션을 본 것만으로도, 보면서 같은 호흡을 했다는 것 만으로도 가까운 가족의 비보를 들은 듯이 옆구리가 시려 옵니다. 그의 가족과 그를 사랑 했던 사람들과 그 슬픔을 같이 하고 싶습니다.

Global Illumination in 99 lines of C++

http://www.kevinbeason.com/smallpt/

Features

• Global illumination via unbiased Monte Carlo path tracing
• 99 lines of 72-column (or less) open source C++ code
• Multi-threading using OpenMP
• Soft shadows from diffuse luminaire
• Specular, Diffuse, and Glass BRDFs
• Antialiasing via super-sampling with importance-sampled tent distribution, and 2x2 subpixels
• Ray-sphere intersection
• Modified Cornell box scene description
• Cosine importance sampling of the hemisphere for diffuse reflection
• Russian roulette for path termination
• Russian roulette and splitting for selecting reflection and/or refraction for glass BRDF
• With minor changes compiles to a 4 KB binary (less than 4096 bytes)

사실 Ray-tracing engine기반의 renderer 만큼 straightforward 한건 없는데 path tracing을 이렇게까지 간단해 질 수 있는지는 몰랐다. 물론 불필요한 부분은 다 잘라 냈으니 그렇겠지만 위의 features에서 보듯이 필요한 중요한 부분들은 거의 있다고 볼 수 있다. 게다가 단순화된 오픈소스라 path tracing 기반의 GI renderer가 어떻게 연동 되는지 이해하는데 많은 도움이 될 것이라 생각 된다.

이번 siggraph 2010, production부분에서 이미 소개 되었 듯이 path tracing 기반의 GI rendering 방식은 sony pictures를 중심으로 헐리우드 퀄러티 스튜디오에 들어와 자리를 잡았고 하드웨어의 발전에 따라 점점 확대해 나간다는 것에 대해서 의심의 여지가 없는지라 관심을 기울어야 할 필요가 있다.

How interreflections can affect color appearance.

Most studies of surface color appearance have ignored 3-d illumination phenomena such as shadows and interreflections. How interreflections can affect color appearance. How the lightness, hue, and chroma of the reflected color signal vary with the concavity aperture. The color appearance of a surface depends on both the spectrum of the illuminant and the spectral reflectance of the surface.

개인적으로 많은 시간을 갖고 생각했던 부분이지만 이 노트는 가다 멈춘 느낌이....

Signal processing with post-filtering in RenderMan (1)

3D Rendering algorithms에 대해 깊숙히 들어가다 보면 renderer 성격과 상관없이 어디에서나 만나게 되는 것중에 하나가 이 signal processing과 연관된 anti-aliasing이 아닐까 한다. 넓게 보면 2D, 3D를 떠난 모든 raster computer graphics 전반에 걸쳐 있을 뿐만 아니라 3D CG rendering 과정은 물론이고 연관된 여러 illumination algorithms에 있어 중요한 부분이 아닐 수가 없다. 더나가 이런 signal processing에서 파생된 spherical hamonics 원리를 이용한 여러 illumination 효과까지, 그 이해의 필요성은 말 할 것도 없을 것이다.

Rasterization, 즉 The process of generating an image from a model in raster-space로 간단하게 Rendering in 3D computer graphics을 정의 할 수 있 듯이 결국 original signal with vector information in 3d space을 raster-space로 perspective projection 시키는 point sampling의 최종 목적지, 즉 the intensity of the image at some X-Y coordinate point within the pixel로 가면서 aliasing은 늘 따라 다니는 동반자가 될 수 뿐이 없게 되지만 우리 눈이 capture 할 수 없는 영역 밖으로 그 aliasing을 minimalize 시키므로 극복해 나갈 수 있게 되는 것이다. 그 중 오늘은 signal processing과 연관해서 point sampling 후 이어지는 post-filtering에 중점을 두어 얘기를 시작 하도록 하겠다.

먼저 일반적인 rendering in 3D CG에서 signal precessing을 전체적으로 크게 보면 아래와 같을 것이다.

original signal -> pre-filtering -> point sampling -> post-filtering -> final pixel.

Original signal을 sampling and reconstructing을 통해 aliasing 없이 최종 pixel에 도달하게 만들어야 하는데 있어 가장 중요한 목적은 low frequency signal은 손실 없이 그리고 aliasing의 주범인 high frequency signal을 aliasing and detail lose 사이에서 가장 적절하게 capture하여 pixel로 reconstructing을 하는데 있다고 볼 수 있겠다.

Nyquist frequency theory (It has to be sampled at more than twice the frequency of the original signal.)에 의해 A pixel안에 다수의 samples(surper-sampling, sub-sampling 혹은 multi-sampling이라고도 함)을 capture하게 되는데 이는 up sampling으로써 high frequency data까지 capture가 가능하게 되지만 여러 aliasing errors을 피하기 위해 다시 역으로 low pass filtering을 통해 down sampling 하게 하므로 그 capture 해온 high frequency data에서 생기는 aliasing을 막는 동시에 lower frequency data는 잃지 않게 하면서 amplitude(color) reproduce를 해야한다. 그래서 rendering에서는 weighted average of samples from both inside and outside the area covered by the pixel 로 post-filtering을 해주게 되어 final pixel를 얻게 되는 것이다.

여기서 위의 up sample된  sub-samples를 filter weighting function을 거쳐 가게 하는데 있어 이런  signal(data) 다루기 편한 상태로 만들어야 하는게 우선시 되겠다. signal은 읽혀지는 방식에 따라 time domain(CGI에서는 observing signals in sptial domain, like as pixels on a screen)과 frequency domain이 존재 하는데 대부분의 신호 처리는 연산량과 편리함을 위하여 fourier transform(fft)을 통하여 time(or spatial) domain을 frequency domain으로 변환 혹은 inverse Fourier transform 후 계산을 하게 된다.

Fourier theory states, that a periodic signal can be seen as a sum of sine waves with different ferquencies, amplitudes, and phases. More important is to understand that some operations are much easier to do in the frequency domain than in spatial domain, and vice versa.

즉, time(spatial) domain은 가로축이 time(space)이고 frequency domain은 가로축이 주파수가 되는데 (세로축은 amplitude(color)) 따라서 spatial domain에서는 time(space)에 따라 신호가 어떻게 변하는지를 볼수 있고 frequency domain에서는 이 신호에 각각의 주파수 성분들이 얼마나 많이 들어 있는지를 볼 수 있게 된다.

이는 filtering 시 그 signal은 frequency domain 안에서 쉽게 higher frequency data를 없앨수 있지만 time(sparial) domain에서는 그리 쉽지가 않다. 그래서 filter weighting function(weighted average of the signal in the area of the pixel)는 Fourier transform 통해 frequency domain로 전환후 적용을 하게 되는 것이다. Frequency domain에서 가장 이상적인 filter의 모습은 step 형태가 되겠는데 이는 간단하게 higher frequency signals을 lower frequency data의 손실 없이 제어를 하게 되겠다.

To perform the filtering, we need to calculate the distance from the center of the pixel being filtered, to each sample point location, and use that to get a sample weight. The data for that sample is then accumulated using the weight. When the samples have all been processed in this way, the result is divided by the total weights of all samples that contributed and this will be the final data stored on the pixel, and passed onto the exposure stage. 

다음 글에는 RenderMan과 직접적으로 연관해서 post-filtering에 대해서 한번 살펴 보도록 하겠다.                    
계속.....

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을 그때 그때 내릴 수 있게 될 것이라 생각한다.

Pixar’s Ed Catmull

"I don’t like hard rules at all. I think they’re all bullshit."

http://www.scottberkun.com/blog/2010/inside-pixars-leadership/

32 bit depth and super-whites as output for compositing

넓은 의미의 Compositing은 3D space에서 이루어지는 models와 lights의 illumination 현상을 rendering을 통한 2D space의 image-based caches로 매체의 전환후에 이루어지는 illumination + alpha의 연장선(post-process)이라 말 할 수 있겠다. signal processing 측면에서 본다면 point sampling-based process에서 pixel imaging-based process로 매체 전환과 3D space에서 2D space의 공간 전환으로 생기는 Aliasing errors을 최소한으로 줄이며 연결 시켜야 3D rendering 부터 시작된 그 data의 저니가 compositing 후 final output 도착 할때까지 손실 없이 성공적으로 이루어 질 것이다.

공간적인 측면의 전환으로 생기는 여러 aliasing errors는 3D rendering 과정 내부에서 효과적인 sampling과 reconstructing으로 최대한 최소화 시키 넘겨 주지만 point sampling-based process에서 pixel imaging-based process로 전환으로 오는 aliasing은 지금부터 얘기할 부분이 될 것 같다.

우리는 최대한 3D rendering 당시의 모습 그대로의 data를 image에 담아 내야 하지만 하드웨어의 한계와 display devices에 맞춘(gamma까지!) 기존의 여러 image format방식으로는 그 data를 가지고 가공이 이루어 지기에 post-process로써 compositing에서 다루기에는 모니터에서 확인 할수 없는 여러 aliasing errors에 시달리게 될 것이다. 특히 영화 film을 최종 목적지로 달려갈때나 전체 pipeline상에서 후반 작업, 즉 compositing 과정을 많이 의지 할때는 더더욱 그럴것이다. (개인적으로는 single-pass rendering을 선호하지만...)

그래서 결론적으로 우리는 3D rendering 과정안에서 가장 가깝게 접근한 환경을 가지고 있는 floating point를 기반으로 하는 high dynamic range, super-white 그리고 linear space가 지원하는 image file format 사용해야만 point-sampling based process에서 pixel-imaging based process로의 매체 전환으로 생기는 여러 aliasing errors와 현 standard image formats 자체에 기생하는 errors를 최소화 할 수 있을 것이다.
 
먼저 32bit floating point를 3D rendering output image format으로 쓰는 장점부터 얘기를 하자면, Color 값을 high dynamic range로 저장 할 수 있다는 것 뿐만 아니라 일반 display로 확인이 안 될 뿐이지 super-white 즉, over pure white, color(1 1 1) 넘는 값도 clipping 없이 저장이 된다는 것이다. (모든 integer image format은 shading and rendering 과정을 끝낸후 얻은 floating point pixel value를  post-image processing 과정에서 integer로 converting시 tone mapping 없이 자연스럽게(?) clipping이 이루어 지게 된다. (tone mapping에 대한 옵션이 min/max로 주어졌지만 특정한 경우를 빼고는 거의 사용 안하기에, 그리고 특히 8bit integer에서는 아주 빈약한 low dynamic range로 강 비츄!)

참고로 Mental Ray에서 32bit floating point tif로 저장시 위에 언급한 pixel로 전환후에 이루어지는 모든 post-image processing을 생략하기에 모든 것을 shading과정에서 해결해야만 한다. 그렇기 때문에 gamma를 조절 하기 위해서는 primary frame buffer가 아닌 mia_exposure_photographic, 혹은 mia_exposure_simple lens shaders를 사용해야만 하는 이유가 된다.

다시 본론으로 돌아와서,
반면 8bit와 16bit에서는 integer가 아닌 floating point로 저장을 한다고 해도 super-white는 clipping 되어 over white는 날아가 버리게 될 것이다. (예외로 오직 openEXR만이 16bit floating point에서도 저장이 가능.)

pure white 넘어로 짤린 부분이 전혀 필요 없이 3D rendering이 final output for TV screen을 위한 작업이라면 상관 없겠지만 3D rendered images를 가지고 후반 작업을 진행 해야 할시에는 얘기가 달라진다. 특히 illumination 영역을 compositing까지 확장시켜 다룰때 밝은 부분의 수학적 계산을 정확하게 하기 위해서는 꼭 필요 하게 되는데, 간단한 산수 예를 들면 color( 0.8 1.2 2.0) * 0.5 = color( 0.4 0.6 1.0) 이 되지만 clipping이 이루어진 color( 0.8 1.0 1.0)를 계산할 경우에는 color( 0.8 1.0 1.0) * 0.5 = color( 0.4 0.5 0.5) 로 상당히 다른 결과를 얻게 될 것이다. 다시말해 모니터 상에서는 color( 0.8 1.2 2.0)나 color( 0.8 1.0 1.0)나 똑 같이 color( 0.8 1.0 1.0)로 보여주지만 계산후 결과는 서로 전혀 다른 color를 모니터에서도 볼 수 있게 될 것이다.

또한 32 bit color depth는 3D rendering에서 보내준 color value를 tone mapping 없이 거의 그대로 가져 오기에 curve functions을 이용해 color depth range를 늘려야 할지라도 마지막 final output에 aliasing error 없이 충분한 color depth를 이어 가게 만들어 줄 것이다.

약간 벗어난 예로 digital camera에서 쓰이는 raw 파일과 비유하면 raw를 지원하는 photo editing tool에서 exposure를 낮출시에 하얗게 날라가 있던 하늘이나 구름의 형태와 칼라가 다시 복원되는 예를 들 수 있을 것이다.(Typically, two f-stop increments) raw는 8bit 이상인 11, 10, 12, 14, 혹은 16 bit color depth(회사, 기종마다 다름)까지 CCD에서 받은 순수 원색을 interpolation 없이 linear color space로 camera setting information meta file과 함께 uncompressed 저장 된 파일 형태이다. post-editing 작업을 원할 경우 이 raw를 jpeg 보다 강력히 추천되는 이유는 위의 내용과 동일하다고 말할 수 있겠다. Interpolation 없다는 것은 3D rendering으로 치면 weighted filtering 된 pixel 이전 상태인 color 값을 가진 sub-samples 상태의 points가 되겠고 11bit부터 16bit까지의 color depth는 linear color space에서 two f-stops을 오가는 상황에서도 충분한 color depth를 받쳐주게 되는 것이다.

이로써 linear work flow가 지원하는 photo editing tool을 사용 한다면 디지탈 카메라 안에서 계산되는 정확한 illumination과 연관된 exposure 매커니즘을 안방에 있는 모니터 앞에서 즐기게 해 줄 것이다. 참고로 photo editing tool에서 raw file을 위한 linear work flow를 지원 한다는 것은 마치 compositing tool에서 pre-multiply by alpha를 위해 거의 모든 effects or functions의 input과 output에 pre-divide, post-multiply 하는 것과 같이 gamma를 풀고 계산후 다시 gamma를 주는 방식으로 계산 될 것이라 예상 된다.

반면 photo image를 jpeg로 저장하여 후반 작업을 할 경우는 위의 예와 반대로 exposure를 조절시 clipping 된  white와 gamma correction issue에 의해 조금만 건드려도 민감하게 highlight 부분이 날아가 버리겠고 쉽게 saturated 되어 버려 어느 순간부터는 비현실적인 모습을 드러 낼 것이다. (뭐 이게 스타일이라고 주장하면 할 말은 없겠지만 알고는 주장을 해야 하지 않을까 해서....) 약간 중심에서 벗어 났지만 전체적인 이해를 위해서는 좋은 예가 아닐까 한다.

다시 3D world로 돌아와,
3D rendering process와 마찬가지로 compositing tool 안에 있는 모든 effects의 수학적 calculation은 linear space에서 clipping 안된 상태의 floating point를 기준으로 이루어 진다. 이런 기준에 미치지 못하는 image를 input으로 쓰게 된다면 계산시 미묘한 error를 가져다 주면서 noticeable artifacts가 조금씩 쌓이면서 final output에서는 사실적인 룩과는 점점 거리가 멀어 지게 될 것이다.

참고로 8bit integer image에 대해서 말하자면 8bit는 일반 모니터 상에서조차도 부족한 color depth이기에 인간의 logarithmic visual perception 원리를 이용해 과거 브라운관에 맞춘 비스므리한 gamma curve를 사용하여 풀어 나갈 수 있었던 것이다. 2.2 Gamma corrected image을 linear로 쫙 펴서 8bit image를 보면 부족한 칼라수로 인해 어두운 부분에서 banding현상이 일어날 것이다.

위에서 언급 했듯이 open EXR가 인기(?)를 끌고 있는 이유 중에 하나가 유일하게 16bit(정확하게는 15 bit color depth) 이면서도 floating point in linear space를 지원 한다는 것이다. 물론 super-white에 대한 clipping 없이. 최종 아웃풋이 film인 우리에게 사실 32bit까지의 color depth가 필요하진 않다. film이 수용할수 있는 한계가 12bit color depth이기 때문이다.

Light Radius vs. Light Angle as attribute of ray-tracing soft shadow

Maya 혹은 Mental ray에서 Distribution Ray tracing Soft Shadow를 만들때 shadow의 softness를 조절하는 옵션으로 쓰이는 것을 자세히 보면 약간의 함점(?)이 있다고 할 수 있겠다.

Point Light와 Spot Light에서는 'Light Radius' 라는 말로 쓰이지만 Directional Light에서는 'Light Angle' 이란 말로 쓰인다는 것이 어감이 비슷해 대강 넘어 갈수도 있지만 그 어원적인 차이를 이해하면 방식의 차이를 알게 될 것이라 생각 된다.

모든 ray-tracing shadow 계산 방식의 시작은 제일 먼저 camera view에 들어온 objects을 골라 illuminated된 surface의 각 point P로 부터 Light Emitter쪽을 향해 역방향으로 shadow rays를 travel 시켜 그 rays가 출발지점이였던 light emitter까지 거침 없이 도달하느냐 아님 any geometry에 blocking 당하느냐에 따라 shadow 생성 여부를 판단하게 되는데 soft shadow를 위해서는 그 illuminated P점에서 역방향으로 travel 시킬때 그 P점을 중심으로 한 solid angle안에서 random하게 multi rays를 쏴 hit test 하여 최종 그 light emitter까지 도달한 ray의 개수를 총 ray 개수로 나눈 퍼센트 value가 shadow가 되는데 그 solid angle의 radius size가 shadow의 softness를 결정하게 되겠다.

이  illuminated P점에서 solid angle radius를 결정하는 방법적인 차이가 light Radius와 light Angle가 나오게 된 배경이 되겠다.

 먼저 간단히 Parallel ray를 가진 distance light 보면 말 그대로 light Angle의 의미는 light 위치와 상관없이 어느 illuminated P점에서나 동일한 solid angle radius와 같다고 보면 된다.

반면 spot light와 point light에 있는 Light Radius는 distance light와 달리 light emitter origin을 중심으로한 가상의 정원을 만들어 그 illuminated P점에서 solid angle의 중심은 light origin을 향하는 콘을 형성하는데 그 solid angle radius는 그 가상의 원을 radius 크기만큼 열리게 되어 soft shadow를 만들게 된다. 따라서 그 light emitter origin을 중심으로 한 가상의 원의 radius가 solid angle의 radius를 지배하게 된다. 그래서 여기서는 light radius라는 이름으로 쓰이게 된 것이다.

여기서 간혹 문제가 생기는 것이 spot light cone에 들어 있지 않지만 그 Light emitter에 가까이 object가 있어 soft shadow 계산시 생성되는 가상의 원 radius 범위 안에 들어 왔다면 모든 shadow rays는 그 object를 shadow 영향 범위 안에 넣어 계산이 되어 전체적으로 noise를 형성되는 shadow가 생성될 것이다.

shadow의 softness의 조절은 결국 shadow ray의 solid angle radius를 넓혀 주어야 하는데 distance light는 위치와 크기에 상관 없이 light angle로 고정된 solid angle radius를 주기에 무조건 light angle을 따르게 되어 있지만, spot light와 point light는 상대적으로 light emitter를 중심으로 한 가상의 원의 radius가 shadow ray의 direction and solid angle radius를 결정하기에 light emitter 위치 즉, 거리와 light radius가 light scale과 연결되어 있다면 light의 크기 값까지 영향을 받게 되어 상당히 상대적으로 조절하게 되는 것이다.

The structure of light shaders for interactive local illumination

RenderMan은 현재 5가지 방식의 shading을 지원하는데, 이는 다들 알고 있는 surface shading, light shading, displacement shading, volume shading, 그리고 imager shading로 (예전에는 transform shading이 하나 더 있었다고 함) 그 중 개인적으로 가장 간단한 구조를 가지고 있다고 생각하는 local illumination에서의 Light Shading 구조에 대해 오늘 얘기를 해 볼까 한다. shading script coding 하기 나름이라고 반문 할 수도 있겠지만 내가 말하는 부분은 local illumination models and lights 관계에서 light shader의 기본적인 역할이 생각보다 간단하다는 것이다. 이에 반해 light shader에서 보낸 정보를 받아 반사해야 하는 surface shading에서의 illuminance loops 역할이 상대적으로 복잡해 진다고 말 할 수 있겠다.

RenderMan같은 Reyes algorithm renderers뿐만 아니라 Ray-tracing기반의 renderers를 포함 거의 모든 renderers에서 light shader와 surface shader의 이런 interactive illumination관계의 기본적인 구조는 쓰인 언어만 다를뿐 거의 같다고 자신 있게 말 할 수 있겠다. 물론 단순히 수학적으로 트릭 시킨 BRDF 관계가 아닌 Ray-tracing 기반의 ray traveling 방식의 illumination 계산이 필요로 할시에는 다소 복잡해지겠지만 오늘은 거기까지 가지는 않기에 이부분은 무시하고 가 보기로 하겠다.(RenderMan에서는 이 ray-tracing관련의 functions도 Op-codes로 단순화 시켜 버렸지만....)

Local illumination models and lights 관계에서 흔이들 쉽게 오해 하는 부분이 light emitters에서 빛 입자, 즉 photon을 발산하는 시뮬레이션을 하여 surface에 반사해 color값을 알아 내는 것으로 알고 있는데 사실 같은 이치를 수학적 트릭으로 계산해 거의 같은 결과를 얻어 내는 것이지 그렇다고 ray-tracing처럼 ray samples를 쏴 물리적인 reflection 시뮬레이션 같은 것을 하는것은 절대 아니다.

그럼, 다 아는 얘기겠지만 실제 local illumination에서 models and lights 계산 원리를 대강 살펴 보면
1. light emitter origin에서는 point light emitter의(point emitting light source로만 국한시켜 보면: area emitting light source는 오늘은 접어 놓겠다.) position 값과 light color 값만 가지고,
2. camera view frame에서 결정된 계산 해야 할 object의 surface 위의 한점인 P에서 계산된 normal vector N과,
( light distance 값과 light ray의 angle 값은 쉽게 light origin point와 surface point P를 그냥 연결시킨 vector에서 쉽게 얻을수 있겠다.)
3. 최종 ,그 두 light vector L과 surface normal vector N의 angles만 가지고 거의 대부분의 local illumination 계산이 이루어지게 된다고 볼 수 있겠다. 물론 specualer reflection에 가까울 수록 camera vector I와의 계산이 필요 하게 되겠지만...

BRDF(bidrectional reflection distribution function)중에 diffuse() reflection function만 보면 그 둘의 각도, 즉 light vector and surface normal vector의 cosine 값에(단위 벡터의 내적, lambert's law) 최종 light에서 보내준 color와 surface shader의 color을 multiply 하는 과정을 illuminance loops시켜 계산 하겠고, specular reflection function을 보면 하나 더 camera 단위 vector I가 추가되어 해당 point P에서 surface normal을 중심으로 light vector가 incoming light vector(입사각)과 outgoing reflected light vector(반사각)가 같은 앵글을 그릴때 그 반사각에 camera vector I가 가까을수록 highlight가 강해지게 계산해 내 광원에 대한 specualr 효과를 표현 하게 되겠다.

정리하면 simple light shader가 output으로 surface shader에 건내 주는 것은 light emitter의 position값과 light intensity가 multiply된 최종 light color 값만 줄 뿐이다. 이 outputs를 토대로 surface shader에서 반사값을 수학적 fake로 계산해 light ray를 쏜 것 같은 시뮬레이션을 연출 하게 되는 것이다. (이거 말로만 하려니 더 복잡! shading code를 보는게 더 쉬울 것 같기도...... 나중에 RSL에 대해 얘기할때 자세히 얘기하기로 하고....)

그럼 light shader가 복잡해 지는 이유는 Lighting의 cinematic control을 위한 shaping과 Distance fallofff functions이 추가 되어 있기 때문이라고 보면 된다.(Shadowing과 관련된 추가적인 부분들은 나중에 따로 얘기하기로 하고, 우선 통과!)

여기서 shaping이란 light coordinate space에서 X,Y plane 위에서만 놀아나는 2D functions을 써 shaping을 제어하여 마치 projection 같은 (Z축에 변화를 주지 않기에 ,배트맨 라이트 같은 효과라고나 할까?) 효과를 주는 것을 말 한다. spot light의 penumbra 효과가 가장 대표적인 예로 spot light cone 중심에서 형성된 원의 경계를 smooth function으로 제어하는 가장 단순한 방법이고 다른 예를 들면 star-shaped function 쓴다거나 혹은 pattern generating functions과 같이 써 별무리 같은 shaping을 적용해 procedual cookies or slides 효과를 연출 한다든지 더나가 u-ber light shader에서 쓰이는 super ellipse function을 써 cinematic 연출을 위해 사각과 원의 shaping을 자유로이 넘나들수도 있게 할 수도 있겠다.

X,Y plane에 대한 제어로 shaping을 했다면 이번엔 light coordinate space의 Z축을 기준으로 제어하는 Distance falloff 부분이 있겠는데 distance falloff는 Z축으로 camera origin으로부터 거리에 따라 제어 하는 부분으로 shadping 보다 훨씬 간단한 function으로 제어 할 수가 있겠다. 우리가 흔히 쓰는 빛의 거리에 따른 물리적인 기본 성질인 '거리 2제곱의 반비례'가 여기에 쓰이게 되는데 나름 원한다면 다른 여러 math curve functions을 여기에 써서 간단하게 적용 할 수도 있겠다. 참고로 우리가 Maya spot light에서 흔히 쓰는 효과 또한 Z축으로 near/far clipping을 smooth function로 각 경계면을 제어 하면 간단히 표현 할 수도 있겠다.

그럼, light coordinate space기준으로 X,Y,Z 축 전부로 3D space내에서 control이 가능 하지 않겠냐고 물어 올 수도 있겠는데 물론 가능하다. 주로 volumetric shader와 연결된 light shader에 turbulence 같은 noise-based function을 이 3D space로 흘려 보내 흐르는 안개속을 비추는 헤드라이트 같은 효과를 줄 때 사용 할 수 있겠고 더 나가 제 3의 local coordinate system을 이용해 그 좌표계 origin으로 부터 정의된 X,Y,Z 축 영역을 light coordinate space로 전환해 계산하면 결과적으로 3D world space 내에서 light intensity 변수를 local coordsys로 volumetric control이 가능해 질 수 있겠다. 눈치가 빠르다면 cinematic lighting의 꽃인 shadow blockers 얘기인지 알아챘으리라 본다. 사실 엄연히 따지면 depth map을 사용하는 shadowing 또한 여기에 속한다고 말 할 수 있겠다. 제어하는 메터리얼이 수학적 functions이 아닌(사실 이것도 가능, 예: projected shadow blockers) X,Y,Z space에 대한 정보를 이미지화 시킨, 즉 shadow camera 좌표계로 map의 가로세로가 X,Y축이 되고 pixel의 luminance value가 Z축의 depth value가 되는 엄연한 3D space 내의 light intensity 변수에 대한 projected volumetric control 인 것이다. 물론 전에도 얘기 했듯이 shadowing 계산을 위한 z-depth 대조 작업을 위해 real rendering camera 좌표계와 일치 시켜야 한다. 

위의 두 부분, shaping과 distance falloff을 빼서 light shader를 쨔면 자연 스럽게 정말 간단한 simple point Light shader가 되겠다. 여담이지만 poing light는 촛불과 같이 부드럽운 효과를 위해 쓴다는 얘기를 종종 듣게 되는데 불행하게도 그런 감성적인 차이는 우리 기분일 뿐이지 기술적으로 spot light와 아무런 차이를 주지 않는다. 그냥 한정된 지역의 shaping이 필요하거나 낭비 없는 shadowing을 쓰기 위해서 point light 대신 spot light를 쓰는 것 뿐이다.

그럼 Distance (Directional) Light는? 하고 질문이 생길 수도 있겠는데, distance light는 더더욱 간단하여 light의 position 값이 필요 없이 하나로 통일된 parallel ray angle 값만으로 surface normal vector와 계산된다고 볼 수 있다. positional data가 있기는 하지만 이건 그냥 shadow camera 용으로 쓰기 위한 것일뿐 illumination계산에 아무런 영향을 주지 않는다. 이런 이유로 distance light 또한, point light shader처럼 정말 간단하게 쨔여 진다. shaping control도 distance fall off control이 아예 필요 없기 때문이다. 구지 원한다면 위에서 언급 했듯이 제 3의 local coordsys를 이용해 3D space 특정 범위 내에서 volumatric shaping을 할 수 있는 shadow blocker 기능을 쨔 넣을 수도 있겠지만....

마지막으로 light attributes 중에 있는 non-diffuse, non-specular 기능에 대해 설명하자면 이것 또한 surface shader의 diffuse(), specular() functions 내에서 coding되어 illuminance loops시 light shader에서 전해준 그 파라미터의 값만 전달 받어, 즉 light shader에서 surface shader를 제어하는 Message passing 메카니즘을 구현해 계산하는 것이다. 이 Message passing은 renderman의 아주 강력한 기능 중의 하나로 서로 다른 종류의 shader들간에 variables를 교류 시킬수 있는 메카니즘이다.

공개된 light shaders 중 아직까지도 가장 확장된 cinematic flexibility를 가지고 있는 U-ber light shader를 예를 들면, A4 3,4 페이지가 넘는 스크립트로 아주 복잡하지만 사실 분석해 보면 각 부분의 functions이 복잡한 것이지 위의 기본 골격은 그대로 유지한다는 것을 알 수가 있을 것이다.

아무리 복잡한 shader라도 기본 구조를 이해한 상태로 분석해 본다면 더이상 복잡해 보이지 않는 다는 것이다. 이는 light shading에만 국한 된게 아니라고 본다. 이로써 light shading이 다른 종류의 shading들보다 훨씬 간단한 기본구조를 지녔다고 말하는 이유를 이해 했으리라 믿는다. (더 복잡하게 만든건 아닌지....음)

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 환경의 발전을 기대하고 있다.

Marmoset Toolbag

아직 사용은 안 해 봐서 자세히는 모르지만 아래 링크된 동영상을 보면 Game rendering engine을 써서 실시간으로 절적한 퀄러티의 렌더링을 보면서 shader와 lighting을 동시에 콘트롤, 확인 할 수 있기에 작업 시간의 단축은 물론이고 실시간의 피드백도 가능한 아주 유용한 툴이라 생각 된다. 여기에 HDRI까지 실시간으로 사용이 가능하기에 surfacing 영화쪽 작업은 물론 신속한 순발력이 요구되는 곳 어디서나 유용하게 쓰일 수 있을 것 같다.


http://vimeo.com/5734031
http://boards.polycount.net/showthread.php?t=61346
http://www.8monkeylabs.com/technology#Tools

Errors in standard specular reflection functions.

가끔은 내가 여지껏 의문 없이 믿고 쓰던 것들에 대해 근본부터 의심을 해봐야 할때가 있는 것 같다. 그 중 요즘 강하게 의심하는 하나가 일반적으로 우리가 믿고 사용하고 있는 standard specular reflection functions와 intensity rate between diffuse and specular이 아닐까 한다.

지금 일반적으로 쓰고 있는 거의 모든 specular()들은 light vector, camera vector, surface normal vector를 가지고 BRDF 입각해서 cosine 커브를 이용한 수학적 트릭으로 사용이 간편하고 계산시간이 상당히 빠르기에 70년대부터 조금씩 발전되어 오면서 여지껏 잘 써왔던것 같지만 어느 부분에서는 사실적인 접근에 한계를 보이지 않았나 싶기에 다시금 근본부터 생각해 보았다.

Pixar Ratatouille에서도 방금 요리해온 촉촉한 음식의 맛을 시각으로 살리기위해 접근 했던 부분 중에 하나가 보다 사실적인 surface highlights 였던것을 보면 같은 이치라 생각 할 수 있을 것 같다.

내가 생각하는 standard 한 방식의 문제점은 내외적으로 살펴 볼 수 있겠는데, 첫째 외적인 요소로 보면 point light emitter 의 한계성에서 오는 문제로 다양한 shape과 type의 light emitter를 받쳐 주기에는 상당한 한계를 보이는 부분이 아닐 수가 없는 것 같다. (모든 lights를 point emitter로 가정하에만 계산을 하기에)

둘째로 내적인 요소에서 보면 과거 70, 80년대에 상대적으로 느렸던 하드웨어에서 쓰기위해 빠른 계산이 우선시 되었던 상황에서 수학적 트릭으로 이루어진 functions이다 보니 high frequency reflection으로 갈 수록 광원에 의한 반사관계의 정확성이 떨어졌던 것도 사실이다.

다시말해 광원에 대한 reflection인 specular 영역에서 mirror reflection에서 glossy reflection으로 갈때 가장 에러율이 높은 사각지대가 되지 않나 싶고 반면 100% diffuse reflection에서 glossy reflection으로 갈때가 가장 에러율이 낮아 사실적인 specular를 표현 할 수 있지 않나 싶다.

안타깝게도 현재 우리 주위의 물체의 surface attribute은 상당수가 이 mirror reflection과 glossy reflection사이에서 반사관계를 가지는 material들이 많다는 것이다. 여기에는  transparency를 가지고 있는 mirror reflection 성질의 코팅된 mixed media들을 포함 할 수 있겠는데 이런 물체들은 플라스틱부터 코팅된 종이, 도색된 자동차, 페인트 된 나무, 그리고 물에 젖어 있는 물체까지 우리 주위에 흔히 볼 수 있는 물건들이 포함 된다. (참고로 이런 물체들은 fresnel효과가 상당히 강하다는 것을 잊지 말기를.....)

이런 high frequency reflection성질을 가지고 있는 물체를 가지고 간단히 비교를 해 본다면, HDRI에서 얻은 광원의 specular reflection과 surface shader에서 제공하는 specular reflection을 비교 rendering시에 그 차이는 분명해 질 것이다.

뿐만아니라 현실 세계와 비요해 diffuse와 specular의 빛에 대한 반사 intensity의 수치적인 관계가 부정확하다는 것과 over-specular intensity 따르는 여러 광학적 효과부분에서도 전적으로 후반작업으로 의지하는 것보다 어느정도 책임을 져야 하지 않나 싶다.

야외 태양광 아래서 100% pure diffuse white 석고상과 mirror ball을 보면 석고상의 가장 하이라이트 부분은 (1, 1, 1)이하로 보여지지만 미러볼의 하이라이트는 눈뜨고 볼 수 없을 정도의 강도로  보여진다. 반면 3D CGI 같은 상황에서는 어떨지 생각해보면 반사 강도의 관계가 상당히 다르게 산출 된다는 것을 알 수 있을 것이다.

현 재의 specular reflection function은 20~30년 역사를 가지고 아직도 잘 쓰고 있지만은 이제 한단계 진보 해야 하지 않나 싶어서 얘기를 꺼내 보았다.


The following is part of Siggraph 2007 Course 30 / Inside Ratatouille's Kitchen.

Color: realize that the highlight is reflecting off the outer transparent liquid layer, not the underlying food. Transparent liquids generally reflect light without modifying its color (as opposed to a metallic surface in which the reflections take on the surface color). So even if the food is a deep red or green you will still get a neutral highlight from the liquid.

Intensity: If you have a really bright light then you would expect to see an equally bright highlight on the food, but not every highlight needs to be so strong. In addition to the main highlight you will see secondary highlights and reflections of the room. These subtle highlights really add shape to the food (especially in motion because they are view dependent) and they are equally important in creating a convincing wet look.

Shape: notice the shape of the highlights on food. The highlights are broad and broken-up, letting you see fine ridges and shape changes in the surface. The first inclination might be to use specular light to create these highlights, but a traditional specular highlight is often inadequate for creating wet highlights. The only real control you have over the shape of a specular highlight is the roughness parameter. Low roughness produces a sharp, focused highlight that is too small (figure 5b). To make the highlight larger you must increase the roughness. But high roughness produces a broad smooth highlight that does not adequately break up to show off surface detail; it creates a semi-shiny plastic look or waxy look but not a wet look.

Size: a small reflection texture will produce an effect similar to a tight specular reflection. A large texture with sharp edges produces a studio lighting effect or a window highlight with broad highlights that abruptly break up based on the surface angle, which is usually the best starting point for creating a wet look.

Softness: We can control the size of the reflection texture vs. the width of the falloff at its edges, and this is perhaps the most important element in controlling the overall feeling of the highlight (in contrast, a traditional specular highlight always falls off from its center – it is not possible to define a broad center to it). Very soft highlights produce a shiny, waxy appearance that is appropriate for things like an apple or the outer layer of a red onion. You can produce this using a texture with very soft edges; the effect resembles a specular reflection with high roughness. Broad, sharp reflections produce a wet look (figure 5d). By slightly blurring the edges of the reflection texture you can soften the overall look while still maintaining shape in the reflections.

Incident Radiance and Irradiance,

Left: Incident Radiance(Illumination Environment Map)
Right: Irradiance Environment Map


아마도 그리 흔히 우리가 흔히 쓰는 용어 말고도 "Radiometry" 측면에서 보면 왼쪽 이미지는 Incident Radiance(Illumination Environment Map), 오른쪽의 이미지는 Irradiance Environment Map이라고 좀 더 전문적인 용어로 쓸 수 있겠는데 뭐 이런 것까지 알 필요가 있을까 하는 생각도 들겠지만 HDRI을 사용한 image-based lighting같이 현실에 존재하는 light information을 캣치하여 image-based caches 형태로 3D rendering 속에 집어 넣어 illumination을 계산하는 기술이 대중화가 된 이 시점에 이미 우리는 알게 모르게 이 구역까지 침범 하지 않았나 싶어 소개 할까 한다.

빛의 여정을 CG로 재현하는 과정에서 재현 이전에 우리는 분석 단계를 필히 거쳐야 하는데 이런 복잡한 빛의 성질을 조밀 조밀 따져가며 분석 할때 우리는 그 빛의 양을 재는 단위가 필요한 것은 당연 할 것이다. 그 기준으로는 Time, Space Angle이 있을 것이고 여기서 파생된 구체적인 기준을 보면 아래와 같을 것이다.

"per unit time, per unit area, per unit direction, per steradian (solid angle), power insident, power emitted."

이런 기준을 이용하여 다양한 빛의 성질을 표현하는 단위가 생겨 나게 되었는데 이는 아래와 같을 것이다.

(inputs: between the surface normal and the angle of insidence)
Irradiance: power incidnet upon unit area dA per unit time
Radiant exitance: pover emitted per unit area per unit time
Radiant intensity: power per solid angle dw per unit time
Radiance: power incident on a unit surface area dA from a unit set of directions per unit time

이 중에서 우리가 가장 많이 접하게 되는 단위가 처음에 언급한 Radiance와 Irradiance가 되는데 좀 더 깊이 있는 image-based illuminating의 이해와 활용을 위해서는 알아야 할 부분이 아닌가 생각된다.

Spherical Harmonics for Irradiance Environment Maps

요즘 한참 관심있는 "Pre-filtered irradiance environment map for a diffuse reflection map"이다. (precomputing separate reflection maps for the diffuse and specular)

다시 말해 chrome 구를 이용해 실제 세상의 light를 캡쳐한 incident radiance, 즉 illumination environment map을 low frequency reflection으로 쓰기 위해 미리 diffuse illumination as Ambient light로 전환하는 방식인 pre-filtering(pre-computing)을 하여 보다 효율적으로 쓸 수 있게 만든 irradiance environment map for a diffuse reflection map이다. 결과가 간단히 blurry env map으로 보여 단순하게 photoshop blur 정도로 생각했던 내게 띵~하고 머리에 뭔가 맞은 느낌이였다.

첫째로, illumination environment map에서 각각의 pixel을 point P로 놓고 평면 uv 좌표계가 아닌 3D space에서 두 angle과 단위 distance로 구성된 sphere coordsys (r, θ, φ)으로 전환해 정확하게 filtering이 이루어지고 둘째로는, 실제 가상의 3D sphere상에서의 normal 값을 산출해내 hemi-sphere sampling 과정을 Monte Carlo 적분법으로(Hemispherical Integration) 상당한 정확하게 low frequency diffuse illumination 계산이 이루어 진다는 것이다. (The env map should be in linear space)

diffuseConvolution(outputEnvironmentMap, inputEnvironmentMap)
{
for_all {T0: outputEnvironmentMap}
sum = 0
N = envMap_direction(T0)
for_all {T1: inputEnvironmentMap}
L = envMap_direction(T1)
I = inputEnvironmentMap[T1]
sum += max(0, dot(L, N)) * I
T0 = sum
return outputEnvironmentMap
}


위에 설명 한 것 처럼 illumination environment map에서 standard 방식으로 전체 pixel point를 다 sampling을 하여 average 값을 얻으려고 하면 너무 과다한 연산 시간과 메모리를 필요로 하게 되는데(물론 아주 정확한 결과를 얻겠지만....) 이를 좀 더 효율적으로 하기 위해 sampling 방식을 Spherical Harmonics Function과 접목해서 쓰게 되면 정말로 드라마틱하게 연산 시간을 줄일 수 있게 된다.(거짓말 같이 2시간 걸릴 것을 1~2초만에) 조금의 에러율을 얻게 되지만 High frequency(High pass)로 가지 않는 한 전혀 문제가 되지 않는다.

이미 게임쪽에서는 2000년대 들어오면서 실시간 global illumination을 위해 획기적으로 발전되고 있는 원리로 듣기로는 벌써 몇몇 게임에서 쓰고 있다고 들었다.

영화 CGI쪽에서는 여기 설명한 Irradiance Environment Maps을 빠르게 계산해 내기 위해서 그리고 RenderMan에서는 directly illuminated surface color값이 포함된 point cloud radiance caches에서 Color Bleeding과 Ambient Occlusion을 point-based approximate 방식으로 접근 계산 할때 빠르게 계산해 내기 위해 쓰이고 있다. 이 모든 현상들이 low frequency라는 공통점이 있기에 가능한 것이다.

처음 듣는 분들에게는 상당히 당혹스런 전문용어가 아닐까 한다. 나역시 이제야 이해가 가기 시작한 시점에서 자세히 정확하게 설명하기에는 그렇다. 부수적으로 딸린 수학원리 식구들이 많아 한국에서의 내가 배운 고등 수학을 뛰어 넘어야 정확한 이해를 할 수 있을 것 같다. 게다가 영어로 된 이런 수학, 물리 용어들은 너무 생소하고 전혀 다른 뜻으로 해석이 되니 이해하는데 상당히 부담을 준다. 한국어로 된 자료는 그리 많지 않지만 게임쪽의 몇몇분과 카이스트 대학에서 올려놓은 자료가 있어 지금 이해하는데 상당히 많은 도움을 얻고 있다.

해마다 이 Spherical Harmonics와 접목 된 Global illumination 분야가 게임은 물론 영화 CGI쪽에서 정말 빠르게 연구 되고 발전 된다는 것을 눈치 챘다면 주목 안 할수가 없는 부분인것 같다.

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

다음 회사는 정말이지 렌더러를 보고 가든지 해야지 이거..... 이쯤 됐으면 Mental ray에 정이 들 때도 된 것 같은데 근본적인 대안이 없는 문제들이 발생 할 때는 정말이지....  ray-tracing renderer의 장점을 충분히 살린 좋은 점도 많이 있지만 기본적으로 필요한 부분에서 막힌다는 것은 풀싸이즈로 가야 하는 영화 작업에서는 상당히 치명적이지 않나 싶다. 지금 회사도 멘탈레이를 현재 쓰고 있지만 결국은 다 고쳐 렌더맨 처럼 만들어 써야 되는 한계를 드러냈고 그렇다고 렌더맨의 기본 장점들을 쓸 수 있는 것도 아니고 이것 저것도 아닌 렌더러로 쓰고 있는 것 같다. 문제는 지금의 파이프 라인에서 조금만 옆으로 비켜 가야만 해도....음

그중에 하나인, mental ray 3d motion blur! 이 것 때문에 요즘 회사에서 골치를 앓고 있다. renderman에서는 아무 문제도 아닌 것이 왜 이리 mental ray는 3d motion blur와 depth of field에서 쥐약 먹은 듯 힘을 못 쓰는지 이 참에 한번 집고 넘어가 보기로 하겠다. 사실 거의 모든 ray tracing renderer의 공통적인 문제이고  Renderman을 더욱더 돋보이게 대조 되는 부분이기에 서로 비교 해가면서 살펴 보는게 좋을 것 같다.

먼저, 멘탈레이는 두가지 방식으로 모션 블러를 지원 하는데, 하나는 렌더링 과정에서 해결하는 3D motion blur와 다른 하나는 motion vector value를 Screen space에서 XY 전환하여 image RG채널로 뽑아서 composting tool 제일 마지막 단계에서 blur effect와 연결해 쓰게 하는 방식이다. 멘탈레이를 사용 하는 프로덕션이라면 이 두번째 방식을 거의 쓰리라 생각 된다. (설마 3D motion blur로 가는 곳이.....?)

간단하게 장단점만 언급 한다면 첫번째로 부정확성, 두번째 linear 모션 동선만 지원(프로펠라 같이 돌아가는 상황에서는 죽음) , 세번째 extremely motion blur 상황시에서는 작동이 안됨, 네번째 종종 튀어나오는 거친 값으로인한 artifacts 등등.... 뭐 이런 저런 단점이 수두룩 하지만 정말 값 싸게 모션블러 효과를 그럴듯 하게 줄 수 있다는 장점 하나만으로 이 모든 단점을 무시하고 쓰게 되는 것 같다.(후반 작업에서 노가다로 고치면서) 또 다른 이유는 멘탈레이의 3D motion blur의 죽음의 렌더링 타임으로 풀 싸이즈 영화 프로덕션에선 거의 쓸 수 없기 때문이다. (rhythm and hues에선 기존의 2D motion blur를 한단계 up 하여 사용한다고 들었다. 여기: http://www.rhythm.com/~ivan/mb.html)

ray tracing renderer의 3D motion blur는 distributed ray-tracing이 쓰이면서 가능하게 되었는데, 이는 over-sampling or multi-sampling이라 하여 단일 ray로 할 수 없었던 soft shadow, glossy reflection, blurry transparency, motion blur, depth of field를 가능하게 만들었다. 그 중 depth of field, 즉 DOF 와 motion blur는 rendering의 시작점인 primary ray에서 multi-sampling을 해야 하기에 고스란히 rendering time의 드라마틱한 증가를 피할 수가 없게 되는 것이다. 반면 나머지 것들은 secondary ray에서 multi-sampling을 하기에 primary ray보다는 그런 엄청난 부담을 주는 것도 아니고 여러 추가적인 옵션으로 optimizing도 가능하게 피신처를 남겨 주었다.

DOF는 보통의 renderer(renderman 포함) 방식인 pin-hole camera가 아닌 image plane 앞에 실제와 같이 가상의 lens(imaginary lens surface)를 만들어 거기서 multi-sampling을 random하게 쏘면서 거의 현실과 같은 방식으로 시뮬레이션을 하여 결과를 얻는다. lens를 사용하는 사진기의 원리를 이해 한다면 무슨 얘기인지 이해 하리라 생각한다. 조리개를 열면 열수록, 렌즈의 사용 범위가 커지면 커질 수록 심도가 얕아지게 되는 optic원리와 같은 원리를 사용한다.

아래 글 중에 ray-tracing renderer에서 sub-sampling을 위해 primary ray 수를 늘리면 rendering 시간에 어떻게 영향을 미치는지 언급 했었다. 3D motion blur, DOF도 같은 이치지만 기존 primary sub-samples 수에 플러스 되어 쏘고 더나가 anti-aliasing 이슈를 피하기 위해서는 더더 많은 sample 수가 요구되기에 rendering 계산이 상당히 오래 걸리게 되는 것이다. 그 뿐만 아니라 만약 secondary ray(ray tracing reflection, refraction, shadow 등등)라도 썼다면, 더나가 sedondary ray를 multi-sampling을 위해 썼다면, 매 primary sample마다 나무 가지 늘 듯이 주렁 주렁 계산 량은 늘어 날 것이다.

또한, mental ray 3D motion blur에서는 animated shader를 지원한다. (renderman과는 달리....) 지원한다고 전혀 좋은 소리는 아니다. 이 말은 곧 3D motion blur 계산 할때 visibility ray마다 매번 그 무거운(경우에 따라) shading 과정을 계산 해야만 한다는 것이다. 구조상 어쩔 수 없이 계산 해야 하기에 옵션으로 on, off 할 수도 없는 것이다. 과연 animated shader motion blur 쓸 일이 평생 몇 번이나 있을까? 반면, renderman은 3D motion blur에서 animated shader를 지원하지 않는다. motion blur의 시작되는 shutter opening time에서만 shading하여 나머지에 그 shading한 값을 쓰기 때문이다.

renderman의 경우는 3Dmotion blur, DOF를 계산을 하든 말든 그리 렌더링 타임이 차이가 나지 않는다. 무슨 마술도 아니고....  계속....

The name, Monte Carlo Algorithm, is from ......?

늘 궁금 했었다.
ray를 많이 쏴대기만 하면 툭하고 튀어 나오는 몬테 카를로 방식, 몬테 카를로 적분 등등등!  늘 그렇듯이 이 방식을 만든  사람의 이름에서 따 왔을거라 생각했었다. 근데.....삼촌이 갬블링을 위해 돈 빌린 모나코에 있는 카지노 이름에서 따온 거라니..... 장닌끼로 만든 코드 네임이 이제는 빼도 박을 수도 없는.... 쩝,


John von Neumann and Stanislaw Ulam suggested that the problem be solved by modeling the experiment on a computer using chance. Being secret, their work required a code name. Von Neumann chose the name "Monte Carlo". The name is a reference to the Monte Carlo Casino in Monaco where Ulam's uncle would borrow money to gamble

Number of Samples in Mental Ray vs. Shading Rate in RenderMan

Number of samples and shading rate는 각각 Mental ray와 RenderMan에서 Quality를 결정하는 가장 큰 영향역 있는 render global 옵션이기에 비교를 해 보았다. 이 두가지를 비교 이해 한다면 두 렌더러의 근본적인 차이점을 이해 하게 될거라 생각든다. 하나는 상용 ray tracing 방식에서 다른 하나는 상용 reyes scanline 방식에서 각각 탑클래스를 달리는 renderer라고 봐도 무방하다.

아마도 많이들 궁금해 할것 이라 생각드는 것 중에 하나가 Renderman에 있는 shading rate라는 option이 Mental ray에는 왜 없는지가 아닐까 생각한다. shading rate는 말 그대로 shading하는 단위의 크기를 정의 하는 것이다. Renderman은 한 grid에 붙어 있는 모든 Micropolygon의 4개의 vertex를 shading 하므로 Micropolygon의 크기가 shading rate가 된다. 고로 shading rate는 Micropolygon을 screen 상에서의 크기를 정의 하는 옵션이 되는 것이다.(정확히 어떻게 크기가 결정되는지는 어느 renderman 책에나 잘 나와 있으니 패쓰) 반면 Mental ray에서는 전형적인 pure ray-tracing renderer가 그렇듯이 primary ray로 sampling 되는 곳이 shading 하는 곳이 되기에 shading rate라는 옵션이 필요 없는 것이다. 그러므로 sample 개수가 곧 shading rate와 같은 정의를 내리게 되는 것이다. 반면 Renderman에는 Mental ray와 마찮가지로 Number of samples 옵션과 shading rate 옵션이 모두 다 있는데 이는 Renderman은 sampling이 별개로 shading과 독립되어 있기에 양쪽의 옵션이 필요하게 된 것이다. 다시 말하면 sample 개수를 늘려도 렌더링 시간에 큰 영향을 안받는다는 것이다. 너무도 너무나 무지 무지 중요한 얘기다. (이부분이 이해 안간다면 아래 전에 쓴 글들을 참조하기 바란다.) 다시 mental ray로 넘어와서, 이와는 달리 멘탈레이는 sample의 개수의 증가는 첫 출발지인  primary ray의 개수의 증가로 바로 이어지면서 늘어난 만큼 intersection tests와 shading 할 포인트 증가로 바로 직결 되어 렌더링 타임이 power곡선을 그리 듯 늘어나게 되는 것이다.

다시 정리해보면 랜더맨은 sampling을 거의 끝물에 shading과 상관없이 독립적으로 실행되고 멘탈레이는 sampling이 시작점에 위치해 primary ray 쏴주는 개수가 되므로 앞으로 있을 모든 렌더링 계산에 영향을 미치게 되는 것이다.

그런 이유로 랜더맨은 sampling이 부수적인 옵션이 되고 shading rate가 메인 옵션이 된것인 반면 맨탈레이는 shading rate라는 옵션이 아예 없이 sampling 옵션만 있는 것이다.

이렇게 sample 개수의 증가를 두려워 하는 맨탈레이는 이를 덜기 위한 선택으로 adaptive sampling 방식을 도입해 쓰게 된 것인데 이는 contrast 기준으로 통해 sample 개수를 통제하는 것으로 콘트라스트가 낮은 지역이면 변화가 적어(low frequency) 작은 샘플 수로도 충분히 픽셀화 시킬 수 있고 콘트라스트가 높은 지역(High frequency)에서는 많은 변화가 있다는 뜻으로 그 변화를 다 캡쳐 하기 위해서는 더 많은 샘플 수가 필요로 하기에 콘트라스트에 따라 샘플 수의 개수를 조정 한게 되는 것이다. 그래서 맨탈레이는 min sample level와 max sample level가 존재하는 것이고 contrast threshold 옵션을 통해 그 콘트라스의 기준을 움직이는 것이다.

이처럼 adaptive sampling 방식은 주로 ray를 동시 다발적으로 쏴야 하는 경우에 계산시간을 더 빨리 낭비 없이 히기 위해 이곳 저곳에서 많이 쓰이는 방식으로 널널한곳은 널직하게 하면서 밀집한 곳을 집중 공략하는 방식이라 할 수 있겠다. 예를 들면 ambient occlusion과 color bleeding 계산 할때도 쓰일 수 있겠는데 여기에 하나더, a cosine-weighted라 하여 cosine의 곡선을 이용해 hemisphere에서 90도가 되는 normal주위에 더 많은 rays를 쏘고 0도나 180도로 가는 끝부분에서는 적은 양의 rays를 쏘게 하여 더 효율적으로 계산 할 수 있게 만드는 기능이 첨가 되어 있다. 어떻게 해서든 ray수를 줄여가며 효율적으로 sampling 부족으로 인한 anti-aliasing 극복 하느냐가 ray-tracing algorithm의 계속 풀어 나가야 하는 숙제 중에 하나 인 샘이다.

그럼 renderman에서도 adaptive sampling 방식을 쓰면 더 빨라 지지 않겠냐는 의문을 가질 수 있겠는데 사실 adaptive sampling이 자체의 구현이 빠른게 아니다. sampling rate를 요구에 따라 바꿔주어야 하는 계산과정이 있기에 그러한데 ray-tracing rendering에서는 워낙 intersection tests가 비싸기에 adaptive sampling방식으로 ray sample 개수를 줄이는게 더 효과적이기 때문에 쓰는 것이다. 그래서 추가 sampling 비용이 필요 없는 renderman에서는 구지 이 비용이 더 드는 adaptive sampling을 쓸 이유가 없고 대신 간단한 jittered sample distribution 방식을 써 한 픽셀안에서 일률적인 수의 sampling을 하게 되는 것이다.

알면 알아 갈수록 renderman의 트위스트한 묘한 매력에 빠지는 것은 당연한 것 같다.

What is Micropolygon?(1)

흔히 RenderMan을 Micropolygon-based renderer라고 한다. Reyes algorithm renders를 조금이라도 접했다면 'Micropolygon' 이 단어를 정말 귀청 떨이질 정도로 들었을 것이다. 많이들 듣고 얘기를 하지만 사실 이 녀석이 뭔 놈인지, rendering시 다른 process와 연관되어 어느만큼 중요한 부분을 차지하는지 정말 이해하고 쓰는 이는 많지 않다고 생각된다. 그냥 아주 작은 rendering되는 최소 geometry 단위(the common basic geometric unit of the algorithm)라는 정도로 생각하지 않을까....

Reyes algorithm의 꽃 중에 하나가 그 제각기 크기와 성격이 다른 geometry에서 micropoylgon으로 통일화 되어 가는 여정일 것이다.(The Reyes algorithm is in essence a micropolygon-centered algorithm) 이 micropolygon이란 단어는 micro-bilinear-patch의 줄임 말이다. 전에는 더 복잡한 flat-shaded sub-pixel quadrilateral이란 단어로 쓰이기도 했었다. 직역해 보면 '평면의 쉐이드된 한 픽셀보다 작은 사변형'이라고 나름 해석 할 수 있겠다. 다시 말하면 한 pixel의 반보다도 작게 쪼개 질 수 있는 four vertices로 구성된 사변(four-sided)의 polygon(quadrilateral facet)이다.(tiny bilinear patch or facet 이라고도 함) 뭐 말만 붙이면 넘 더 복잡해지니..... 쉽게 얘기하면 아주 아주 작은 삼각이 아닌 그냥 사각의 쌍 직선의(bilinear) 두 edges로 이루어진 polygon이다.

늘 평면을 유지하는 triangle mesh를 기본 Rendering 단위로 쓰는 ray tracing-based renderers와 달리 micropolygon은 사각으로 되어 있기에 경우에 따라 flat 하지 않을 수 있는 상황에서 오는 error를 가질 수 있지만 pixel보다 작아지는 상황에서는 그냥 무시되는 error일 뿐이다. 그럼 왜 사각형으로 선택을 했을까하는 의문을 가질 수 있겠는데 이는 parametric geometry을 sub-divide하기에 가장 용이한 형태이기 때문이다. (단, polygon만 제외)

micropolygon의 바로 전 단계 형태인 grid라는 놈을 빼놓고 얘기 할 수는 없다고 보는데, a grid는 각각의 micropolygon으로 분리 시키기전의 micropoygon을 그룹 시켜논 bicubic subpatch이다.(A grid is a tessellation of the primitive into a rectangular array of quadrilateral facets(= micropolygon facets) and a bunch of large rectangular arrays of floating-point-numbers) 사실 shading단계까지는 이 migropolygon의 덩어리인 grid 단위로 계산이 이루어지고 rendering과정이 거의 끝나갈 무렵인 모든 shading조차 끝난 상태에서 그 grid가 각각의 조각인 micropolygon으로 분리 독립이 되어 한손에는 Ci 값을 다른 한손에는 Oi값을 네 vertex마다 쥐어 주고 최종 hiding과 sampling 공정으로 보내지게 된다. (사실 micropolygon을 부를때 shaded micropolygon이라 불러야 더 정확하지 않을까 한다.) grid 단위로 shading 계산이 이루어진 이유는 당연 계산의 효율성 때문인다. 즉 이웃한 micropolygon끼리 공유된 vertex를 한번에 renderman shading engine의 심장인 SIMD virtual machine으로 보내져 shading계산을 할 수 있기 때문이다.

Anyway! 다시 micropolygon쪽으로 돌아 오면,
우선 그 그렇게 작은 크기에서 오는 장점부터 얘기를 해보겠다. (한 픽셀의 반보다도 작게 쪼개 진다는 말은 정말 CG세계의 마이크로 세계의 단위라고 말 할 수 있을 만큼 정말 정말 작은 단위이다.) 이는 크게 네가지의 장점을 만들어 준다.

첫번째로, 최초 geometry(polygon은 제외)의 곡율를 가장 가깝게 전달, 재현해 줄 수 있고( 게다가 veiw dependent),
두번째로, Nyquist limit으로 올 수 있는 artifacts를 지오메트리 단계에서 부터 해결해 줄 수 있고,
세번째로, shading과정에서 displacement에 의한 vertex의 재배치에 자유로움을 주게 되고,
마지막으로, shading을 현존하는 렌더러중 현실과 가장 가까운 단위 면적으로 빛과 표면의 반사되는 관계를 계산해 내어 정확한 color값을 구할 수 있다는 것이다.(interpolation만 의지 한게 아닌)  계속......

Why RenderMan needs Displacement Bounds?

왜 renderman류의 renderer에서만 displacement bound 옵션이 있을까? 라는 물음으로 시작하겠다. 이 옵션의 역활은 단순하다. 말 그대로 해당 geometry의 bounding box 사이즈를 정의된 unit단위로 늘리는 것뿐이다. 그럼 왜 bounding box 싸이즈를 displacement 되어 움직여지는 grid vertices 만큼 늘여야만 하는 것일까? 첫번째 이유는 bucket단위로 독립적인 rendering을 하기 때문이고 그 bucket안에 geometry가 안에 있냐 밖에 있냐를 계산할때 bouncing box 단위로 체크를 하기 때문이다.

두번째 이유는 displacement는 shading과정에서 계산되어지기 때문이다. shading을 하기 전까지는 이 grid상태의 micropolygons vertices이 후의 과정인 displacement shading에 의해 어디로 튈지 모르기 때문에 렌더링 초기 과정인 bucket안에 들어와 있는지 여부를 (bounding box 단위로 check & culling) 확인할때 그 bounding box 싸이즈를 크게 하여 계산되고 있는 bucket안에 들어오게 하여 실제 계산인 쉐이딩 까지 그 데이타를 계속 끌고 오게 만드는 것이다. 이 옵션은 상당히 비 계산적인 방식으로 조절해야 하는 것이 사실이다.

그럼 이런 비 계산적인 방식 말고 정확하게 계산해여 displacement bound value를 얻을 수 없는 것도 아니다. extremedisplacement attribute을 씀으로써 정확한 값을 뽑아 올 수가 있다. 이 방식은 먼저 해당 geometry마다 displacement shading을 연산하여 정확한 displacement bounds 값을 산출하여 제공하므로써 메모리를 낭비하는 것을 방지하는 것이다. shading을 먼저 한다는 것 또한 rendering 과정에 상당한 부담을 줄것이지만 어떤 경우에는 이 부담을 안고서도 정확한 값을 필요로 하기에 이 attribute가 있는 것이다. 흔히 Extreme Displacement가 이루어질때 이것이 효과적으로 쓰이기 되는데 Extreme 같은 경우에는 보다 정확한 displacement bounds value가 요구되어 진다. 잘못 쓰인 값은 엄청난 메모리 낭비로 직결되기 때문이다.

Shading Rate vs. Pixel samples in Renderman.

"Decoupling between shading and sampling in RenderMan."

Renderman rendering과정(REYES Algorithm)을 크게 둘로 나눈다면 shading rate가 영향을 받는 부분 까지와 이후 영향을 안받는 나머지 후반 부분, 즉 pixel sampling이 지배하게 되는 단계로 나눌 수 있겠다. 이 두단계를 서로 영향 안받게 만듬으로 RenderMan은 pixel sampling(super sub-sampling)에 자유로움을 갖게 되었다. 이는 모든 Renderer의 최대의 적 aliasing issue에 대해 보다 자유로워 질수 있고 많은 투자 없이도 좋은 quality로 final pixel까지 가게 해 주었다. 더 나가 motion blur와 DOF에서 요구되는 충분한 samples을 얻는데 쉽게 갈수 있는 길을 열어 주었고 할 수 있겠다.

하드웨어 사용면에서 보면, 이로써 shading과 hidden surface calculations와 분리를 하였기에 많은 부하를 줄일 수 있게 됐다. shading 과정에는 메모리 먹는 괴물 texture가 포함되어 있기에 sampling 과정에서 나오는 또 다른 메모리 포식자 visible point lists와 분리 시킴으로써 효울적인 메모리 관리가 가능하게 된 것이다.

이런 완전, 완벽한 분리는 RenderMan같은 종류의 Reyes Renderer에 pure ray-tracing renderer 가 따라 올 수 없는 많은 독특한 특징을 지어준다고 볼 수 있다.

단점으로는 미리 shading 되어 있는, 차려진 밥상에서만 가지고 a pixel안에서 sub-sampling이 들이가기에 painted texture 와 procedural texture에 high frequency 지역에서 aliasing이 방치되게 된다. sub-sampling으로 쪼개진 만큼 texture 또한 같은 sampling이 이루어져야 하는데 이미 shading에서 끝나 버렸기에 돌아 갈수가 없는 것이다. (참고로 모든 신호 체계는 reconstruction단계에서 Nyquist sampling 법칙에 의해 두배이상의 sampling을 요구한다.) 그래서 미리 high frequency를 신호를 막기위해 RenderMan은 pre-filterd texture를 쓰게 된다.

procedural texture는 얘기가 더욱 복잡해 지는데, 선분 하나 그어도 filtering을 shading script차원에서 미분까지 들쳐 가면서 만들어 줘야 하기에 그리 간단하지 않은 것이다.

반면 일반적인 Ray-tracing Renderer들은 지금 얘기와 반대로 이해하면 될것이다. 그러기에 다른 renderer에서는 super sub-sampling위해 primary sample 수를 늘려주는 만큼 드라마틱하게 rendering time이 늘어나게 되는 것이다. 물론 나름대로 primary sample 수를 줄이기 위해 여러 대처 방식(예:Adaptive sampling)으로 그 늘어난 시간과 메모리를 효율적으로 만들려고 노력하지만 근본적인 구조의 디자인이 다르기에 쉽게 Renderman같은 효과를 못 내는 것이다.

Monster Inc.부터 쓰이기 시작한 Deep shadow maps이 renderman에서 그리 많은 추가 비용이 필요 없이 효울적인 사용이 가능한 것도 Decoupling between shading and sampling의 프로세서를 가지고 있기 때문이다. deep shadow maps의 주요 특징중에 하나가 기존의 한 pixel에서 한 sample만 가능 한 traditional shadow map과 달리 sub-sampling이 가능하여 fur같이 pixel보다 작은 geometry의 detail을 놓치지 않고 shadow 생성 할 수 있는 것이다. 다시 말하면 shadow camera에서 depth map을 생성시 shading단계까지 오는 micropolygons 생성 과정이 traditional shadow maps과 deep shadow maps방식은 같고 shadow map이기에 당연히 shading은 생략을 하면서 sampling 단계 부터 서로 다른 길을 가게 되기에 reyes의 Algorithm을 갖고 있는 renderer는 부담 없이 deep shadow maps을 더 정확하게 효율적으로 쓸 수 있게 된 것이다. 이외에도 정말 환상적인 어드밴스 기능이 많은 deep shadow maps이기에 다음 기회에 이것만 갖고 더 자세히 얘기하기로 하겠다.

참고로 Mental ray도 이같은 방식의 shadow map을 지원하지만(called: detail shadow map), 어떻게 진행 시키는지는 잘은 모르지만(알 수가 없음) renderman과 같은 결과는 기대하기 힘든 것 같다.

Nyquist sampling.

Normally, the Nyquist sampling theorem(proposed by Harry Nyquist in 1928) states that for adequate sampling, the sampling frequency needs to be twice or more than the highest frequency in the input signal.


모든 3D rendering과정은 signal processing에서 sampling과 reconstruction의 과정과 같다고 해도 과언이 아니라 생각한다. 이 sampling 얘기만 나오면 하는 얘기 중에 하나가 Nyquist sampling 원리일 것이다. 그만큼 중요하기에 여기 짧은 글이나마 올려 본다.

signal processing을 통한  Anti-Aliasing 부분은 3D CG rendering에서 너무도 중요한 부분이다. 이 신호 체계의 기본 컨셉을 이해 해야 왜 그렇게 rendering뿐만 아니라 이곳 저곳에서 짜르고 미리 나누고 미리 막고 sampling하고 sub-sampling하고 filtering 해야 하는가를 이해 할 수 있을 것이다. 나중에 기회 있을때 이런 신호체계에 대해 더 자세히 얘기해 보기로 하겠다. 

When Shadows Become Interreflections

"When Shadows Become Interreflections"
"Shadows tend to occur in those parts of a scene in which interreflections have the largest gain."  

우연찬게 몇몇 자료를 서치 하다 그 제목을 보고 너무도 놀랬다. 내가 한동안 관심있게 생각했던 현상에 정확히 어울리는 영어 제목이였기 때문이다. (짧은 영어라...^^) 우연찮게 같은 생각을 하는 사람을 만난 느낌이랄까? 논문 형식으로 쓰여진거라 내용은 좀 동떨어져 보이지만 개인적으로 이 주제는 photo-realistic lighting으로 가는 길에 상당히 중요하다고 생각한다.



http://www.cim.mcgill.ca/~langer/MY_PAPERS/Langer-IJCV99.pdf
http://www.cim.mcgill.ca/~langer/pubs.html

fail.....

등잔 밑이 어둡다더니, 이건 바로 머리 위의 천장이 문제 였네....

Precomputed Radiance Transfer, Siggraph 2005 Course

http://www.cs.ucl.ac.uk/staff/j.kautz/PRTCourse/


2005년도 것이지만 정말 최신의 lighting 흐름이  전체적으로 보이는 소중한 자료 인것 같다. 시그라프에 소개된 pdf파일들이라 정리도 아주 잘 되어 있다.

Exposure in light shader.

Alternatively if you want an exposure control you just need to adjust the brightness in stops. This is a logarithmic scale so increasing the exposure by one stop doubles the intensity.

Cl *= pow( 2, exposure);

요즘 보면 Exposure Parameter를 Light shader에서 intensity와 함께 같이 쓰는 경우를 종종 볼 수 있다. 실제 Photography & Cinematography에서 사용되는 단위로 간단할 것 같지만 깊이 있게 설명하자면 정말 분량이 엉첨 커질 것이다. 빛이 film에 닿을때 물리적인 커브부터 사람의 눈이 빛에대한 민감성의 변화량, 1 stop 2 stop이 나온 이유부터.... 뭐 이리저리 얘기 할 것들이 정말 많아 진다. 예전에 학교에서 영화과 수업에서 들은 적이 있는데 기억 나는 것은 촬영 수업이 갑자기 수학, 물리 수업으로 바껴버려 다들 눈만 멀뚱멀뚱 했던게 기억난다. 다음에 이 부분을 좀 더 공부 해 정리 하기로 하고 오늘은 여기까지만....(도망가는 중^^)

참고로 실제 카메라에서 Exposure 계산법
Exposure = log2 ( Aperture2 * (1/Shutter speed) * (ISO Speed/100) )

What is color bleeding(secondary one bounce diffuse Inter-reflection)?

사실 'secondary diffuse inter-reflection'이라는 말이 더 정확 하겠지만 일반적으로 color bleeding으로 더 많이 알려져 있어 그냥 color bleeding이라 쓰겠다.

Color bleeding이 무엇이고 현제 어떤 시점까지 와 있는지 얘기해를 해보면 Color bleeding은 Ambient Occlusion이 그랬 듯이 현 헐리우드의 메인 프로덕션을 중심으로 빠르게 확산되어 가는, 더욱 사실적인 효과를 주기 위한 lighting의 한 요소로 빠르게 자리 잡아 가고 있는 기능 중에 하나일 것이다. 선택과목에서 필수 과목으로 빠르게 들어 오려 하는 과정이라고나 할까?

Color bleeding은 좀 더 정확하게 secondary diffuse inter-reflection이라 정의 내릴 수 있겠는데 앞서 얘기 했듯이 좀 더 이해하기 쉽게 하기 위해 color bleeding이란 용어가 일반적이로 쓰이고 있는 것 같다.

중요한 것은 'secondary'라는 것. 즉, 1차적으로 light emitter에서 나온 direct light가 물체의 surface을 맞은 후에 일어나는 2차 반응 중에 one bounce diffuse inter-reflection만 계산해 낸 것이다.

더 자세히 말하면,
1차, light emitters에서 direct light를 쏘아줌,
2차, 1차에서 쏜 rays에서 hit된 surface의 point P에서 정의 된 distance만큼 반구의 볼륨안에서 정의된 개수만큼 rays를 쏴줌. 그리고 그 쏜 rays가 어느 물체의 surface에 hit을 했으면 그 hit한 surface point P에서 shader의 color값을 모두 가져와 average값을 구하여 1차의 light color 값과 2차의 surface color값을 곱해 준 것이 final output color value가 된다.

이런 효과를 표현하기 위해선 현재로써는 세가지 방식으로 접근 할 수 있겠는데,

첫째는 현재 가장 효율적인 방식으로 점점 유명해져가는 irradiance caches의 한 종류인 point cloud로 caching 하여 octree로, 혹은 brick maps 형태로 그 data를 organization한 상태에서 spherical harmonic functions을 이용한 point-based approximated 방식으로 빠르게 연산하여 얻어내는 방법이겠다. 완벽하게 정확한 값을 얻어내는 것은 아니지만 가장 안정적이고 현 프로덕션 상황에 맞게 고급 퀄러티를 얻을 수 있는 최고의 방법이라 말 할 수 있겠다. 단점은 구조상 pixel만큼 조밀한 point cloud가 가능한(each micropolygon vertex가 point cloud caching이 되기때문) Reyes algorithm의 renderer들만 지원을 한다는 것이다. ray-tracing based render도 이론상 가능은 하지만 screen space안의 부족한 vertex 수로 인해 현재로써는 불가능하다고 본다.

둘째로는 distribution ray tracing 방식을 이용한 방식으로 현재 Fake 방식으로 많이 쓰이는 것으로 알고 있는데(참고로 지금 회사에서 쓰는 방식임) 쉽게 말하면 Ambient Occlusion 방식에서 floating point value 대신 RGB color 값을 가져오는데 AO처럼 hit 유무만 알아 오는것이 아니라 hit 했을시 그 surface point에서 shader에 있는 color 속성도 빼오는 방식이다. 앞에서 얘기 했듯이 이것은 Fake다. secondary diffuse inter-reflection에서 1차 light 계산과의 거래는 완전 무시하고 surface shader에서 color attribute만 뽑아 오기에 계산이 가볍고 어느 ray-tracing 렌더러에서나 가능하다는 것이다. 1차 direct light 계산과의 거래가 없는 관계로 너무 원색적인 final color값을 얻기에 compositing tool에서 또 한번더 부정확한 fake로 만들어 주어야 한다는 단점이 있겠다.

세째로는 뭐 다들 알고 있듯이 photon mapping 방식의 Global illumination을 써서 얻어 내는 것으로 가장 정확한 계산 결과를 얻지만 죽음의 렌더링 타임과 노이즈와의 싸움으로 인해 현실적인 feature production에서 아직까지는 사용이 힘들다는 것이다. 듣기로는 PDI는 Shrek 2부터 이 방식으로 쓰고 있는 듯 하지만 그냥 스탠다드한 방식으로 쓰는 것이 아니라 위의 첫번째 방식인 point based같은 효율성을 얻기 위해 uv space상에서 filtering 및 이와 관련된 2차적인 효과를 주어 보완해서 쓰는 것으로 알고 있다.

어쩌면 color bleeding이란 건 global illumination 방식으로 가는 과도기에서 나온 과도기적 효율적인 방식일지도 모른다. 하지만 현 하드웨어적 상황으로 볼때 당분간은 이것을 유지 할 것으로 예상된다.(늘 하드웨어의 발전 속도는 나의 예상을 뛰어 넘기에.... 과연?)

Ambient Occlusion 사용만으로 오는 포토리얼리즘 속의 비사실성이 보인다면 다음 스텝으로 color bleeding으로 다가가야 한다고 강력히 강조하고 싶다.

Color Bleeding vs. Ambient Occlusion

When a ray shot by indirectdiffuse hits an object, the shurface shader of that object is evaluated. Rays shot by occlusion do usually not cause the surface shader to be evaluated, and are therefore faster. Indirectdiffuse returns a color while occlusion returns a float.

Color Bleeding에서 direct illumination 계산을 무시하고 생각 했을때 Ambient Occlusion 계산과의 근본적인 차이이다. 그리 많은 차이는 없지만 hit한 point에서 shading을 계산하냐, hit의 유무만 계산 하냐이지만 각 point P마다 워낙 ray 수를 많이 쏴야 하는 상황이라 계산 시간의 차이가 상당히 나게 된다.

The wonder hospital.

Let me introduce a close friend of mine's short animation. I'm always waiting for a next pixar's project and a next Ghiburi's animation, as well as my friend's short animation.

http://www.shimbe.com/The_Wonder_Hospital.htm

Why we have to use integer pixel values as final output? no floating-point values?

Most output devices are controlled by integer pixel values. The process of converting the floating-point real values into integers is called quantization

자연스럽게 나오는 질문중에 하나가 "왜 우리는 최종 output image로 integer를 쓸까?" 라는 질문일 것이다. 대답은 간단하다 gamma가 그랬듯이 거의 모든 device들이 실질적인 color를 생성할때 인티저 값을 요구하기 때문이다. 그럴것이 채널당 8bit 즉 256 칼라 수만큼 표현하는데 있어 명확한 칼라값을 요구 하기에는 인티저가 제격일 것이다. 32bit상에서도 integer가 유용할때가 있다. 예를 들면 칼라의 경계를 명확히 해야하는 ID를 추출할때를 들수 있다. 하지만 거의 모든 3D 더나가 2D and compositing application에서 계산하는 전 과정은 floating-point이다. 하지만 최종 아웃풋으로 내 보낼때 아래와(256 color수의 예) 같은 integer로 전환과정을 가게 된다.

outPixel = (pow(((inPixel * 255.0) - inBlack) / (inWhite - inBlack), inGamma) * (outWhite - outBlack) + outBlack) / 255.0;

Monitoring for 32 bit floating-point color depth.

3D 작업 상에서 효과적인 color depth는 As much as possible이다. 단 하드웨어와 소프트웨어가 지원을 하는 한도 내에서. 하지만 현 하드웨어, 특히 computer display의 지원이 다른 것들에 비해 느리게 발전되어 왔던것 같다. 8bit 이상을 써 왔을 경우 확인 할 수 있는 방법은 극히 제한적이다. 그래서 전에도 언급 했듯이 계산 되어진 절차와 공정으로 우린 머리속으로 모니터링을 하게 되고 최종 목적지로 안심하고 보내게 되는 것이다. Output color depth를 32bit floating-point로 했다고 해서 rendering time에 별로 영향을 미치지는 않을 것이다. 3D renderer 내의 모든 공정이 가장 근사하게 32bit floating-point in linear space로 이루어 지기 때문이다. 단지 저장 공간인 하드에 많은 부하를 줄 것은 분명하다.

Gamma correction issue in 3D CGI rendering

gamma correction이 issue가 된 원인을 살펴 보면 renderer내에서는 아무런 gamma correction에 대한 issue꺼리가 없다. 하지만 renderer밖에 있는 이미지 데이타(as texture or image based light)가 3D renderer로 input으로 들어 올 때와 그 데이타를 가지고 rendering 되어 final render output으로 나와서가 문제가 된다. 책임을 따지자면 먼 옛날 브라운관이 발명 될 때로 돌아가 보면 부족한 8bit color depth를 매꾸어야만 하는 상황에서 나온 나름 똑똑한 방식으로 나왔기에 책임을 물을 수는 없는 것 같다. 그냥 기술이 발전되는 과도기에서 나온 happening이라고 말 할수 있을 것 같다. 그렇다고 그냥 happening이라고 말하기에는 그간 10년 넘게 우롱 당해온 3D CG 일반유저가 가엽다고나 할까?

재밌는건 밖의 2.2gamma correct된 이미지(Textures)가 renderer안에 들어와 마지막 render pixel화 단계에서 gamma correct 안되면서 그 보이는 것보다 밝에 들어온 texture가(gamma correction 때문) 파이널 렌더링에서 모티너의 gamma때문에 감추어 진다는 것이다. 그래서 일반유저가 볼때는 아무런 문제가 없는 듯 보인다. 하지만 render내부에서 계산되어지는 rendering, shading, lighting 모든 것들이 linear로 계산되기에 잘못 된 최종 아웃풋을 렌더링 하게 되어 지는 것이다. 다시 말하면 잘못된 쉐이딩 라이팅의 값과 비슷하게 맞아 떨어진 texture값의 아웃풋이 우리가 흔히 보는 3D rendered images인 것이다. 그럼 2.2 gamma corrected texture 대신 원형 그대로인 linear space의 texture 쓰게 되면 그 문제점이 확연히 들어난다. 가까운 예를 들면 HDRI를 texture나 env map으로 사용하면 알 수 있을 것이다.


The standard image processing calculations that might be applied to an image, such as blurring, resizing, or composting, all work best if the data is "linear," that is, has no built-in gamma correction. For this reason, it is usually best for high-quality images to be stored with no gamma correction and to apply correction as the image is being loaded into a display.

The RenderMan community of Japan, RenderSan( San means sir in japanese)

처음에 무슨 소리인가 하다 한참을 웃었던게 기억난다. 간혹 농담식으로 랜더우먼, 랜더걸이라 하며 만든 이름들은 봤지만 이게 가장 웃긴 것 같다. 참고로 ~상은 우리 나라말로 ~씨로 해석하면 된다. 랜더씨라....그럼 한국은 RenderSSi? ^^

http://www.rendersan.org/

How does the renderer know the point of origin of the light as a shadow emitting point in renderman?

When camera at the time that the shadow map was made-in other words, the emitting point. The shadow() function knows to look for this information in the shadow map file. Notice that since the shadow origin comes from the shadow map file rather than the light shader, it's permissible(and often useful) for the shadows to be cast from an entirely different position than the point from which the light shader illuminates.

개인적인 생각으로 Renderman lighting의 장점 중에 하나가 depth map shadow을 쓸때 Shadowing을 lighting으로 부터 완전히 분리 시켜 다룰 수 있다는게 아닌가 싶다.

실제로 종종 composition 이유로 light와 상관없이 shadow 방향을 틀어야 할때가 있겠고 더 나가 shadow map을 여러개 만들어 한 light에 연결하여 쓸 수도 있겠고(예:주로 넓은 배경에서 아주 큰 쉐도우 맵이 필요로 할때) shadow를 다른 light와 공유해서 쓰고 싶을때도 움직이는 물체와 고정된 물체를 같이 렌더링 할때 움직이는 물체만을 위해선 매 프래임마다 쉐도우를 만들게 해주고 고정된 물체에는 한장으로 재사용이 가능하게 만들어 그 두 쉐도우를 한 라이트에 연결기켜 사용하기 등등등....

이런 자유로움을 가능하게 해주는 이유 중에 하나가 shadow depth map 안에 그 shadow를 제너레이션 했던 camera의 정보가 들어 있기에 어디서든 어느 다른 light와 연결하거나 share가 가능한 것이다.

아직까지 큰 스튜디오에서 ray-tracing shadow 대신 depth map 방식을 쓰는 이유 중에 하나가 이런 자유로움에서 오는 optimization과 cinematic flexibility 같은 장점이 있기 때문일 것이다. 뭐 요즘은 거의 deep map shadow을 쓰지만....

BMRT: A Global Illumination Implementation of the RenderMan Standard

http://www.siggraph.org/education/materials/HyperGraph/radiosity/jgt96.pdf


레리 그리즈가 BMRT를 만들어 워신텅 대학에 발표한 논문!

이런 자료들을 20년이 지나도 이렇게 누구나 쉽게 찾아 볼 수 있게 항상 문서화하는 부분은 정말 우리가 배워야 할 부분이 아닐까 한다. 좋은 프로덕션일수록 이런 문서화 시스템이 잘 되어 있는 것은 당연한것 같다. 지금 내가 있는 부서도 제대로 된 슈퍼바이져로 바뀌면서 제일 먼저 한 것이 모든 것을 문서화 시켜 누구나 볼 수 있게 만든 것이었다. 개인적으로 이부분은 정말로 상당히 중요하다고 생각한다.

simplicity vs. Complication

사람들은 모르면 모를 수록 복잡하게 만드는 경향이 있다. 그리고 쓸데 없는 곳에 힘이 들어간다.

정말 수고 하셨습니다.

어제는 또 한분의 큰 사람이 가셨습니다. 외국에선 아시아의 만델라라는 칭호와 고국에선 빨갱이라는 칭호를 갖고 계셨던 분이 셨습니다. 고국은 몇번이나 그분을 죽이려 했고 세계는 한 목소리로그분을 살리려 했습니다. 이제 세계의 양심들과 지식인들이 슬퍼하고 있습니다. 그를 빵갱이로 불렀던 사람, 모든것을 알면서도 권력과 돈앞에 앞서고 가슴안에 양심을 닫은 무리들과 그리고 무식으로 앞과 과거를 못보는 아둔한 시민들이여.....

Mid-point (or Mid-distance) depth shadow

mental ray의 숨겨진 mid-point 옵션에 대해 바로 전에 얘기를 했는데 생각 난김에 한번 정리를 해보고 넘어 가보도록 하겠다. (참고로 maya에서는 mid-distance로 renderman에서는 mid-point라고 부른다.)

depth map을 이용한 shadow 방식에서 가장 이슈화 된 것은 늘 최적의 값으로 맞춰 주어야 하는 shadow bias 일 것이다. 늘 일정치 않은 값으로 매번 조절을 해야 한다는 것, 그것도 rendering을 걸어 봐야 확인이 가능하다는 것 때문에 lighting artist들에게 이만 저만 귀찮은 존재가 아닐 수 없다.

shadow bias는 shadow camera origin에서 rendering된 z-depth value image를 가지고 rendering 할 real camera에서의 distance 값을 같은 좌표계로 변환해서 거리 값을 비교 할 때 shadow z-depth 값을 (+) 쪽으로 살짝 밀어 너어 겹치지 않게, 즉 self-shadowing이 않나오도록 하는 옵션으로 값이 너무 높으면 object와 유격이 일어 나기에 늘 가장 타이트한 값을 선택해 주어야 한다.

가장 이상적인 shadow를 shadow map에서 얻을 수 있는 방법은 shadow camera coordinate space에서 X,Y 축으로 타이트하게 만드는 것 뿐만 아니라 Z축으로도 타이트하게 만들어 허용 할 수 있는 가장 큰 범위의 Z-depth contrast를 얻어 내어 real camera depth 값과 비교 하게 만드는 것이다. 이는 shadow camera에서 near/far clipping plane을 조절 하므로써 가능하게 되는데 아쉽게도 maya와 mental ray는 자동적으로 shadow camera에 들어온 objects의 bounding boxs를 체크해서 clipping 하는 auto-focus 기능만 지원한다. (경험상 이 같은 auto 기능들은 쉽고 편리함을 주지만 늘 문제의 원인이 되는 경우가 많다.)

간단한 테스트를 해본다면 renderman에서 box object를 작게 만들어서 depth map shadow를 뽑아 렌더링 해본후 다음번엔 그 box를 10배 이상 키워서 렌더링 해보면 shadow가 어떻게 바뀌는지 보일 것이다.

자, 그럼 본론으로 들어가자. 이런 shadow bias의 불편함으로 벗어 나기위해 생각 해 낸 것이 mid-point depth map shadow방식이다. woo algorithm이라고도 불리는데 bias free로 zero bias 값으로도 self-shadowing 이슈 없이 shadow를 만들어 낼 수 있는 방법이다. (renderman에서는 과거 디즈니의 다이노소어 영화에서 처음 소개 되었다.)

원리는 아주 아주 간단하다. shadow depth map을 두 장 rendering 하는데 하나는 기존과 같은 방식으로 그리고 다른 하나는 obejcts의 back-facing 면만 보이게 한후 depth 값을 rendering 하여 이 두 depth maps을 가지고 중간값(mid-point)만 갖는 제 3의 depth map을 만들어 이를 shadow에 쓰면 bias free가 되는 것이다.

내가 좋아하는 간단하면서도 좋은 아이디어이지만 여기에도 단점이 따라다니게 된다. 디테일이 필요하는 상황(예: hair)에서는 geometry의 중간 값을 얻기가 힘들어 지기에 무리가 따르고 어떤 특정한 geometry상황(예: 갑지기 안으로 들어가 깊은 구덩이를 만드는 상황)에서도 중간 값을 못찾아 에러를 낸다는 것이다. 그래서 영화 파이널판타지에서는 이런 상황 때문에 depth map shadowing을 위해 extra geometry를 만들어 미리 메꾸어야 하는 extra work을 해야만 했었다고 한다.