View-Dependent Real-time Rain Streaks Rendering

카메라 의존적 파티클 시스템을 이용한 실시간 빗줄기 렌더링

Abstract

Realistic real-time rain streaks rendering has been treated as a very difficult problem because of various natural phenomena. Also, in creating and managing a large number of particles, a large amount of computer resources had to be used. Therefore, in this paper, we propose a more efficient real-time rain streaks rendering algorithm by generating view-dependent rain particles and expressing a large amount of rain even with a small number. By creating a 'rain space' dependent on the field of view of the camera moving in real time, particles are rendered only in that space. Accordingly, even if a small number of particles are rendered, since the rendering is performed in a limited space, an effect of rendering a very large amount of particles can be obtained. This enables very efficient real-time rendering of rain streaks.

1. 서론

다양한 날씨 중, 특정 날씨를 골라 콘텐츠를 제작하면 해당 매체를 접하는 관객 또는 사용자는 특별한 경험을 체험하게 된다. 날씨에는 맑은 날, 구름 낀 날, 비, 눈 등 많은 종류가 있으며 이를 렌더링하는 방법에는 크게 오프라인(off-line)렌더링과 실시간 렌더링 두 가지 방법이 있다. 영화의 경우, 실시간으로 관객과 소통하지 않는 매체이기에 많은 시간이 걸리더라도 촬영 장면에 렌더링 결과물이 자연스럽게 녹아들도록 사실적인 렌더링 결과물을 추구한다. 반대로 게임과 같은 콘텐츠에서는 사실적인 점이 비교적 덜 부각되더라도 실시간성을 매우 강조하기에 영화의 그것에 비해서 다소 낮은 품질의 렌더링 결과물을 추구한다.

본 논문에서는 다양한 자연 현상의 렌더링 중, 비가 내리는 장면에 대한 실시간 렌더링 알고리즘을 제안한다. 비가 내릴 때, 복잡하고 다양한 현상들을 고려해야 하는데 대표적으로 물방울, 물 튀김(splashes), 무지개, 구름 등이 있다. 하드웨어 산업이 폭발적으로 증가해 왔으나 시뮬레이션해야 할 다양한 조건들과 파티클의 양 등을 고려한다면 현재의 하드웨어 계산 능력으로도 실시간 시뮬레이션은 매우 어렵다. 게다가 빗방울 또는 물의 물리적 특성까지 생각한다면 전체 시뮬레이션 과정은 매우 복잡해진다. 따라서 대부분의 실시간 비 렌더링은 비가 올 때의 다양한 현상 중 특정 현상에 집중하며 이를 사실적으로 렌더링하기 위해 실제 현상에 대한 계산값의 근사치를 이용하여 사실적인 실시간 렌더링 결과물을 얻는 방법으로 연구 방법들이 제시되었으며 대부분의 연구에서는 특정 현상 중, 빗방울의 물리적 특성을 고려한 사실적인 빗방울의 모델링에 대한 방법들이 제시되었다[3,14]. 이로 인하여 실시간에서도 사실적 인비 렌더링이 가능하게 되었으며 빗방울 모델링 외에도 빗방울과 물체와의 충돌 감지 등 다양한 현상에 대한 구현 결과를 제시하였으나 화면에 렌더링 되지 않는 영역에서 빗방울과 관련한 계산이 일어나고 있었기에 비효율적이라는 단점이 있다[4].이에 따라 효율적인 렌더링을 위하여 비가 내리는 특정 공간을 정의하고 렌더링을 하는 등 다양한 연구 결과들이 소개되었으나 카메라가 특정 공간을 벗어난 곳을 비추게 되면 빗방울 또는 빗줄기가 보이지 않거나 공간 외의 지역에서는 렌더링되지 않는 어색한 현상들이 존재하였다[8, 9, 13].

본 연구는 파티클에 빗줄기 텍스처를 매핑하고 카메라의 위치와 시야에 의존적인 파티클 시스템을 만들어 앞서 언급한 단점을 보완하는 알고리즘을 제안한다. 또한 사실적인 렌더링을 위하여 빗줄기와 광원과 간단한 산란에 대한 방법도 제시한다. 본 연구를 통해 카메라의 이동과 회전이 일어나도 파티클이 렌더링 되므로 특정 공간에서만 비가 렌더링되는 어색한 장면을 피할 수 있으며 적은 수의 파티클을 렌더링하지만 매우 많은 양의 파티클이 렌더링되는 것처럼 보여 하드웨어의 자원을 효율적으로 운용할 수 있다. 이를 통해 3차원 공간에서 더욱 효율적인 실시간 빗줄기 렌더링이 가능해진다.

2. 관련 연구

사실적인 비 렌더링과 관련하여 많은 연구 방법들이 제시되어 왔으며 대부분은 비가 내리는 현상 중 특정 부분에 집중하고 있다. 가장 기본적인 비 렌더링은 크게 두 가지가 있는데 하나는 반투명한 흰색 오브젝트를 사용하여 카메라 앞에서 렌더링하는 것이다. 또 다른 방법은 미리 계산된 빗줄기 텍스처를 활용하여 해당 장면(scene)에 블렌딩(blending) 하는 것이다.Garg의 빗줄기 텍스처 렌더링은 빗방울에 대한 진동 모델을 제시하는데, 단순한 광도측정 모델이 아닌 카메라 시점과 조명 방향 등에 따라 여러 파라미터를 입력하여 해당 결과들을 하나의 빗줄기 텍스처로 데이터베이스화한다[3]. 이후, 단순한 이미지 기반 알고리즘을 활용하여 유저로부터 depth map, 카메라와 비의 파라미터 등을 입력받아 최종 결과물을 하나의 영상이나 이미지에 렌더링한다. 이 방법은 그들이 사용한 컴퓨터를 기준으로 프레임 당 10초의 성능을 보여주었으며 이는 실시간 렌더링에 매우 부적합한 성능이었다. 본 논문에서는 그들의 데이터베이스를 사용하지만, 실시간으로 사실적인 비 렌더링을 구현한다.

