Vit
への視線 Gaze
の
アタリ判定にまつわる周辺のそれををさらにススめることにある.
Fvision
が観測視線
Gaze
を一本えらび,
が観測眼
Eye
にこの
Gaze
を始めると宣言する.
Fvision
はすぐに下請けにして
三次元区画 (ヴォクセル) もとぢめたる
Voxels
に
Eye
と
Gaze
をそえて仕事を丸投げしてしまう.
Voxels
は三次元検索やって
この仕事を担当すべき下請け
Voxel
部分集合を探しだすだけ.
で,
そちらに
Eye
と
Gaze
をそえて仕事をまた丸投げしてしまう.
Voxel
はその三次元区画内にうろうろしてる
Vit
にアタリ判定をまかせてしまい,
アタってるようだったら
その後の処理は
Eye
に押しつけてしまう.
Vit
と
Eye
は純粋仮想関数なるものを
ならべただけの文字どーり
無能な基底クラスである.
そこで上のようなアタリ判定だの
その後の処理だのはライブラリ利用側
(つまり PipeTree とか
小川シミュレイターとか)
で準備されるこれらの派生クラス
(VitCylinder
だの
EyePipetree
だの)
へ実際の計算ぎょーむは
託されることになる.
Fvision
は観測視線
Gaze
上の近傍観測点を動かす.
しかしながら,
それも面倒なのでまた別の下請けたる
TravelGuide
に丸投げしてしまう.
TravelGuide
は視点を動かすにあたって,
しち面倒な周期境界条件計算その他をこなす.
このあたりはなぜかしら
ライブラリ内でまぢになって精密複雑計算しており,
虚業ライブラリらしくない.
将来的には虚業化すべきだろうか?
しかし三次元実存・観測眼とは異なり
境界条件処理は generic かつ
書き直すのがたいへんなので,
利用者側にやらせるべきではない.
Eye
もしくは
TravelGuide
が終了宣言をだすまで上のループを繰りかえす
(つまり一本の Gaze
の処理).
終ったら
Eye
にこの
Gaze
を終ったと宣言する.
Fvision
が細かい仕事をしていたんだけど,
やはりこのあたりは無能に徹するべきだとサトったので,
かくのごとくいよいよ空洞化が進行している今日この頃なのである.
[予備審対策カレー]
私もおしょうばんにあずかってしまった. 小菅せんせーには善行章一本がついたのは 言うまでもない. |