曲がった迷路その31 - パラメータの設定値の影響

こないだ動くようになった迷路生成。パラメータの値によってどうかわるかみてみた。

迷路作成結果とパラメータの値による違い

featureSizeの値

featureSizeの値は、他のいろいろなパラメータのもとになっていて長さの指定はすべてこの値に対する比で指定するようになっている。

featureSizeそのものはFourier変換面でのカットオフを決めていて、その外（高い空間周波数）を0にする。featureSizeが1のときはFFTの最大周波数をカットオフにすることになって、何もしないのと同じになる。

だから1より大きな値を指定すべきである。1よりも小さな値を指定したとき、ポテンシャル全面で1になるはずだけど、斜め方向にはカットオフの外に出る成分もあるので軸に沿うような壁ばかりができる場合もある。さらに小さな値を指定すると全面1になってランダムウォークに近づくはずである。

ポテンシャルサイズ

2次元FFTの大きさのことで任意の整数がとれるのはfftwのおかげ。vDSPにもFFTのルーチンがあってどのMacOS Xにもインストールさせているけど大きさが2のベキに限られる。FFTは2のベキが効率が一番いいので画像や音声の操作にはいいんだけど、迷路の縦横比がいつも正方形というはつまらない。任意サイズが扱えるようにしておいた方がいい。
fftwは

• 多次元の任意のサイズに対応する
• fftwはFFTに特化してるわりにはサイズが大きい

であるので、今回の場合に向いているけど、アプリのバンドルに含めるといっきにでかくなってしまう。今回の場合、アプリ全体の効率にFFTが律速しているわけではないので、遅くてもいいから独自実装する、というのもありえる。

できあがる迷路の壁どうしの距離はfeatureSizeできまるのでポテンシャルサイズを大きくしてもそれに比例してfeatureSizeを大きくすると、できあがった迷路の壁密度は同じくらいになる。

同じ壁密度にするなら、なるべくポテンシャルサイズとfeatureSizeを大きくとった方がいい。というのはfeatureSizeが大きい方がスペックルパターンの粒度が大きく（つまりなだらかに）なってバイキュービック補間に伴う数値的な不安定性が現れにくくなるからである。

できあがった迷路をpdf出力したときにポテンシャルの1画素が1mmになるようにしたので、ポテンシャルサイズを大きくするとpdfのカンバスサイズが大きくなるのと、FFTに時間がかかってドキュメントウィンドウの表示までちょっと考え込むようになる。

また、繰り返しのアルゴリズムが切り替わったときに、候補となるポテンシャルの値の低い格子点の数が増えるので極端に遅くなる。

ということでこのへんは兼ね合い。

branchingProbability

伸びた壁の途中から壁を分岐させる確率なので、この値が大きいと枝分かれが増える。

図-35はbranchingProbabilityだけを変えて生成した迷路で左がbranchingProbability=1で右がbranchingProbability=10^-4のとき。branchingProbabilityが大きいと壁が山の稜線のような形に伸びる。

見た目は明らかに違うけど、それ以上に枝分かれが多いほうがぱっと見て解がわかるものができやすい。どうしても均一に成長してしまうせいだろう。また、枝分かれが多いほうが完成までの時間は短くなる。

Q値（αの値）

繰り返しのアルゴリズムの切り替えをする値で、小さくすると完成までははやいけど枝分かれが多くなる。これも悩ましいパラメータで、壁を伸ばすアルゴリズムを考え直したほうがいいかもしれない。

壁長さのσの値

σは単位壁の長さの再尤値を表す。これがfeatureSizeより長いとポテンシャルの山谷を飛び越えることになって、解を塞いだり自己交差を作ったりする。一方であまり短すぎるとroot壁の衝突回避ポテンシャルを超えられなくなって壁が作られなくなってしまう。なかなか微妙なパラメータ。スライダで設定できる範囲は表示で0〜2までになっているけど、なかで適当なスケーリングをして現状featureSizeの0〜1倍までしか設定できなくなっている。自己交差もそれなりに面白いけど。

残っている作業

改良すべき点は多いけど、とりあえず

• 日本語リソース
• ユーザインターフェイスをわかりやすく
• SMCIterationTerminatorの別thread化

ぐらいか。でも、動いてしまうとあまりやる気無くなるのよね。