独り言日記
2004/04/30 update.

最近のナイスメール
更新日時 2004/04/30
内容 「jaian@doraemon-mail.com」というところからメール来ました。
タイトルは「I cannot forget you!」。中身は「lovely, :-)」
ドラえもんメールでしかも、ジャイアン・・・
たぶん、ウイルスに感染した方からでしょうけど(^_^;;
ということで、最近もウイルス「NetSky」が大量に来ますねぇ。 Nortonがいちいち報告ダイアログを出すので、メール受信時は連打ですわ。
MVC
更新日時 2004/04/30
内容 リハビリもかねて、Javaの技術をあさってます。
さて、最近の設計の流行として「MVC」というものがあります。 「Model/View/Controller」の頭文字を取ったもので、それぞれ以下のような意味合いになります。
乱暴に言うと、システム(プログラム)を組むときの設計思想の1つです。

  • Model
    システムの中心となる「機能」の集まり。

  • View
    見た目、表示されるページ。

  • Controller
    ユーザの入力に対して応答する。システムの流れを定義。

ControllerからModelでの機能を呼び出して(利用して)、最終的にViewを出力といったとこでしょうかね、 雑多に言うと。
で、Javaでは「MVC モデル2」というので「Model → Bean」「View → JSP」「Controller → Servlet」 という対応付けがされています。
「Bean」というのは、機能をコンポーネント化したもので、実質は「クラスの集まり」。 C言語で言う「ライブラリ」みたいなもんです。業務ロジック、なんて言ったりしていますね。 入出力部が特定のルール(Getter/Setter)で決まっているだけで、普通のJavaプログラムです。
JSPはHTML内にJavaプログラムを記述できるもの、ServletはWeb環境でのJavaプログラム、といったところでしょうか。
で、大前提は「将来の拡張・メンテのために明確にMVCを分ける」なんですが、 ビューに操作部が入ったりして、完全にとはならない場合があるんですね。
それを手助けするフレームワークとして「Struts」というのがあったりします。
「フレームワーク」というのは、テンプレートみたいなもんですかね。 決まった枠組みでソースを記述していくことでシステムを構成します。
使いやすい考えかというとそうでもなく、「はじめはフレームワークに対する学習がいる」 というリスクが少なからずあります。ただ、長い目で見るとメンテは楽かな。
ちなみに、ソースを再度見直すことを「リファクタリング」といいますね。
ほか、いろいろ用語や技術が派生するのですが、ぶっちゃけ「複雑になりすぎなのではないか」というのが 私の率直な意見ですねぇ。<最近のJava技術
最近の流行(?)は技術者的というか敷居を高くする要因になるかもしれない、とちょっと危惧してしまいます。
多くのJava本なんか見ると思うこととして・・・なんか振り回されてはいないのかと。 シキタリが多いというのは一過性のものだと思ってますので、この先変化するのかもしれませんね。
まぁ、プログラムに王道というのはありませんので、組むことに関しては人それぞれでいいのかな、と 思ってます(もちろん、ソースの可読性は必要としても)。
「気軽に楽しくプログラム」なら、別に千差万別でいいと思いますけどね。
ちなみに、今作っているのはMVCに乗っ取ってます(^_^;;。時代に流されてる〜〜
出会い
更新日時 2004/04/25
内容 最近はいろいろな方と会う機会が多いのですが、いろんな年代の方からお話を聞くのは楽しいですね。 視点・考え方がいろいろあると思い知らされました。
現在の仕事が4月末で一段落で完了、ということで5月からの動きをこれから練って行かねばなりません。 とりあえずはホームページのリニューアルかな。もうちと、ビジネスチックな部分・技術部分を強化できればと思います。
後、去年から人材募集ということで公募していたのですが締め切らせていただきます。 応募された方、ありがとうございます。
今後、夢に向けて飛躍できればと思います。

当分はso-netのページは残しておきますが、 今後は「http://ft-lab.ne.jp」が私のページとなります。
ゴールデンウィーク明けには何かしらアクションを起こしたいですね。
糞直撃
更新日時 2004/04/18
内容 散歩がてら外に出かけていると、突然肩のほうに衝撃波が走りました。 「なんだ?」と思って肩を見ると、トリ(鳩っぽい)の糞がジャストヒットしてました。
ぬぉ〜っ、と近くのスーパーのトイレに駆け込み払い落として来ましたが、 こういうときは合わせ鏡にして背中も確認したいもんですなぁ。
それにしても、偶然にしてもすごい確率になるはず。

20m四方くらいの広場になってたところが現場なんですが、ここの上にトリが飛んでいたとします。 (ちなみに、上空には電線などありませんから飛びながら落としたんでしょう。「アトランチスの謎」のStage-1のごとく)
さて、私がその下のいずれかにいたとして、ターゲット(私の肩幅)としては多めに見積もっても50cm x 15cmくらいかな。
なので、まずトリが私の上空に来る確率(双方が静止しているとする)は「(50 x 15)/(200 x 200) = 0.0185」。
加えて、トリがこの領域を通りすぎる確率(中間をとって0.5としましょう)と 私が歩くことによって通り過ぎる確率(これも0.5としましょう)、 そして「トリの便意の確率」(気まぐれで10分に1回するとして、10 / (24 x 60) = 約0.007としましょう)などを考慮すると、 0.0185 x 0.5 x 0.5 x 0.007 = 0.000032375ってことで約1/30888の確率でヒットしたと。ちなみに、確率は苦手なのでテキトーです(^_^;;
ってわけで、交通事故よりも確率的には低いけど遭遇したということで、ここは一つプラス思考でウンが良かったとしましょう。
少なくとも言えることは「確実にねらっただろ」ってことかなぁ。 恐るべし、都会の野生。
フラノの歌
更新日時 2004/04/18
内容 以前BBSのほうに書いたことがあったのですが、テレビの「銭形金太郎」という 番組で流れていた「フラノの歌」というのが気に入ってしまい、 路上ライブ(東京の赤羽)聞きに行きました。
軍曹さん、というギター一本+澄んだ声で歌っておられる方です。 なんか、スナフキンな感じで(^_^;;
で、路上販売していたCDを買ってきました。
この方のホームページは以下になります。
http://homepage3.nifty.com/daijiyuuoukokugunnso/

少しお話しましたが気さくな方でしたよ。
それにしても便利な時代になりましたねぇ。ホームページやメールで交流して どこでいつライブしているのか、というのをご本人に確認できるんですから。
1時間ほど聴いておりましたが、夕方過ぎには人がいっぱい集まってました。 小さい子からお年寄りまで、というのはテレビの影響でしょうか(でも、ご本人はテレビを持ってないらしい(^_^;; さすが、銭金に出ただけはある・・・)。 でも、これからも応援していきたいですねぇ。
AABB Tree
更新日時 2004/04/17
内容 レイトレーシングの速度の最適化方法として、主なものにバウンディングボリュームと空間分割があるのですが、 SRenderではグリッドで空間を表現する空間分割を行ってます。 たしかに小さいシーン・少ないポリゴン数では速度は速いのですが、規模が大きくなると やはり速度が問題になってきます。
そこでバウンディングボリュームによる最適化も実験してみようかなぁと思ってます。 これは、シーン全体から始まり 直方体(バウンディングボックス)ごとに空間内を分割していき、 マクロからミクロに木構造を作成していきます。 AABB Tree(Axis Aligned Bounding Box)と言ったりします。
レイトレーシングの速度に影響する一番の要因は個々のポリゴンとの交点計算ですので、 これをいかに省くか(交差しないポリゴンを以下に除外するか)、ということでまだまだ勉強が必要なようです。
安定した速度を得るのは難しいですねぇ。
バウンディングボックスではなく、バウンディングスフィア(球)での階層化もありますね。

このページがわかりやすいかもしれません。
http://isg.cs.tcd.ie/spheretree/
ただ、球の内包は最適化が難しそうですのでとりあえずはAABBで考えてみます。
このあたりはいろいろ試してみて検証する必要がありますね。シーンによってハイブリッドで実装できると面白いかも。
レイトレの影
更新日時 2004/04/10
内容 こちらのレンダラ(SRenderと命名しています)での不正な影ですが、 Shadeのレイトレでも出ますね。
自由曲面またはポリゴンメッシュ(スムーズの角度は45度)に変換すると面分割が荒くなり、同等の画像を得ることができました。
Shadeでは、普通の「球」の状態ではこのようにはならないです。

これの解決策は面の分割を細かくすること、ということでプログラム的には回避できないもんなんですかねぇ。
この問題はFIXということで、その他の動作検証と速度アップをやっていくことにします。
COOL鯖
更新日時 2004/04/10
内容 ただいまCOOLの契約が切れたため、掲示板が使えなくなってます。 またメンテすることにします。が、これを気に新サーバに乗り換えるのもいいなぁ、 ちょっとお時間をください。そろそろ大規模に移行することにします。
さて、レンダラ開発を再び続行しているのですが(今はShadeのレンダラとして実装してテスト中) 大きな不都合発見です。

面の法線と平行光源の向きがほぼ90度となるときでしょうか、1つのポリゴン内ですべて影がついてしまってます。 「ほぼ90度で交わるときに、影を生成しない」とはできるのですが、今度は影を作らないといけない場合に影を落とせなくなったりします。
少し試行錯誤してみることにします。それにしても時代の流れから遅れてますね、私(苦笑)。GIもやりたいのですが、ステップ踏んでいこうかと思ってます。
陰線消去
更新日時 2004/04/03
内容 時の経つのは早いものですでに4月・・・。ひさびさに技術的な話題でも。
Shade7にて、図形ウィンドウ上にてついに陰線消去が可能になりました。 でも、実はこのあたりはすぐに実装できてしまうものですので、アルゴリズムを書いてみます。

なぜ、陰線消去ができるのかというと、実はZバッファレンダリングしているからです。
OpenGLなどを使った描画では、Zバッファが生成されます。ですので、半透明でないポリゴンを描画した場合は 無条件で前後関係がピクセルごとに表現されることになります。
Zバッファへのポリゴン描画のみを行った後に(個々のポリゴンは背景色で塗りつぶす)、 稜線(ワイヤーフレーム)をZ値を考慮して描画することにより、 視点からみてポリゴンにて隠れる部分は描画されないことになります。
ですが、ことは単純にはいかなくて 小数点の誤差やほんとに細かい少数の比較にて、エッジ部が汚くなります。
これの回避策としては大きく分けて2点が上げられます。
  • 視点と前面クリッピング面の距離を大きく取る
    奥行きの前後関係の誤差を防ぐための手段です。逆に言うと、視点からみて一番遠くのZ値と 前面のクリッピング面までの距離を狭めて、よりZ値の精度を高めます。
    Shade7で試せば分かりますが、カメラの設定にてzoom値を小さくすることで 奥行きが広くなり、図形ウィンドウでの陰線消去時の線が破綻するのが確認できます。

  • 稜線描画時に少し視点に近づくように描画
    ポリゴンをZバッファに描画した後に、稜線を描画時にはちょっと視点に近づけるようにして線を引きます。
    これにより、浮いた感じにはなるのですがポリゴンの破綻は緩和できます。
    Zバッファ上では以下のような感じになってます。

    実際に、陰線消去を行ったワイヤーフレームレンダラを作って確認してみました。
    上の画像がレンダリング結果、下の画像がZ値を見たものになります。
    ラインだけ浮き出ているのが確認できるかと思います。
このようなやり方だと、面の表裏のないShadeでも陰線消去は可能になりますね。
で、図形ウィンドウでは裏に位置する隠れた選択ポイントは選択できない、となっているのですが これも簡単な話で、視点から見たときの選択ポイントのZ値を算出してみてZバッファでの指定位置でのZ値よりも奥にある場合は 選択ポイントはないものとする、としているのだと思われます。
このあたりは3DCGのモデラーを作るのに必須の考え方ですので、覚えておいて損はないかと。