Weber의 연구에서는 실시간으로 사실적인 비 렌더링을 위해 비 시뮬레이션에서 빗방울과 나무의 관계에 초점을 맞추었다. 수관 통과(through-fall) 렌더링에 대해 현상학적으로 분석하여 나무의 덮개(canopy) 부분과 나뭇잎의 물에 대한 저장량에 따른 렌더링 방법을 제시한다[4]. 더 나아가 Nanko의 연구에서 시간적, 공간적으로 dripping through-fall에 대한 분포를 바탕으로 이를 실시간으로 추가 구현하였다[5]. Through-fall에 대해서는 크게 2가지로 나뉘는데 첫 번째는 자연 상태의 비이다.이는 아무 것에도 부딪히지 않은 freethrough-fall이며 덮개 부분과 나뭇잎에 부딪히지 않고 낙하한 경우이다. 두 번째는 앞서 언급한 덮개 부분과 나뭇잎에 부딪혀 물이 튀거나 저장되었다가 현상학, 수문학적으로 다시 나오는 경우이다.Weber의 연구에서는 실시간으로 비가 오는 장면에서 각 나뭇잎의 수용 저장량 등을 고려하여 through-fall에 실제와 매우 비슷한 현상을 구현하였으나 카메라 시야 외에서 일어나는 빗방울의 계산에 대한 설명은 존재하지 않았다.

Rousseau.P 등은 빗방울을 설계할 때 빗방울 내부에서 일어나는 빛의 굴절에 집중한 모델을 제안하였다[6]. 빗방울을 설계할 때 반사도 고려해야 할 사항이지만 그들은 충분히 무시할 만하다고 생각하여 반영하지 않고 굴절에 대해서만 반영하였다. Wang. L 등은 구형의 빗방울에 대하여 광학적 속성들에 대하여 분석하였다[7]. 영상에서 추출한 빗줄기 텍스처를 한 장면의 카메라와 일치하도록 변형하고 해당 이미지에 블렌딩하여 아티스트가 디자인한 효과가 더욱 돋보이도록 하였다. 하지만 이들 또한 실시간 렌더링에 사용하기에는 매우 큰 단점이 있다. 결과 화면에 맞추어 텍스쳐를 변형해야 하므로 실시간 프로그램의 동적인 장면들로 인하여 큰 어려움이 있기 존재하기 때문이다.

Tariq은 Garg의 빗줄기 텍스처를 좀 더 단순화하여 quad에 매핑하여 렌더링하였다[8]. 또한 프로그램과 관련한 작업을 DirectX를 활용하여 GPU에서 처리하였으며 각 파티클은 시간이 지남에 따라 각 프레임에서 기하 셰이더를 사용하여 렌더링 되었다. Tariq은 lightglow등을 활용하여 좀 더 사실적인 렌더링을 보여주었으나 광원과의 관계에 대해서는 묘사되지 않았으며 카메라의 이동 또는 회전에 따라 비가 렌더링되지 않는 모습이 보이기도 했다.

Puig-Centelles 등은 타원을 사용하여 비가 오는 지역을 정의하고 비 시뮬레이션을 반 원통형으로 제한하는 실시간 비 렌더링을 제안하였다[9]. 나아가 그들은 가까운 비(closerain)와 먼 비(farrain)를 따로 설정하고 자연스럽고 실제와 같은 시각적 효과를 위하여 전환(transition)영역을 추가하였다[10]. 관찰자가 비가 내리는 비 공간(rainarea)에 있느냐 없느냐에 따라 전환이 이루어지는데 만일 관찰자가 매우 먼 거리에서 비가 오는 영역을 관찰할 경우, 해당 지역에서만 비가 내리는 어색한 장면이 렌더링 될 수 있었다.

위의 연구들과는 달리 본 논문에서 제안하는 모델은 실시간으로 카메라의 위치를 확인하고, 시야 절두체(viewfrustum) 안에서 파티클이 생성되는 비 공간(rain space)을 생성되도록 하여 시야 외의 지역에서는 파티클이 생성되지 않도록 한다. 이를 통해 실시간으로 카메라가 계속 움직여도 특정 공간에서만 비가 내리지 않고 장면 전체에 비가 내리도록 한다. 또한 적은 수의 파티클을 렌더링하지만 매우 많은 양의 비가 내리는 것처럼 보이는 장면을 연출할 수 있다. 이후 파티클과 광원의 상호작용하는 렌더링에 대한 모델을 제시하여 단순해 보이나 사실적인 렌더링이 가능하다.

Fig. 1은 제안하는 알고리즘의 구현 중, 한 장면을 캡처한 것이다. 4개의 빨간선은 시야 절두체를 구성하는 4개의 선이며 이들이 만나는 점이 실제 카메라의 위치이다. 또한 Fig. 1의 카메라는 다른 위치에서 촬영한 것이다. 그림을 보다시피 파티클은 시야 절두체에서만 생성되며 카메라가 다른 방향을 비추거나 이동할 경우 파티클이 생성되는 위치도 카메라에 따라 이동된다.

Fig. 1. Particles rendered only in the view frustum.

3. 알고리즘

본 연구에서는 카메라에 의존적인 비 공간을 만들어 카메라 시야에서만 파티클이 생성되고 비가 내리도록 하는 실시간 비 렌더링 방법을 제시한다. 이로인하여 카메라 시야 외의 지역에서는 파티클이 생성되지 않으며 적은 수의 파티클을 렌더링하더라도 카메라가 비추는 곳에서만 파티클이 렌더링되므로 적은 수의 파티클로 매우 많은 양의 파티클이 렌더링 되는 효과를 얻을 수 있어 효율적인 렌더링이 가능하다.

