Raytracer in C++ - Introduction - What is ray tracing - 번역

http://www.codermind.com/articles/Raytracer-in-C++-Introduction-What-is-ray-tracing.html

This article is the foreword of a serie of article about ray tracing. It's probably a word that you may have heard without really knowing what it represents or without an idea of how to implement one using a programming language. This article and the following will try to fill that for you. Note that this introduction is covering generalities about ray tracing and will not enter into much details of our implementation. If you're interested about actual implementation, formulas and code please skip this and go to part one after this introduction.

이 아티클은 Ray tracing에 대한 아티클 시리즈중 서문이다. 아마도 Ray tracing이라는 단어는 무엇을 의미하는지 확실히 알지는 못하거나 프로그래밍 언어를 사용해서 어떻게 구현해야 할지 아이디어가 없더라도 들어는 봤을 것이다. 이 아티클과 다음에 나올 것들은 당신이 원하는 것을 채워줄 것이다. 이번 도입부는 Ray tracing에 대해서 우리가 할 구현의 많은 세부사항들은 시작하지 않을 것이고 일반적인 부분으로 구성하였다. 만약 실질적인 구현에 대해서 관심이 있다면 이 부분을 건너뛰고 이 도입부 뒤에 있는 내용으로 가서 공식과 코드를 보라.

What is ray tracing ?

---

Ray tracing is one of the numerous techniques that exist to render images with computers. The idea behind ray tracing is that physically correct images are composed by light and that light will usually come from a light source and bounce around as light rays (following a broken line path) in a scene before hitting our eyes or a camera. By being able to reproduce in computer simulation the path followed from a light source to our eye we would then be able to determine what our eye sees.

Ray tracing은 컴퓨터로 이미지들을 렌더링하기 위해 존재하는 수많은 기법들중 하나이다. Ray tracing의 아이디어는 물리적으로 올바른 상은 빛에 의해 구성된다는 것과 빛은 광원으로부터 나오고 씬 안에서 광선들은 우리 눈이나 카메라에 도달하기전에 산란한다(꺽인 선을 따라감)는 것이다.

Of course it's not as simple as it sounds. We need some method to follow these rays as the nature has an infinite amount of computation available but we have not. One of the most natural idea of ray tracing is that we only care about the rays that hit our eyes directly or after a few rebounds. The second idea is that our generated images will usually be grids of pixels with a limited resolution. Those two ideas together form the basis of most basic raytracers. We will place our point of view in a 3D scene, and we will shoot rays exclusively from this point of view and towards a representation of our 2D grid in space. We will then try to evaluate the amount of rebounds needed to go from the light source to our eye. This is mostly okay because the actual light simulation does not take into account the actual direction of the ray to be accurate. Of course it is a simplification we'll see later why.

물론 이것은 들리는 것 만큼 간단한 것은 아니다. 자연은 무한한 양의 계산을 할 수 있지만 우리는 그럴 수 없으므로 이 광선들을 따라갈 방법이 필요하다. Ray tracing의 자연적인 아이디어중 가장 중요한 것은 우리의 눈으로 바로 들어오는 광선이나 약간의 산란후에 들어오는 광선만 고려하면 된다는 것이다. 두번째 아이디어는 우리가 생성할 이미지들은 보통 제한된 해상도로 픽셀로 이루어진 격자라는 것이다. 이 두가지 아이디어 모두 대부분의 기초적인 Raytracer들의 기본이 되었다. 우리는 3D 씬으로 관점을 두어야 하고 이 관점으로 부터 광선을 쏘고 공간안의 2D 격자로 향하게 할 것이다. 그리고나서 우리는 광원에서 우리눈으로 오는데 필요한 재 산란된 양을 평가할 것이다. 이 방식은 일반적으로 괜찮다.  정확하게 말해서 실제 빛 시뮬레이션은 실제 광선의 방향을 고려하지는 않기 때문이다. 물론 우리가 나중에 알게될 단순화된 방법이다. 

How are raytracers used ?

---

The ideas behind ray tracing (in its most basic form) are so simple, we would at first like to use it everywhere. But it's not used everywhere.

Ray tracing의 배경이 되는 아이디어들은 매우 간단해서 우리는 처음에 모든 곳에 사용하고 싶어 한다. 하지만 모든 곳에서 사용되지는 않는다. 

