W21CA

インターネットとの付き合い方

from ITmedia
>W21CA - フルブラウザを使ったサイト閲覧にパケット定額制が適用されないのには注意が必要。
ネットワークを使う人と、使わない人との間の溝が埋まらない限り、
ネットをより実用的に使うための方法は発展しない。するはずがない。
もっと安く、開かれてくれと願ってるし、一番に開いたキャリアを俺は必ずサポートするだろう。
-
3G端末の台頭は、この３年間待っていた性能ではあったけど、コストの問題から、答えにはならなかった。
どんなに用途に優先順位を定めていっても、パケットのノイズはゼロには出来なかった。
俺はネットに対する必要の、見極めを誤って、９月からこっち、落ち着くまでに十万以上の金額を投じてしまった。
もちろん、最終的に契約したAir-H"/32kbpsは満足のいく速度ではない。
もっと速い方が断片的なモジュール群を十分に素早く整理するのに役立つ。
10mbを越えるアーカイブは事実上ＤＬ不可能な速度でもある。
でも、プログラムの初心者にとってまず必要な知識は、主に言語についてで、
それは良書を買ったほうが遥かに話が安くて早い。
生活に実用する情報については、このスピードで全く問題ない。
-
欲するよりも探すことが大事。今までずっと自分に欠けていた意識。
娯楽を導入として、そこから離れて、広大な知識のまとまりの中に、それに代わるものを見つける。
ただし本当に代わりになるものはない。
DVDと音楽は、一番きれいな娯楽になる。
俺は来年から、漫画や一時しのぎのゲームソフトを買わなくなる代わりに、もっと頻繁にハードや本や映画を買うだろう。
それは必要な変化だ。

041228

mks(mqo)2x.py - 構造設計

Programming - 3Dモデル

当然と言うか、一度オブジェクトにmqoから各チャンクデータを格納して、
必要なチャンク情報をそのつど、そっから呼ぶコンバータクラスを作って変換する形。
mqoのみについて取得できる情報を考えると、最も難しいところでも、フレームの相互階層だけで、あとは素直に、
メッシュオブジェクト毎に順に中身を書いていって、共有マテリアルリストを挿入すればいい。
内部使用するmqoデータオブジェクトクラスを細かく設計し、書式順の挿入操作に対応する。
-
ただひとつ素直にいかなさそうなのがMeshNormalsだ。これは・・・生成する必要があって、
書式としては、生成した法線ベクトルのリストをフェース毎にインデクス設定してやるという書き方になる。
そうだとすると、フェース毎にシェーディングを設定できると思えるかもしれないけど、
DX7を使っていた時の記憶では、これはシェーディングではなくて、ライティングに使用されるものだ。
どっちにしろ、単一面の場合、各頂点毎の法線は全て面の法線と同じ値であり、
連続する曲面の場合、ちょっと工夫して、隣接面の法線を合算するとかして、ベクトルを出してやらなくてはいけない。
-
.x形式のメッシュの書式のうち、頂点リスト＞インデクスリストの書き順は、どんな場合でも固定。
次にマテリアルナンバーリスト、そしてマテリアルデータそのもののリスト。これも別に難しくない。
-
だが、マテリアルナンバーリストを例にとって考えると、mqoはこうしたフェースの総数に対応しているデータを
一緒くたにフェースチャンクに格納するので、オブジェクトクラスは、このへんを抜き出す手段を持っていないといけない。
つまり、mqoオブジェクトクラスは、各チャンクを生のまま保持する方がいいだろうか？
それとも、リストとして分割して持つほうがいいだろうか？
-
前者の場合、利用者(.xコンバータクラス)はそのチャンク、主にフェースチャンク、の解析が必要になる。
利用者側で、フェースチャンクをバラにする手続きを挟んでから、それらを実際に書くので、
どこかに一時的なローカル/メンバーリストが生まれてくるので、読みにくくなるかも。
-
後者の方法は、setup(filename)メソッドで、特にフェースチャンクを分解する。
一度分解してしまうと、mqoをmqoに対して再書きするような要求が出た場合に、バラしたものをまた結合することになる。
フェースチャンクと、分解したリストとを同時に持つのは、読むときに太っちょでわけわからなくなりそうなので、
あまりいい設計ではないと思う。
-
どっちもどっちに見える。どこまでコンテナクラスが操作を提供するのかということだ。
書き易いと思うのはどっちだろうか？そして、単にコンテナとして見た時に理解が容易なのは？
-
多分、そっけないコンテナクラスの方がいいんだ。
-
そしてちょっと難しいMeshNormals。
最後にMeshTextureCoordsは要領はマテリアルナンバーリストと一緒。

041224

固定機能/頂点ブレンディング/D3DXを使用したスキンメッシュの実現

Programming - 3Dモデル