이 장에서는 제안하는 모델의 알고리즘에 대하여 설명한다. 본 모델의 전체적인 알고리즘은 Fig. 2에 간략하게 설명되어 있으며 각 절차에 대한 내용은 다음과 같다.

Fig. 2. Algorithm overview of our model.

(1) 파티클의 초기화 및 텍스처 매핑을 실행한다. 본 모델에서는 많은 양의 텍스처를 사용하기 위해 KTX포맷을 사용한다. 이에 대해서는 3.3절에 자세히 설명되어 있으며 또한 파티클은 opengl의 trans-formfeedback 기능을 활용하여 기본적인 파티클 시스템을 구축하였다. (2) 카메라의 시야 절두체를 구성하는 8개의 점과 6개의 면에 대해 계산하고 동시에 절두체와 겹쳐지는 가상의 구를 만든다.(3) 시야 절두체와 가상의 구가 겹쳐지는 부분을 비가 생성되는 공간인 비 공간으로 설정하고 (4) 해당 공간에서만 파티클을 생성하도록 한다.Fig. 2의 (4)는 다른 카메라로 파티클의 위치를 촬영한 것이며 빨간선은 시야 절두체에 대한 4개의 선이다. (5) 이후 광원과의 위치, 세기 등을 고려하여 산란 계산을 해준다. 본 논문에서는 스포트라이트에 대해서만 고려하였다. (6) 위에서 언급된 모든 것들을 최종 렌더링을 한다.

우선 시야 절두체와 비 공간에 대한 언급을 먼저 한 이후, 공간 내에서만 생성되는 파티클에 텍스쳐를 적용하고 빛의 산란에 대한 방법을 논의한다.

3.1 시야에 의존적인(view-dependent) 비 공간 생성

3.1.1 View frustum(시야 절두체) 계산

시야 절두체에 의존적인 비 공간을 생성하기 위해서 먼저 far 면과 near 면의 높이와 폭, 그리고 해당 면의 중심점을 계산하여야 한다. 다음 식 (1)은 그중 각 면의 높이와 폭을 계산한 식이다. 이때 카메라로부터 far면까지의 거리인 dist_far의 값이 클수록 절두체의 크기가 커지게 되어 절두체 내부에서 생성되는 비의 밀도가 매우 낮아지게 된다. 또한, 카메라로부터 멀리 생성된 파티클은 매우 작게 렌더링 되어 잘 보이지 않는다. 따라서 파티클에 대한 카메라로부터 far면까지의 거리는 다른 오브젝트의 far면에 대한 거리보다 더 작은 수로 설정해야 하며 본 논문에서는 50.0으로 설정하였다.

\(\begin{array}{l} h_{f a r}=2 * \tan \left(\frac{\text { fov }}{2}\right) * \text { dist }_{\text {far }} \\ w_{\text {far }}=h_{\text {far }} * \text { aspect ratio } \\ h_{\text {near }}=2^{*} \tan \left(\frac{\text { fov }}{2}\right)^{*} \text { dist }_{\text {near }} \\ w_{\text {near }}=h_{\text {near }} * \text { aspect ratio } \end{array}\)       (1)

여기서 h와 w는 각 면의 높이(height)와 폭(width)을 의미한다. 또한 카메라의 값을 이용하여 각 면의 중심점 C를 구하며 이는 다음 식 (2)에 나타나 있다.

\(\begin{array}{l} C_{\text {far }}=\text { view }+\left(\vec{V} * \text { dist }_{\text {far }}\right) \\ C_{\text {near }}=\text { view }+\left(\vec{V} * \text { dist }_{\text {near }}\right) \end{array}\)       (2)

이때 view는 현재 카메라의 위치이며 ​​는 카메라의 view 방향에 대한 벡터를 의미한다. 이후 near 면과 far 면의 각 꼭짓점을 구해야 한다. 각 꼭짓점에 대한 위치 및 이름은 Fig. 3에 나타나 있으며 이를 구하는 식은 다음 식 (3)과 같다. 여기서 ​​\(\overrightarrow{RIGHT}\)는 \(\overrightarrow{U P}\)​​벡터와 \(\overrightarrow{V }\)​​를 외적하여 정규화한 벡터이다.

Fig. 3. Vertexes and sides of the view frustum.

\(\begin{array}{l} f b r=C_{f a r}-\left\{\overrightarrow{U P} *\left(h_{f a r} * 0.5\right)\right\}+\left\{\overrightarrow{R I G H T} *\left(w_{f a r} * 0.5\right)\right\} \\ f b l=C_{f a r}-\left\{\overrightarrow{U P} *\left(h_{f a r} * 0.5\right)\right\}-\left\{\overrightarrow{R I G H T} *\left(w_{f a r} * 0.5\right)\right\} \\ f t r=C_{f a r}+\left\{\overrightarrow{U P} *\left(h_{f a r} * 0.5\right)\right\}+\left\{\overrightarrow{R I G H T} *\left(w_{f a r} * 0.5\right)\right\} \\ f t l=C_{f a r}+\left\{\overrightarrow{U P} *\left(h_{f a r} * 0.5\right)\right\}-\left\{\overrightarrow{R I G H T} *\left(w_{f a r} * 0.5\right)\right\} \\ n b r=C_{n e a r}-\left\{\overrightarrow{U P} *\left(h_{n e a r} * 0.5\right)\right\}+\left\{\overrightarrow{R I G H T} *\left(w_{n e a r} * 0.5\right)\right\} \\ n b l=C_{n e a r}-\left\{\overrightarrow{U P} *\left(h_{n e a r} * 0.5\right)\right\}-\left\{\overrightarrow{R I G H T} *\left(w_{n e a r} * 0.5\right)\right\} \\ n t r=C_{n e a r}+\left\{\overrightarrow{U P} *\left(h_{n e a r} * 0.5\right)\right\}+\left\{\overrightarrow{R I G H T} *\left(w_{n e a r} * 0.5\right)\right\} \\ n t l=C_{n e a r}+\left\{\overrightarrow{U P} *\left(h_{n e a r} * 0.5\right)\right\}-\left\{\overrightarrow{R I G H T} *\left(w_{n e a r} * 0.5\right)\right\} \end{array} \)       (3)

