Friday, February 19, 2010

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.

Sunday, February 14, 2010

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의 이해와 활용을 위해서는 알아야 할 부분이 아닌가 생각된다.

Sunday, February 7, 2010

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쪽에서 정말 빠르게 연구 되고 발전 된다는 것을 눈치 챘다면 주목 안 할수가 없는 부분인것 같다.

Thursday, February 4, 2010

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를 계산을 하든 말든 그리 렌더링 타임이 차이가 나지 않는다. 무슨 마술도 아니고....  계속....

Tuesday, February 2, 2010

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