Ray tracing has been used in production environment for off-line rendering for a few decades now. That is rendering that doesn't need to have finished the whole scene in less than a few milliseconds. Of course we should not generalize and let you know that several implementations of raytracer have been able to hit the "interactive" mark. Right now so called "real-time ray tracing" is a very active field right now, as it's been seen as the next big thing that 3D accelerators need to be accelerating. Raytracer are really liked in areas where the quality of reflections is important. A lot of effects that seem hard to achieve with other techniques are very natural using a raytracer. Reflection, refraction, depth of field, high quality shadows. Of course that doesn't necessarily mean they are fast.

Ray tracing은 현재 몇 십년동안 오프라인 렌더링으로 생산하는 환경에서 사용되어 왔다. 오프라인 렌더링에서는 몇 밀리세컨드보다 적은 시간에 완전한 씬을 완료할 필요가 없다. 물론 우리는 일반화 하지 않았고 "interactive" 하게 하려는 목표를 달성할 수 있는 raytracer의 몇몇가지의 구현방법들을 알지 못한다. 요즘에 "Real-time Ray tracing"이라 불리우는 분야가 매우 활성화되고 있어 3D 가속기의 가속을 필요로 하는것이 다음의 큰일로 보여지고 있다. Raytracer는 반사의 퀄리티가 중요한 곳에서 정말 환영받고 있다. 다른 기술들로는 성취하기 힘들어 보이는 많은 효과들은 raytracer를 사용하므로써 매우 자연스럽게 된다. 반사, 굴절, Depth of field, 고품질 그림자에서 사용된다. 물론 그것들이 빠르다는 것을 의미하는건 아니다.

Graphics card on the other hand they generate the majority of images these days but are very limited at ray tracing. Nobody can say if that limitation will be removed in the future but it is a strong one today. The alternative to ray tracing that graphics card use is rasterization. Rasterization has a different view on image generation. Its primitive is not rays, but it is triangles. For each triangle in the scene you would estimate its coverage on the screen and then for each visible pixel that is touched by a triangle you would compute its actual color. Graphics cards are very good at rasterization because they can do a lot of optimization related to this. Each triangle is drawn independently from the precedent in what we call an "immediate mode". This immediate mode knows only what the triangle is made of, and compute its color based on a serie of attributes like shader program, global constants, interpolated attributes, textures. A rasterizer would for example typically draw reflection using an intermediate pass called render to texture, a previous rasterizer pass would feed into itself, but with the same original limitations which then cause all kind of precision issues. This amnesia and several other optimizations are what allow the triangle drawing to be fast. Raytracing on the other hand doesn't forget about the whole geometry of the scene after the ray is launched. In fact it doesn't necessarily know in advance what triangles, or objects it will hit, and because of interreflexion they may not be constrained to a single portion of space. Ray tracing tends to be "global", rasterization tends to be "local". There is no branching besides simple decisions in rasterization, branching is everywhere on ray tracing.

반면에 그래픽카드는 요즘에 이미지들의 대다수를 생성하지만 Ray tracing에서는 제한적이다. 아무도 미래에 제한이 사라질 것이라고 말하지 않을 수 없지만 오늘날에는 아직 강한 제한이 있다. 그래픽카드에서 Ray tracing의 대안으로 래스터화를 사용한다. 래스터화는 이미지 생성에 다른 견해를 가진다. 이것의 원시 데이터는 광선이 아니라 삼각형이다. 씬 안에 있는 각각의 삼각형마다 화면안의 적용 범위를 추정하고 픽셀이 보이는지 여부를 판별하고 실제 색상을 계산해낸다. 그래픽카드들은 래스터화와 관련된 많은 최적화를 할 수 있었기 때문에 래스터화를 매우 능숙하다. 각각의 삼각형들은 "immediate mode"라 부르는것의 선례로 부터 독립적으로 그려진다. 이 즉시 모드는 오직 삼각형으로 구성되어있다고 알고있고 쉐이더 프로그램, 전역 상수, 속성의 보정, 텍스쳐들과 같은 일련의 속성들을 기반으로 색상을 계산한다. Rasterizer는 전형적인 예로 Render to Texture(이전의 Rasterizer 패스가 반영된)라 불리는 패스를 사용하여 반사를 그리지만 모든 정확도와 관련된 이슈들로 발생하는 근본적인 제한은 가지고 있다. 이런 기억상실증(그리지 않는 것을 말하는듯)과 몇가지 다른 최적화기법들은 삼각형을 빠르게 그릴 수 있게 해준다. 반면에 Raytracing은 광선이 발사된 후에 씬 전체의 Geometry에 대해서는 잊어버린다. 사실 삼각형이나 광선에 맞게될 오브젝트들이 무엇인지 미리 알 필요는 없다. 그것들의 상호반사는 부득이하게 공간의 한 위치에서 일어나지는 않을 것이기 때문이다. Raytracing은 "global"한 경향이 있고 Rasterization은 "local"한 경향이있다. Rasterization에서는 분기없이 간단한 결정을하지만 Raytracing에서는 모든곳에서 계산을 한다.