식 (3)에서 구한 8개의 꼭짓점을 이용하여 하나의 꼭짓점에서 다른 하나로의 꼭짓점으로 이루어진 하나의 벡터값을 구할 수 있는데 이 식은 절두체의 near면과 far면을 제외한 나머지 4개의 면에 대한 벡터이다. 이는 식 (4)에 나타나있으며 R, L, B, T은 각각 오른쪽, 왼쪽, 아래쪽, 위쪽 면에 대한 벡터이며 각 벡터는 정규화되어있다. 각 면에 대한 벡터 또한 Fig. 3에 나타나 있다.

\(\begin{array}{l} R=(n b r-f b r) \times(n b r-n t r) \\ L=(n b l-f b l) \times(n b l-n t l) \\ B=(n b l-n b r) \times(n b l-f b l) \\ T=(n t l-f t l) \times(n t l-n t r) \end{array}\)       (4)

3.1.2 가상의 구 설정

파티클이 생성될 공간을 만들기 위하여 절두체와 겹쳐지는 가상의 구를 만들어야 하는데 우선 구의중심점과 반지름을 설정해야 한다. 가상의 구는 파티클에 대한 절두체의 near면과 far면 사이의 중간 점을 중심으로 하여 최대한 구와 절두체가 겹쳐지도록 한다. 이로 인하여 절두체에서 최대한 많은 공간을 비 공간으로 설정할 수 있다. 가상의 구에 대한 중심점 ​​\(\left(x_{v s}, y_{v s}, z_{v s}\right)\)와 반지름 r_vs를 구하는 식은 식 (5)에 나타나 있다.

\(\begin{aligned} &\left(x_{v s}, y_{v s}, z_{v s}\right)=\left\{\frac{C_{f a r} \cdot x+C_{\text {near }} \cdot x}{2}, \frac{C_{\text {far }} \cdot y+C_{\text {near }} \cdot y}{2}, \frac{C_{\text {far }} \cdot z+C_{\text {near }} \cdot z}{2}\right\}\\ &r_{v s}=\frac{\sqrt{\left(C_{f a r} \cdot x-C_{n e a r} \cdot x\right)^{2}+\left(C_{f a r} \cdot y-C_{n e a r} \cdot y\right)^{2}+\left(C_{f a r} \cdot z-C_{n e a r} \cdot z\right)^{2}}}{2} \end{aligned}\)  (5)

이제 파티클이 생성되는 위치를 정해야 한다. 파티클의 위치는 가상의 구 안에서 무작위로 생성되어야 하므로, 구면 좌표계에서 직교 좌표계로의 계산식을 활용하는데 이때 파티클의 위치는 무작위로 생성되어야 한다. 이에 따라 좌표계 변환 중 θ, Φ를 계산 시, 무작위 변수를 반환하는 ramdom seed(int a, int b) 함수를 이용한다. 이 함수는 a부터 b까지의 범위 중 무작위 수 하나를 반환하는 함수이다.

\(\begin{array}{l} \theta=2^{*} P I^{*} \text { random seed }(0,1) \\ \phi=\arccos \{2 * \text { random } \operatorname{seed}(0,1)-1\} \end{array}\)       (6)

θ, Φ를 활용하여 파티클의 위치를 구하는 식은 식 (7)과 에 설명되어 있으며 x_particle, y_particle, z_particle는 각각 파티클의 x, y, z 좌표이다. 앞서 계산한 구의 중심점에서 ramdom seed(int a, int b)함수를 사용하여 파티클의 위치가 무작위로 설정되도록 하되, 가상의 구의 내부에서 파티클이 생성되어야 하므로 무작위 반환 함수 ramdom seed(int a, int b)의 매개 변수는 구의 반지름을 이용하여 (-r_vs, r_vs)로 해준다.

\(\begin{aligned} x_{\text {particle }} &=\text { random seed }\left(-r_{\text {vs }}, r_{v s}\right) \sin (\phi) \cos (\theta)+x_{v s} \\ y_{\text {particle }} &=\text { random } \operatorname{seed}\left(-r_{v s}, r_{v s}\right) \sin (\phi) \sin (\theta)+y_{v s} \\ z_{\text {particle }} &=\text { random } \operatorname{seed}\left(-r_{v s,} r_{v s}\right) \cos (\phi)+z_{v s} \end{aligned}\)       (7)

이후 파티클은 y축으로 계속 떨어지면서 위치가 업데이트 된다.

위치가 설정된 파티클과 앞서 계산한 시야 절두체를 구성하는 8개의 정점 중 무작위로 2개의 정점을 이용하여 파티클 위치가 시작점이며 정점이 끝점인 벡터 값 2개를 구한다. 이 벡터는 파티클의 위치에서부터 정점까지에 대한 벡터이며 이후 파티클과 절두체의 상하좌우를 이루는 4개의 면과의 관계를 구하기 위한 벡터이다. 이를 구하는 식은 식 (8)에 나타나 있으며 여기서는 nbl(near bottom left)와 ntr(near top right) 점을 사용하였다.

\(\begin{array}{l} \overrightarrow{P A R\ N B L}=\text { pos }_{\text {particle }}-n b l \\ \overrightarrow{P A R \ N T R}=\text { pos }_{\text {particle }}-n t r \end{array}\)        (8)