DirectX使用を前提とした戦略の選択肢として、
.mksから.xへの変換スクリプトをPythonで書くか、.mqo+.mksをハードコードから読むか。
その違いを、言う事が出来るだろうか。
-
前者の場合、両方のファイルフォーマットのどちらか片方、
または、あの便利なD3DXLoad...FromXof()APIが変更された場合、手直しが必要になるだろう。
ただ、ファイルフォーマットは、意外と長い年月の間は変更されず、機能する。
-
後者の場合、コンテナクラスに使うD3D型のどれか一つでも変更された場合
(例えば、それがD3DVECTOR3がD3DVECTOR_3になる、等の些細な変更であっても)、コードの手直しが必要になる。
ハードコードとして自分の書いたクラスが一個でも通らなくなるのは、気分的に、絶対イヤ。
-
DirectXはバージョン更新の度に、利用者にオープン/クローズドのどちらに立つかの選択を強いてきた。
変更に対し閉じ、拡張に対し開く、というOCPの原則は、二つの条件を両立する設計のことであって
どちらか片方をユーザーに選ばせることではない。
おそらく彼らは意図してやっているのだろう。
-
DirectXのどこが変更され、廃止され、淘汰されるかを、予測することは、不可能ではない。
それにしたって、なんかもう使うなと言われているような感じではある。
２年もあとには、wg3d.libなどと名称変更されたライブラリを、彼らは平気で標準にするだろう。
-
データコンバートによって対応できるうちはそうした方がいい。
文字通りの対処療法ではあるものの、問題が複雑にならないからだ。
-
サンプルコードが機能し続けるためには、前者に逃げておくのが無難。
ファイル操作は面白くないが、結局は必要だ。問題はその方法。
-
Mikoto式のボーン設定を施された.mqoから、格納頂点、センター、ラディウスの情報を取得し、
.xのFrameチャンクに書く必要がある。
tiny.xは、唯一のスキンメッシュ対応.xで、出力書式を得るためにはこれを読む。
特に難しいことはしていない、が、SkinWeights,XSkinMeshHeader,VertexDuplicationIndices
これら三つのローカルチャンクの示しているものについては調査が必要。
-
SkinWeightsチャンクの書式は大体理解できる。
ボーン毎に結び付けられる格納頂点の総数と、非連続な頂点インデクスの配列と、
そして、0~1の間で示される、格納頂点の影響ウェイトデータ配列で、
つまりこれが0なら、その頂点はフレームがアニメーションしても全く動かない。
SkinWeightsとBoneとなるFrameとが対応していて、ローカル原点はFrameチャンクから得られるが、
SkinWeightsの側にオフセットを含めることも出来ると。
-
Mikoto式のアンカーボックスからウェイトを得る為には、
ボックス同士が重ならない部分に含まれる頂点のウェイトは明らかに1となり、
重なる部分については、例えば、形状差分を作って、センターからの距離とか、そんな感じで出るんだろうと思われる。
-
剛体アニメーションのみのコンバートなら算段が付く。あとはやる気だが・・・。
-
Pythonのコンバートモジュールの組み方として、最適と呼べる例文を読みたい所。

041223

3Dグラフィックス関連の良書

買いもの

Game Programming GemsReal-Time Rendering
立て続けに本を買ったために、必要な知識は全てここから得られるくらいまで揃った。
だからといって何もしなければ当然結果はゼロなわけだが、少なくとも大分視野が広がってきた。
ゼロと言うか金額と重量分のマイナスが出たけど、話が非常に簡単になったと感じる。
断片的なWeb上のテキストを探し集めるのには、時間と金額以外に、一定の編纂の仕事が必要になる。
-
ジオメトリ周りだけが自分にとっての課題。あとはどうでもいい。
無思慮な言い方だろうか。
なにを追いかけようとしているのだろうか？その答えは明らかに過去にある。
-
3Dグラフィックス技術がゲームに利用される中で発展し、
驚くほどの成長を遂げていくものの、いつまでも、それらの成果は、生活にとって直接関係がない。
それ以前から存在したゲームの分野は僅か数年で塗り替えられた。
-
描画能力を利用するための知識は拡大し、良書が生み出され、増刷されてきた。
amazon:Real-Time Rendering]と[amazon:Game Programming Gemsとの間に引くことの出来る線は、圧縮を主題の一部として持つか否かだ。
制約は少ないほどいいと思うのは自然なことだし、誰だってそうだ。
-
遥か先の技術に憧れるのは自然なことだ。
たとえば、それがどんなに生活の必要からかけ離れていても、感情の面では、一度感じたそうした記憶は残っていて、
いつまでも消えることがない。
-
扱い方だけでは、話の半分でしかない。
何を描くか？に注視することは、常に大切なことだ。
3Dグラフィックスは、幻覚を生成するための道具ではない。
イメージを視覚化するための、高性能な道具を手に入れることだけが、正しい目的になる。
より多く、自由に、忠実に描くことが出来たら、それが勝利となる。
-
道具は人の頭の働きを確実にし、結果として速くする。
実用性の高い道具は、多くの人の生活の中でも、生き残っていくことが出来る。
家庭環境に対して直接機能する道具(例えば電灯や暖房など)に対する需要が、なくなることはない。
-
いずれにせよ非常に長い時間、知識を積まない限り目に見えるところはない。
041221