Ray tracing is not used everywhere in off line rendering either. The speed advantage of rasterization and other techniques (scan line rendering, mesh subdivision and fast rendering of micro facets) has often been hold against true "ray tracing solution", especially for primary rays. Primary rays are the one that hit the eye directly, instead of having rebound. Those primary rays are coherent and they can be accelerated with projective math (the attribute interpolation that fast rasterizers rely upon). For secondary ray (after a surface has been reflecting it, or refracting it), all bets are off because those nice properties disappear.

Raytracing은  Offline Rendering의 모든곳에서 사용되지는 않는다. Rasterization의 속도 이점과 다른 기술들(Scanline Rendering, 메쉬 분할, 소규모 면에 대한 빠른 렌더링)이 있어 종종 실제 "Raytracing 해법"을 특히 1차 광선들에서 나쁘게 보게되곤 한다. 1차 광선은 다시 튕겨나오는 것 대신에 눈으로 바로 들어오는 광선이다. 이 1차 광선들은 일관성 있고 투영 수학계산(빠른 Rasterizer들에 의존되는 속성의 보간)에 의해 가속될 수 있다. 2차 광선(표면에서 반사되거나 굴절된)에서는 멋진 성질이 사라지기 때문에 무효화 된다.

In the interest of full disclosure it should be noted that ray tracing maths can be used to generate data for rasterizer for example. Global illumination simulation may need to shoot ray to determine local properties such as ambiant occlusion or light bleeding. As long as the data is made local in the process that will be able to help a strict "immediate renderer".

알려져야할 밝혀진 사실들에서 흥미로운 점은 Raytracing 수학들은 Rasterizer의 예시를 만들기 위한 데이터를 생성하는대 사용될 수 있다는 것이다.  전역 조명 시뮬레이션은 Ambient occlusion이나 Light bleeding과 같은 지역적 성질을 결정하기 위해 광선을 발사할 필요가 있다. 데이터가 진행중에 지역적인 성질이 만들어지면 "immediate renderer"를 도울 수 있을 것이다.

Complications, infinity and recursion

---

Raytracers cannot and will not be a complete solution. No solution exist that can deal with true random infinity. It's often a trade off, trying to concentrate on what makes or break an image and its apparent realism. Even for off line renderer performance is important. It's hard to decide to shoot billions of rays per millions of pixel. Even if that's what the simulation seems to require. What trade offs do we need to do ? We need to decide to not follow every path possible.

Raytracer들은 완벽한 해법은 없다. 사실상 무한한 임의성을 다룰 수 있는 해법은 없다. 종종 이미지를 만들거나 깨뜨리는 것과 사실적으로 보이게 만드는 것중 어디에 집중하느냐에 따라 Trade off가 발생한다. 심지어 Offline Renderer에서조차 퍼포먼스는 중요하다. 몇백만 픽셀당 몇십억개의 광선을 발사하자고 결정하는건 어려운 일이다. 심지어 만약 그것이 시뮬레이션에서 요구되는 것을 보이게 하더라도 말이다. Trade off를 진행하기 위해 우리가 필요로 하는 일은 무엇인가? 우리는 가능한 모든 경로를 따라가게끔 결정하지 않을 필요가 있다.

Global illumination is a good example. In global illumination techniques such as photon mapping, we try to shorten the path between the light and the surface we're on. In all generality, doing full global illumination would require to cast infinite amount of ray in all the directions and see which percentage hit the light. We can do that but it's going to be very slow, instead, we'll first cast photons (using the exact same algorithm as ray tracing but in reverse from the light point of view) and see what surface they hit. Then we use that information to compute lighting in first approximation at each surface point. We only follow a new ray if we can have a good idea using a couple of rays (perfect reflection needs only one additional ray). Even then it can be expensive, as the tree of rays expands at a geometric rate. We have often to limit ourself to a maximum depth recursion.