이후 절두체의 상하좌우 4개의 면에 대한 벡터 중​​, ​​\(\overrightarrow{B}, ​​ \overrightarrow{L}\)은 식 (8)에서 구한 ​​\(\overrightarrow{P A R ~ N B L}\) 벡터를, \(\overrightarrow{R}\)​​과 ​​\(\overrightarrow{L}\) 벡터에는 ​​ \(\overrightarrow{P A R ~ N T R}\) 벡터를 각각 내적 연산을 해준다. 이에 대해서는 식 (9)에 나타나 있다. 결과 값으로 나온 스칼라값은 현재 파티클이 절두체 내부에서 생성되는지, 외부에서 생성되었는지를 알아낼 수 있는 스칼라값이다.

\(\begin{array}{l} n t r R=\overrightarrow{P A R\ N T R} \cdot \vec{R} \\ n b l L=\overrightarrow{P A R\ N B L} \cdot \vec{L} \\ n t r T=\overrightarrow{P A R\ N T R} \cdot \vec{T} \\ n b l B=\overrightarrow{P A R\ N B L} \cdot \vec{B} \end{array}\)       (9)

식 (9)의 결과로 도출된 4개의 스칼라값이 0보다 큰지 작은지에 따라 생성된 파티클의 현재 위치가 절두체의 내부에 있는지, 외부에 있는지 판가름을 내릴 수 있다. 만일 내부에 있을 경우, 그 공간을 비공간으로 설정하고 파티클의 위치를 그대로 두도록 한다.반대로 외부에서 생성되었을 경우, 파티클이 카메라의 시야에 들어오지 않기 때문에 파티클의 위치를 저장하지 않고 다시 계산하여 파티클이 절두체 내부에서 생성되도록 한다. 3.1절에서 언급한 과정에 대한 결과는 Fig. 1에 나타나 있다.

3.2 스포트라이트

앞서 언급한 바와 같이 본 논문에서는 광원의 종류 중 디렉셔널 라이트와 포인트 라이트는 제외하고 스포트라이트를 구현하고 파티클과 해당 광원과 간단한 산란에 대하여 구현한다. 비가 오는 날을 고려한다면 태양으로 대표되는 디렉셔널 라이트나 촛불 등으로 대표되는 포인트 라이트는 비가 올 때 생각할 수 있을 만한 광원이 아니기에 스포트라이트에만 집중한다.

Fig. 4는 산란에 대한 계산 전, 파티클과 광원과의 관계에 대해서 고려해야 할 경우 3가지를 나타낸 것이다. 파티클에서 일어나는 산란을 계산하기 전에 파티클의 위치가 1) 광원의 위에 존재하는 경우, 2) 광원의 아래에 있으나 영향을 받지 않는 경우, 3) 광원의 아래에 있으며 영향을 받는 경우 등 총 3가지의 경우에 대하여 고려를 해야 한다. 스포트라이트가 영향을 끼치는 범위는 원뿔의 형태이기에 광원이 영향을 끼치는 범위를 원뿔 내부로 설정하며 외부와 광원의 위쪽에는 파티클이 광원의 영향을 받지 않는 것으로 간주한다. 물리적인 정확도를 따졌을 때, 1)과 2) 모두 다른 물체로부터 반사해오는 빛이나 물방울 간의 빛의 굴절과 반사 등으로 인하여 어느 정도의 영향을 받으나 이는 매우 미미하며 사람의 눈으로 자세하게 인식할 수 없기에 여기서는 고려하지 않는다.

Fig. 4. 3 Conditions with particles and light sources.

3.2.1 광원의 위(Above the light source)

식 (10)은 파티클과 광원의 위치를 이용하여 두 위치에 대한 벡터 ​​를 계산하고, 파티클이 광원의 위에 존재하는가에 대한 여부를 알 수 있는 스칼라값 updown을 구하는 식이다.

\(\begin{array}{l} \overrightarrow{P S}=\text { pos }_{\text {particle }}-\text { pos }_{\text {spotlight }} \\ \text { updown }=\overrightarrow{P S} \cdot \vec{D} \end{array}\)       (10)

여기서 \(​\overrightarrow{D}​\)​​는 스포트라이트의 빛의 방향에 대하여 정규화된 벡터이다. 식 (10)에서 도출된 스칼라값 updown은 파티클의 현재 위치가 광원보다 위에 있는지 아래에 있는지를 결정하는 스칼라값이다. 이 값이 스포트라이트의 높이, 즉 지면부터 광원까지의 높이보다 높으면 파티클의 위치가 광원의 위에 존재하므로 광원의 영향은 전혀 받지 않는 상태이다. 따라서 이때의 파티클의 색상은 배경과 같은 색상으로 렌더링한다.

3.2.2 광원의 밑(Under the light source)

현재 파티클의 위치가 광원의 위가 아닌 밑에 존재하는 경우에 대해서도 구현이 돼야 한다. Fig. 4의 2)와 3)의 경우가 이에 해당하는데 두 경우는 각각 스포트라이트의 영향을 받느냐, 받지 않느냐에 의해 달라진다.

스포트라이트는 대부분 원뿔의 형태를 띠고 있으며 본 논문에서도 원뿔 형태의 스포트라이트에 대해서 구현하였다. 원뿔은 단순히 말하자면 한 점으로부터의 거리를 가지는 선형 방정식에 의해 크기가 정의되는 무한한 크기의 원의 형태이다. 파티클이 원적당한 크기의 원 안에 있는지 확인을 하면 원뿔의 내부 또는 외부 어디에서 생성되어 업데이트되는지 쉽게 파악할 수 있다. 이를 확인하기 위해 식 (10)의 결과값인 updown과 원뿔의 높이인 h_spotlight를 이용하여 축을 따라 파티클의 현 위치에서의 원뿔의 반경 r_{circle of cone}을 구할 수 있으며 식 (11)에 구하는 식이 나타나있다.

\(r_{\text {circle of cone }}=\left(\text { updown } / h_{\text {spotlight }}\right)(\text { base radius })\)       (11)

