Mercurial > hg > Papers > 2022 > tawata-thesis
comparison text/chapter2.texi @ 2:192a425a7f10 default tip
final commit
author | Masato Tawata <e185761@ie.u-ryukyu.ac.jp> |
---|---|
date | Thu, 17 Feb 2022 17:33:16 +0900 |
parents | ee7afe39f461 |
children |
comparison
equal
deleted
inserted
replaced
1:ee7afe39f461 | 2:192a425a7f10 |
---|---|
1 \chapter{関連研究および基礎概念} | 1 \chapter{基礎概念} |
2 \section{基礎概念について} | 2 \section{OpenALについて} |
3 \subsection{OpenALについて} | 3 OpenALとはクロスプラットフォームに対応し,ゲームやその他の多くのオーディオアプリケーションで利用できる3DオーディオAPIである.いくつかの実装が存在し,現在はOpenAL-Softが主流な実装となっている. |
4 OpenALとはクロスプラットフォームに対応し、ゲームやその他の多くのオーディオアプリケーションで利用できる3DオーディオAPIである。いくつかの実装が存在し、現在はOpenAL-Softが主流な実装となっている。 | 4 3次元空間上での音の表現に適しており,簡素な記述で立体的な音場を表現する事ができる. |
5 3次元空間上での音の表現に適しており、簡素な記述で立体的な音場を表現する事ができる。 | |
6 | 5 |
7 OpenALの構造は以下の様になっている。 | 6 OpenALの構造は以下の様になっている. |
8 \begin{figure}[htbp] | 7 \begin{figure}[htbp] |
9 \begin{center} | 8 \begin{center} |
10 \includegraphics[width=70mm]{./figures/openal.pdf} | 9 \includegraphics[width=70mm]{./figures/openal.pdf} |
11 \caption[OpenAL_Context]{OpenALの基本構造} | 10 \caption[OpenAL_Context]{OpenALの基本構造} |
12 \label{fig:opeal} | 11 \label{fig:opeal} |
13 \end{center} | 12 \end{center} |
14 \end{figure} | 13 \end{figure} |
15 | 14 |
16 Deviceの下にコンテキストと、音源の実際の信号などを保持しているBufferが存在する。Contextは複数存在し、それぞれのContextに音を受け取る役割を持つListenerが1つある。 | 15 Deviceの下にコンテキストと,音源の実際の信号などを保持しているBufferが存在する.Contextは複数存在し,それぞれのContextに音を受け取る役割を持つListenerが1つある. |
17 SourceはContext内に複数個設ける事ができ、Bufferからの情報を読み取り実際に音声を再生する役割を持つ。 | 16 SourceはContext内に複数個設ける事ができ,Bufferからの情報を読み取り実際に音声を再生する役割を持つ. |
18 | 17 |
19 \subsection{Unityについて} | 18 \section{Unityについて} |
20 UnityはUnity Tecnologiesが開発しているクロスプラットフォームに対応したゲームエンジンである。 | 19 UnityはUnity Tecnologiesが開発しているクロスプラットフォームに対応したゲームエンジンである. |
21 C\#でのプログラミングが可能で、レンダリングの機能も充実しているためゲーム制作以外でも、研究用途やコンピュータグラフィックスの分野でも用いられる。 | 20 C\#でのプログラミングが可能で,レンダリングの機能も充実しているためゲーム制作以外でも,研究用途やコンピュータグラフィックスの分野でも用いられる. |
22 本研究ではC++を用いてOpenALによる3次元音響のシステムを構築するためC++によるコードをUnity上で利用できる様にする必要がある。 | 21 本研究ではC++を用いてOpenALによる3次元音響のシステムを構築するためC++によるコードをUnity上で利用できる様にする必要がある. |
23 UnityにはUnity native pluginという機能があり、CやC++その他の言語で書かれたプログラムに対してCのインターフェースを介してアクセスする事ができる。 | 22 UnityにはUnity native pluginという機能があり,CやC++その他の言語で書かれたプログラムに対してCのインターフェースを介してアクセスする事ができる. |
24 | 23 |
25 \subsection{レイキャストについて} | 24 \section{レイキャストについて} |
26 \label{section_raycast} | 25 \label{section_raycast} |
27 コンピューターにおいて、ある地点から特定の方向に障害物が存在するかを判定する際にレイキャストが用いられる。 | 26 コンピューターにおいて,ある地点から特定の方向に障害物が存在するかを判定する際にレイキャストが用いられる. |
28 走査したい方向に仮想的な光線を飛ばし、その光線と物体を構成するポリゴンと呼ばれる3角形が交差しているか否かで障害物の有無を判定する方法が代表的である。 | 27 走査したい方向に仮想的な光線を飛ばし,その光線と物体を構成するポリゴンと呼ばれる3角形が交差しているか否かで障害物の有無を判定する方法が代表的である. |
29 この様な実装を工夫をせずに行うと全てのポリゴンに対して光線との交差判定をする必要があるため無駄な処理が多い。そのため通常は後述する空間分割などを用いて判定するポリゴンを減らす工夫がなされる。 | 28 この様な実装を工夫をせずに行うと全てのポリゴンに対して光線との交差判定をする必要があるため無駄な処理が多い.そのため通常は後述する空間分割などを用いて判定するポリゴンを減らす工夫がなされる. |
30 | 29 |
31 \subsection{Any-angle path planning} | 30 \section{Any-angle path planning} |
32 ゲーム上のある地点からある地点までの最短距離を求めたい場合、ダイクストラ法\cite{Dijkstra}を用いた経路探索アルゴリズムが用いられる。 | 31 ゲーム上のある地点からある地点までの最短距離を求めたい場合,ダイクストラ法\cite{Dijkstra}を用いた経路探索アルゴリズムが用いられる. |
33 ダイクストラ法ではノードとそれらを繋ぐエッジで構成されたグラフ構造を基に最短経路を求める。 | 32 ダイクストラ法ではノードとそれらを繋ぐエッジで構成されたグラフ構造を基に最短経路を求める. |
34 3次元空間上ではノードが空間上の位置を表し、エッジはその空間同士が接続されているか(ノード間に障害物がない)を表現している。 | 33 3次元空間上ではノードが空間上の位置を表し,エッジはその空間同士が接続されているか(ノード間に障害物がない)を表現している. |
35 ゲームではダイクストラ法の中でもA*アルゴリズムがよく利用されているが、欠点も存在する。 | 34 ゲームではダイクストラ法の中でもA*アルゴリズムがよく利用されているが,欠点も存在する. |
36 それは、A*は探索を始めるノードから隣接するノードを辿っていくことで経路を計算するため、ノード間の角度がグラフの構造に依存してしまうのである。例えばグラフ上のそれぞれのノードが隣接する上下左右の4方向のノードのみと接続されている場合、計算された経路は90度間隔でしか他のノードと接続できない。 | 35 それは,A*は探索を始めるノードから隣接するノードを辿っていくことで経路を計算するため,ノード間の角度がグラフの構造に依存してしまうのである.例えばグラフ上のそれぞれのノードが隣接する上下左右の4方向のノードのみと接続されている場合,計算された経路は90度間隔でしか他のノードと接続できない. |
37 これを解決するアルゴリズムがAny-angle path planningである。 | 36 これを解決するアルゴリズムがAny-angle path planningである. |
38 Any-angle path planningはパスがグラフの構造に制限される事なく、任意の角度でノード同士を接続することができるアルゴリズムである。Any-angeでない経路探索アルゴリズムと比較してより適切なパスを計算できる。 | 37 Any-angle path planningはパスがグラフの構造に制限される事なく,任意の角度でノード同士を接続することができるアルゴリズムである.Any-angeでない経路探索アルゴリズムと比較してより適切なパスを計算できる. |
39 | 38 |
40 \subsection{空間分割} | 39 \section{Theta*アルゴリズム} |
41 \ref{section_raycast}の最後で述べたように空間を離散化せずにレイキャストなどの衝突判定を行うことは計算量の観点から見て非効率なため、同時に空間分割を用いた最適化がなされる場合が多い。 | 40 Any-angle path planningの一つであるTheta*は親ノードを設定する際に,隣接しているノードの親ノードとの間に障害物があるかどうかを探索し障害物がなければ親ノードにその親ノードを設定する. |
42 空間分割の方法には4分木やkd木、BSP木など分割の仕方が異なる方法が多数存在するが、基本的には空間を分割しそれぞれの空間に属するオブジェクトを登録し、分割した空間をさらに分割して子空間を生成、子空間に属するオブジェクトをその子空間に登録、という操作を繰り返してオブジェクトが所属する空間を小さくしていくというのが主な目的である。 | |
43 | 41 |
44 以下に4分木での具体例を示す。 | 42 以下にTheta*の疑似コード\cite{ThetaStar}を示す. |
43 Theta*で特徴的なのが,アルゴリズム\ref{alg1}の19行目の引数のノード間の障害物の有無を返すLineOfSight関数である. | |
44 自分の親ノードと隣接ノードのLineOfSightを判定し,障害物がない場合隣接ノードに自分の親ノードを直接設定する.そのため,Goalノードから親ノードを順にたどってパスを生成する際に余分なノードを経路に含めずに計算する事ができる. | |
45 | |
46 | |
47 | |
48 | |
49 \begin{algorithm}[H] | |
50 \caption{Theta*} | |
51 \label{alg1} | |
52 \begin{algorithmic}[1] | |
53 \Function{Main}{void} | |
54 \State $g(start) := 0$ | |
55 \State $parent(start) := start$ | |
56 \State $open:= \emptyset$ | |
57 \State $closed:= \emptyset$ | |
58 \State $open.Insert(start, 0)$ | |
59 \While{$open \neq \emptyset$} | |
60 \State $n=open.Pop()$ | |
61 \If{$n = n_{goal}$} | |
62 \State \Return "Find path" | |
63 \EndIf | |
64 \State $close := close \cup n$ | |
65 \ForAll{$n' \in neighbors(n)$} | |
66 \If{$n'\notin close$} | |
67 \If{$n' \notin open$} | |
68 \State $g(n')=\infty$ | |
69 \State $parent(n')=NULL$ | |
70 \EndIf | |
71 \State UpdateVertex$(n,n')$ | |
72 \EndIf | |
73 \EndFor | |
74 \EndWhile | |
75 \EndFunction | |
76 \Function{UpdateVertex}{$n,n'$} | |
77 \If{LineOfSight$(parent(n),n')$} | |
78 \If{$g(n)+c(n,n')<g(s')$} | |
79 \State $g(parent(n)):=g(n)+c(parebt(n),n')$ | |
80 \State $parent(n'):=parent(n)$ | |
81 \If{$n' \in open$} | |
82 \State open.Remove(n') | |
83 \EndIf | |
84 \State open.Insert(n',g(n')+h(n')) | |
85 \EndIf | |
86 \Else | |
87 \If{$g(n)+c(n,n')<g(n')$} | |
88 \State $g(n'):=g(n)+c(n,n')$ | |
89 \State $parent(n'):=n$ | |
90 \If{$n' \in open$} | |
91 \State $open.Remove(n')$ | |
92 \EndIf | |
93 \State $open.Insert(n',g(n')+h(s'))$ | |
94 \EndIf | |
95 \EndIf | |
96 \EndFunction | |
97 \end{algorithmic} | |
98 \end{algorithm} | |
99 | |
100 \section{空間分割} | |
101 \label{spatialdiv} | |
102 \ref{section_raycast}の最後で述べたように空間を離散化せずにレイキャストなどの衝突判定を行うことは計算量の観点から見て非効率なため,同時に空間分割を用いた最適化がなされる場合が多い. | |
103 空間分割の方法には4分木やkd木,BSP木など分割の仕方が異なる方法が多数存在するが,基本的には空間を分割しそれぞれの空間に属するオブジェクトを登録し,分割した空間をさらに分割して子空間を生成,子空間に属するオブジェクトをその子空間に登録,という操作を繰り返してオブジェクトが所属する空間を小さくしていくというのが主な目的である. | |
104 | |
105 以下に4分木での具体例を示す. | |
45 \begin{figure}[htbp] | 106 \begin{figure}[htbp] |
46 \begin{minipage}[b]{0.45\linewidth} | 107 \begin{minipage}[b]{0.45\linewidth} |
47 \centering | 108 \centering |
48 \includegraphics[width=40mm]{./figures/noSpatialPartitioning.pdf} | 109 \includegraphics[width=40mm]{./figures/noSpatialPartitioning.pdf} |
49 \label{nsp} | 110 \label{nsp} |
55 \caption{空間分割あり} | 116 \caption{空間分割あり} |
56 \label{sp} | 117 \label{sp} |
57 \end{minipage} | 118 \end{minipage} |
58 \end{figure} | 119 \end{figure} |
59 | 120 |
60 図\ref{nsp}では、赤色のオブジェクトが他の物体と衝突しているかを判定するためには、青色のオブジェクト全てに対して計算を行わななければならないが、 | 121 図\ref{nsp}では,赤色のオブジェクトが他の物体と衝突しているかを判定するためには,青色のオブジェクト全てに対して計算を行わななければならないが, |
61 図\ref{sp}では4分木アルゴリズムを使用し空間が4つに分割されており、他の空間に属している緑色のオブジェクトに関しては衝突していないことが保証されるため、同じ空間に属する青色のオブジェクト1つに対してのみ計算することで衝突する可能性のあるオブジェクトの判定を行う事ができる。 | 122 図\ref{sp}では4分木アルゴリズムを使用し空間が4つに分割されており,他の空間に属している緑色のオブジェクトに関しては衝突していないことが保証されるため,同じ空間に属する青色のオブジェクト1つに対してのみ計算することで衝突する可能性のあるオブジェクトの判定を行う事ができる. |
62 分割は任意の数だけ行う事ができ、分割した空間の一つをさらに4つに分解して粒度を細かくする事が可能である。オブジェクトの数が多い際は分割数を増やすことで衝突判定の計算量を減らせるが、メモリの使用量が増加するため空間の特性に応じた適切な分割数を用いる必要がある。 | 123 分割は任意の数だけ行う事ができ,分割した空間の一つをさらに4つに分解して粒度を細かくする事が可能である.オブジェクトの数が多い際は分割数を増やすことで衝突判定の計算量を減らせるが,メモリの使用量が増加するため空間の特性に応じた適切な分割数を用いる必要がある. |
63 | 124 |
64 \subsection{8分木} | 125 \section{8分木} |
65 8分木は4分木を3次元空間上で利用できるようにしたアルゴリズムである。 | 126 8分木は4分木を3次元空間上で利用できるようにしたアルゴリズムである. |
66 一つの空間を8つの立方体に分割することを繰り返していくことで、それぞれのオブジェクトの所属空間を決定する。 | 127 一つの空間を8つの立方体に分割することを繰り返していくことで,それぞれのオブジェクトの所属空間を決定する. |
67 \begin{figure}[htbp] | 128 \begin{figure}[htbp] |
68 \begin{minipage}{0.3\hsize} | 129 \begin{minipage}{0.3\hsize} |
69 \centering | 130 \centering |
70 \includegraphics[width=20mm]{./figures/octree_Level0.pdf} | 131 \includegraphics[width=40mm]{./figures/octree_Level0.pdf} |
71 \label{octree0} | 132 \label{octree0} |
72 \caption{分割数0} | 133 \caption{分割数0} |
73 \end{minipage} | 134 \end{minipage} |
74 \begin{minipage}{0.3\hsize} | 135 \begin{minipage}{0.3\hsize} |
75 \centering | 136 \centering |
76 \includegraphics[width=20mm]{./figures/octree_Level1.pdf} | 137 \includegraphics[width=40mm]{./figures/octree_Level1.pdf} |
77 \caption{分割数1} | 138 \caption{分割数1} |
78 \label{octree1} | 139 \label{octree1} |
79 \end{minipage} | 140 \end{minipage} |
80 \begin{minipage}{0.3\hsize} | 141 \begin{minipage}{0.3\hsize} |
81 \centering | 142 \centering |
82 \includegraphics[width=20mm]{./figures/octree_Level2.pdf} | 143 \includegraphics[width=40mm]{./figures/octree_Level2.pdf} |
83 \caption{分割数2} | 144 \caption{分割数2} |
84 \label{octree2} | 145 \label{octree2} |
85 \end{minipage} | 146 \end{minipage} |
86 \end{figure} | 147 \end{figure} |
87 | 148 |