전역 조명은 좋은 예시가 된다. Photon Mapping과 같은 전역조명 기술에서 우리는 빛과 우리가 보는 표면과의 경로를 짧게 하려고 한다. 일반적으로 전체 전역 조명을 하는 것은 모든 방향에 대해서 광선들을 무한한 양을 발사해보고 빛에 충돌하는 정도를 확인할 필요가 있다. 우리는 이렇게 할 수는 있지만 이것은 매우 느릴 것이므로 대신에 우리는 먼저 광자(Raytracing과 정확하게 같은 알고리즘을 사용하지만 광원의 위치에서 시선의 역방향으로 이루어진다.)들을 던저보고 표면과 맞는 것들을 확인한다. 그리고 나서 각 표면의 점들에서의 첫번째 근사치에서 빛을 계산하기 위한 정보로 사용한다. 우리가 한쌍의 광선을 이용하는 좋은 아이디어를 떠올릴 수 있다면(완벽한 반사는 오직 하나의 추가적인 광선만 필요로 한다.)하나의 새로운 광선만 쫓으면 된다. 광선의 트리가 기하급수적으로 팽창된다면 이 방식도 비싼 연산이 될 수 있다. 우리는 보통 우리 스스로 재귀에 대한 최대 깊이에 제한을 두어야 한다.

Acceleration structure.

---

Even then, we'll want to go faster. Making intersection tests becomes the bottleneck if we have thousand or millions of intersectable objects in the scene and go for a linear search of intersection for each ray. Instead we definitely need an acceleration structure. Often used are hierarchical representation of a scene. Something like a KD-Tree or octree would come to mind. The structure that we'll use may depend on the type of scene that we intend to render, or the constraints such as "it needs to be updated for dynamic objects", or "we can't address more than that amount of memory", etc. Acceleration structures can also hold photons for the photon mapping, and various other things (collisions for physics).

여기까지 진행해도 더 빨라지기를 원할 것이다. 만약 씬 안에서 검사해볼 오브젝트들이 몇천~몇십만개인데 각각의 광선에 대해서 순차적으로 충돌을 검사해본다면 충돌 테스트하는 부분은 BottleNeck이 될 것이다. 대신에 우리는 가속화 할 구조가 필요해진다. 보통 사용되는 것은 씬을 계층적으로 표현하는 것이다. KD-Tree나 Octree와 같은 것들이 생각날 것이다. 우리가 사용할 그 구조는 우리가 렌더링하려는 씬의 타입이나 "동적인 오브젝트들을 위해 업데이트 될 필요가 있다." 와 같은 제약사항이나 "메모리양 이상의 주소를 접근할 수 없다."와 같은 제약사항 등등에 의존적일 수 있다. 가속화 구조들은 Photon Mapping을 위한 광자들이나 다양한 다른것들(물리연산을 위한 충돌)에 의해 홀드 될 수 있다.

We can also exploit the coherence of primary rays. Some people will go as far as implementing two solutions, one that use rasterization or similar technique for primary rays and raytracing for anything beyond that. We of course need a good mean of communication between both stages and a hardware that is sufficiently competent at both.

우리는 1차 광선의 일관성을 이용할 수 있다. 어떤 사람들은 두가지 해법을 구현할 때까지 진행할 것이다. 하나는 Rasterization을 이용하거나 1차 광선들을 이용하는 것과 비슷한 테크닉이고 또 하나는 그것들 뒤에는 레이트레이싱을 하지 않는 것이다. 물론 각 스테이지와 모두에 충분히 유용한 하드웨어간의 통신의 좋은 방식을 필요로 한다.

------------------------------------------------------------------------------------------------------------------------------------------

-0-;; 평소에 아티클들을 읽어보기는 하지만 일일이 해석해본 건 몇번안된다.

역시 한글로 의미가 통하게 변역해보려고 하니까 힘들고 어색한 부분이 많다.

잘못해석한 부분도 있을 것이고 오타나 어색한 부분도 있을 수 있다.

지속적으로 읽어보면서 그때 그때 수정하는식으로 해야 할 듯 하다.;;;

이것도 많이 하다 보면 늘겠지 -0-;;;;;; ㅋ