여기서 base radius는 스포트라이트의 형태인 원뿔의 밑면의 반지름을 의미한다.

이후 원뿔의 반지름과 비교하기 위해 축에서 점까지의 직교 거리를 계산한다. 이에 대해서는 식 (12)에 나타나 있으며 length()는 매개 변수인 벡터에 대한 크기를 반환해주는 함수이다. 각 변수에 대한 묘사는 Fig. 5에 나타나 있다.

Fig. 5. Structure of spotlights.

\(\text { dist }_{\text {ortho }}=\text { length }\left(\left(\text { pos }_{\text {particle }}-h_{\text {spotlight }}\right)-\text { updown } * \vec{D}\right)\)       (12)

식 (11)의 r_{circle of cone}와 식 (12)의 dist_ortho를 비교하여 파티클의 위치가 광원의 외부에 있는지 내부에 있는지 판별할 수 있는데 r_{circle of cone}의 값이 큰 경우, 파티클은 원뿔의 내부에 존재한다.즉, Fig.4의 3)에해당하는 경우이며 이때 파티클의 색상은 광원의 색상과 같은 색상으로 렌더링한다. 반대로 dist_ortho이 더 큰 경우, 파티클은 광원보다 아래에 있으나 영향을 받지 않는 상태이다. Fig.4의 2)에 해당하는 경우이며 이때는 빛의 색상을 계산하지 않고 배경과 같은 색상으로 렌더링한다. 이때 빛의 세기가 강해질 수록 파티클의 바뀐 색상은 더욱 강해지며 반대로 세기가 약해질수록 파티클의 색상은 더욱 약해진다. 이에 대해서는 식 (13)과 같이 표현이 가능하다.

\(if \left(r_{\text {circle of cone }} \geqq\right.dist \left._{\text {ortho }}\right)\\ color_{particle } = color _{\text {taxture }} \times color _{\text {light }} \times intensity _{\text {light }}\\ else \left(r_{\text {circle of cone }}<\right. dist \left._{\text {ortho }}\right)\\ \text { color }_{\text {particle }}=\text { color }_{\text {texture }} \times \text { color }_{\text {background }} \)       (13)

3.3 텍스쳐 매핑(Texture Mapping)

Garg는 연구 결과물인 rainstreaktexture를 모두가 사용할 수 있도록 png파일로 공개하였다[11]. 본 연구에서는 많은 양의 텍스쳐를 활용하기 때문에 Khronos 그룹에서 제공하는 KTX 포맷을 이용하여 png 파일 여러 개를 하나의 KTX 파일로 만든 이후, 배열 텍스쳐(TextureArray)기능을 사용한다. 배열 텍스쳐 기능을 사용할 경우, 각 텍스쳐는 하나의 텍스쳐 당 하나의 레이어(Layer)를 할당받는다. 이에 따라 파티클 초기화 시 여러 개의 파티클을 만들어 각 파티클 객체당 하나의 텍스처 레이어를 할당한다. 이때 레이어를 할당받는 조건은 무작위이다. Fig. 6은 본 연구에서 사용된 KTX포맷으로 변환한 파일 중 일부를 가져온 것이며 이 파일을 변환하는데 사용한 프로그램은 Github의 프로젝트 중 Image Viewer 3.3이라는 프로그램을 사용하였다[12].

Fig. 6. Rain streaks texture used for texture mapping.

4. 구현 및 실험 결과

본 논문에서 제시하는 카메라에 의존한 비 공간계산 방법은 실시간으로 계속 카메라의 위치와 여러 가지 값들을 계산하고, 파티클의 위치를 생성할 때 난수를 통하여 초기 위치가 설정되기 때문에 많은 계산량이 요구된다. 이에 따라 본 절에서는 총 두 가지의 실험을 진행하여 비교한다. 첫 번째 실험은 난수 생성 방식에 따른 성능이다. 본 논문에서 제안하는 모델에서 파티클은 정해진 범위 내에서 난수로 생성되기 때문에 여러 가지 난수 생성 방식을 비교 및 분석하고 그 중 결과와 성능을 동시에 얻을 수 있는 방법을 제안한다. 두 번째 실험은 제안한 모델을 활용하여 다른 연구의 결과로 도출된 방법과 FPS(FramePerSeconds)를 비교한다. 실험을 진행한 컴퓨터의 CPU모델은 Intel i7–8700이며 Memory 크기는 DDR416Gb2장으로 총 32Gb이다. 또한 그래픽 카드는 GTXGeforce1080ti를 사용하고 있다. 또한 모든 실험은 동일한 환경에서 진행되었다.

4.1 난수 생성 방식에 따른 성능

앞서 언급한 바와 같이 본 논문에서 제안하는 모델은 가상의 구와 절두체가 겹치는 부분이 파티클이 생성되는 위치이기 때문에 실시간으로 카메라 위치에 따른 가상의 구의 지름과 위치를 계산하고 이를 난수를 사용하여 무작위로 파티클의 위치를 생성한다. 이때 어떠한 방식으로 난수를 생성하고 사용하는가에 따라 파티클 숫자에 따른 FPS의 차이가 매우 크게 나타났다. 이에 대한 성능은 Table1에 나타나 있다.

Table 1. FPS for number of Particles according to the random number generation method.

Table 1과 Fig. 7의 randfunction(a)은 난수 발생 시 가장 흔하게 사용되는 rand()를 이용한 것이며 가상의 구에 대해 계산을 하지 않고 단순히 rand() 함수만을 이용하여 절두체 내부에서 생성되도록 한 방법이다. 이는 매우 간편하고 파티클의 개수가 매우 많아도 높은 성능을 보여주었으나 파티클의 위치가 특정 패턴을 보여주며 분포되어 비가 올 때의 무작위적인 위치가 잡히지 않았다. 두 번째 방법인 randusing seed(b)는 기본 rand()함수에 seed를 설정하고 가상의 구를 설정하고 절두체와 겹쳐지는 비 공간에서 파티클을 생성하는 방법이다. 앞선 rand() 함수보다 성능은 다소 떨어질 수 있으나 각 파티클의 위치가 무작위로 분포되어 빗방울이 떨어질 때 무작위로 뿌려지는 느낌을 줄 수 있다. 세 번째 방법은 C++의 uniform_real_distribution(c)을 이용한 것이다. 앞선방법들보다 매우 무작위로 파티클의 위치가 생성되지만, 파티클의 숫자가 많아질 경우, 하드웨어에 부하가 걸려 FPS의 수가 현저히 떨어지게 된다. 이에따라 본 논문에서는 두 번째 방법을 채택하여 실험을 진행하였다.

Fig. 7. Rendering result according to random number generation method.

4.2 다른 모델과의 비교

비교 대상은 Creusetal의 결과물과 Tariq의 결과물이며 두 개의 결과물 모두 제안한 모델과 동일하게 Garg의 빗줄기 텍스쳐를 활용하였다[8,13]. 각 알고리즘의 세부사항들은 다를 수 있으나 결국 사실적인 실시간 비 렌더링을 구현한다는 점에서 FPS를 비교하기에 충분하다. 본 논문에서 제안하는 모델을 포함한 다른 두 가지 모델 모두 동일한 환경에서 실험을 진행하였다. 각 모델에 대한 파티클의 개수에 따른 FPS의 변화는 Fig.8에 나타나 있다.

Fig. 8. Graph of frame change according to particle number.

본 논문에서 제안하는 모델은 비교 대상인 다른 두 개의 모델에 비해 파티클의 개수가 많아질 수록프레임의 저하가 크게 일어났다. 하지만 제안한 모델은 같은 수의 파티클이라도 카메라 시야 내의 비 공간에서만 파티클이 생성되어 다른 두 개의 알고리즘과 같은 수의 파티클을 렌더링하더라도 더욱더 많은 파티클이 렌더링되어 더 많은 양의 비를 그려낼 수 있었다. Fig. 9는 파티클 수에 따른 각 모델의 렌더링 결과물이다.

Fig. 9. Rendering result of each model according to the number of particles.

Fig. 9의 (a)는 본 논문의 모델, (b)는 Tariq의 모델, (c)는 Creus와 Patow의 모델에 대한 렌더링 결과물이다. 세 가지 모델 모두 10500개로 파티클의 개수를 고정한 상태이며 세 가지 렌더링 결과물 모두 같은 파티클 개수를 렌더링하고 있음에도 불구하고 제안한 모델은 육안으로도 구분이 가능할 정도로 더 많은 양의 파티클을 렌더링하고 있다. 이는 적은 수의 파티클로도 많은 양의 비를 표현하여 효율적인 렌더링이 가능하다는 것을 의미한다.

Fig. 9의 (b)인 Tariq의 모델은 파티클의 숫자가 많아지더라도 3가지 알고리즘 중 가장 완만하게 FPS가 떨어지면서 매우 안정적인 성능을 보여주었다. 또한, Fig. 10의 (a)와 같이 광원의 glow효과를 이용하여 매우 사실적인 렌더링 결과물을 제시하였다. 하지만 카메라를 계속 움직일 경우, 파티클이 따라오는 모습을 보여주었으나 어느 순간 Fig. 10의 (b)와 같이 파티클이 카메라를 따라오지 못하여 파티클이 렌더링 되지 않는 어색한 모습을 보여주었다.

Fig. 10. Tariq’s rendering results as the camera moves.

Creus와 Patow가 제시한 알고리즘은 파티클의 개수가 증가할 때 fps가 비교적 안정적으로 떨어진다. Fig. 8의 그래프에는 없지만 파티클의 개수를 10,500개를 넘기도록 설정하더라도 실시간으로 렌더링하기에 매우 충분한 결과물을 보여주었다. Fig. 11과 같이 큐브 내부와 같은 특정 공간에서 파티클이 생성되었으나 카메라를 움직이거나 렌즈를 축소시킬 경우, 해당 지역에서만 파티클이 생성되어 비가 내리며 그 외의 지역에서는 파티클이 생성되지 않는 어색한 모습이 렌더링 되었다. 또한 카메라가 파티클이 생성되는 곳을 비추지 않는 때에도 파티클이 생성되고 충돌처리가 감지되는 등 매우 비효율적으로 실시간 렌더링이 되고 있었다.

Fig. 11. Creus and Patow’s rendering results as the camera moves.

본 논문에서 제시하는 모델은 Fig. 8의 그래프에서 나타난 것처럼 파티클의 개수가 많아질수록 3가지 알고리즘 중 가장 FPS의 변화가 크게 나타난다. 앞서 언급하였듯이 실시간으로 움직이는 카메라의 위치와 시야 절두체에 대한 각각의 값들을 계산하고, 비 공간을 만들기 위해 가상의 구에 대한 계산을 통하여 파티클의 위치를 지속해서 업데이트해 주어야 하므로 계산량이 매우 많아진다. 하지만 Fig. 12와 같이 파티클이 생성되는 비 공간은 카메라에 종속적이므로 카메라가 이동하거나 Fig.12의 (a)와 같이 zoomin 또는 (b), (c)와 zoomout을 하는 등 카메라에 변화가 있더라도 그에 따라 움직이게 되어 일부 지역에서만 파티클이 생성되어 비가 내리는 어색한 렌더링이 일어나지 않는다. 또한, Fig.12의 각 경우는 파티클이 10, 500개일 때의 렌더링 결과물을 촬영한 것이다. 그림을 보다시피 10, 500개의 파티클도 카메라의 시야내에서만 생성되고 이외의 지역에서는 전혀 생성되지 않기 때문에 많은 양의 비가 내리는 느낌을 줄 수 있다.

Fig. 12. Particle position change as the camera moves.

5. 결과

다른 연구 또는 앞선 실험에서 보았다시피 본 연구의 알고리즘은 성능적인 면에서는 다른 알고리즘과 비교하여 다소 뒤쳐진 모습을 보이고 있다. 하지만 선행된 연구에서는 카메라의 위치가 바뀌었을 때 파티클의 위치도 카메라를 따라 이동하는 경우가 거의 없었으며 매우 많은 수의 파티클을 생성하고 관리하기 때문에 컴퓨터의 하드웨어 자원을 낭비하는 경우가 존재하였다. 이에 본 연구는 카메라가 비추는 곳에서만 파티클이 렌더링되도록 하는 카메라에 의존적인 비 공간을 생성하였으며 파티클에 빗줄기 텍스처를 매핑하여 효율적인 실시간 렌더링을 구현하였다. 또한 비 공간의 크기를 작게 만들고 파티클의 밀도를 최대한 높여 적은 수의 파티클로도 많은 양의 비가 내리도록 보이는 효과를 얻을 수 있었다.

Fig. 13은 빛의 색상, 위치 등 모든 게 같은 환경에서 파티클의 개수만 조절하여 촬영한 렌더링 결과물이다. (a), (b)의 경우에는 렌더링되는 파티클의 개수가 적어 산란으로 인한 파티클의 변화가 잘 보이지 않는다. (c)의 경우, 10500개의 파티클 개수를 렌더링하고 있으며 비가 제법 온다는 느낌을 주고 있음을 알 수 있다. 또한 (d)의 경우 파티클의 개수가 가장 많은 49500개이며 비가 매우 많이 오는 듯한 느낌의 렌더링 결과물을 보여주고 있다.

Fig. 13. Rendering result of proposed model according to the number of particles.

Fig. 14는 빛의 색상 변화에 따른 렌더링 결과물이다. (a)는 빛의 색상이 (R, G, B)=(1, 0, 0)일 때이며 광원의 영향을 받는 파티클은 광원의 색상에 따라 붉은 색으로 변화해 있는 것을 확인할 수 있다. (b)는 (R, G, B)=(0, 1, 0)일 때이며 역시나 광원의 색상에 따라 파티클이 초록색으로 변해있다. (c)는 앞선 다른 그림들과 같이 (R, G, B)=(0, 0, 1)일 때 이며 배경색이 회색이라 잘 보이지는 않지만 광원의 영향권에 있는 파티클은 광원의 색상에 따라 색이 변경되어 있다.

Fig. 14. Rendering result according to light color.(a) (R, G, B) = (1, 0, 0), (b) (R, G, B) = (0, 1, 0), and (c) (R,G, B) = (0, 0, 1).

6. 토론 및 향후 연구

사실적인 비 렌더링 기법은 매우 다양한 분야에서 사용할 수 있다. 본 논문에서 목표를 하는 실시간 렌더링에서는 대표적으로 게임에서 활용할 수 있으며 이를 통하여 좀 더 사실적인 게임 장면을 연출할 수 있다. 또한, 실시간 렌더링에서 좀 더 응용하여 오프라인 렌더링, 즉 좀 더 사실적인 측면을 강조하여 영화나 애니메이션 등에도 렌더링하여 더 멋진 결과물을 만들어낼 수 있다.

실시간 렌더링으로 폭을 좁혔을 때, 중요하게 고려되어야 할 것은 fps와 같은 성능과 환경에 어울리는 효과 조성이다. 성능은 뛰어나지만, 해당 환경과 어울리지 않는 렌더링을 할 경우, 해당 매체를 접하는 유저 입장에서는 매우 어색한 경험을 하게 된다. 반대로 환경과 잘 어울리나 성능은 떨어질 때에는 사용자 관점에서 답답함이나 어지럼증 등 해당 매체에 대해서 부정적인 감정을 가진다.이전 연구에서는 해당 환경에 잘 녹아들면서 매우 사실적인 실시간 비 렌더링 알고리즘들을 제안하였다. 하지만 대부분은 카메라 시야외에서의 부분에서도 렌더링하거나 몇몇 알고리즘은 충돌 처리까지 하여 비효율적인 비 렌더링 방법을 제안하였다. 이에 따라 본 연구에서는 빗줄기 텍스처를 파티클에 매핑한 후, 카메라의 시야 내에서만 렌더링 되도록 하는 효율적인 렌더링 방법을 제시하여 카메라가 비추는 곳 외의 지역에서는 렌더링이 되지 않는 알고리즘을 제안하였다. 이로 인해 기존 연구와는 달리 카메라가 렌더링하는 지역 외의 곳에서는 파티클에 대한 계산이 일어나지 않아 효율적인 렌더링이 가능하며, 적은 수의 파티클을 이용하더라도 많은 비가 오는 듯한 렌더링이 가능해졌다. 또한 단순히 카메라의 시야에서만 렌더링 되는 것이 아닌 광원의 변화가 파티클의 변화에도 영향을 주기 때문에 좀 더 사실적인 렌더링 결과를 보여주고 있다.

위와 같은 장점에도 불구하고 본 연구 방법은 transformfeedback을 이용하여 파티클 시스템을 구축하였기 때문에 개별적인 파티클의 관리가 직관적이지 않아 힘든 부분이 있다. 또한, 실시간으로 계속 카메라의 위치가 업데이트되기 때문에 이에 따른 계산량이 매우 많아져 Fig.8의 그래프와 같이 파티클 숫자가 늘어날수록 매우 급격하게 FPS가 떨어진다. 추후 연구에서는 우선 파티클 시스템을 직접적으로 관리하기 용이하게 transformfeedback이 아닌 다른 방법으로 구축해볼 것이며 또한 실시간으로 업데이트되는 파티클의 위치를 GPU 컴퓨팅을 이용해볼 예정이다.