zillionプロジェクト開発ブログ

んなわけでしばらく作業はできませんね。ほかのメンバーに委託します。

その後も、友人のPC製作を手伝ったり、クラスメイトたちとスキー行ったり、そして情報オリンピックもあり、忙しいです。

14日まではテストなので、更新は減るかもしれません。 

[0回]

Luaですが、埋め込み以上に大変なのが、当然のごとくLua用のライブラリの制作です。
まして、2D,3D,通信系なども将来的にはサポートしていかなくてはなりません、並行作業でちょっとづつ作っていくという形になるでしょうか 、いずれにせよ、luabindのおかげで、製作時間が短くて済みます。(内部でテンプレートが多数使われているようなので、かなりコンパイルが長くなるのですが・・・)

とりあえず、実装できたのは、三項演算子っぽい関数、メッセージボックスを表示する関数ぐらいでしょうか。

Luaの実装部のほうでは、デバッグ情報などの出力もサポートしていて、デバッグ機能なども充実していく予定です。
CString形式で、スタックの中身が見えるようにしてみたので、これをリストボックスなどのUIにすることで、デバッグ時にスタックの中身が見れるというそれなりに画期的になりますし、関数からの返値なども見えるようになります。

んーなんか開発がプログラマー思考な気がしてならない・・・

[1回]

球根？
いえいえ、ちがいますよ。
Qコンです。
つまり、「量子コンピューター」のことです。

RSA暗号化など、現在のノイマン型コンピューターの基本的な暗号化アルゴリズムは数学的な因数分解処理によってできている。
ところが、量子コンピューターは、その圧倒的な計算能力から、200億年ノイマン型のコンピューターがかかる計算をわずか数分で解いてしまう能力があると言われる。

量子ビット(Qビット)による計算は、ノイマン型で使われるのと異なり2のn乗となり計算速度は増大することは知られていて、10Qビットで1024ビット分の計算ができることになる。
100Qビットでは12676506002282294014967032045376ビットとなる。
1000Qビットでは1.07150861 × 10³⁰¹　ビットだ。
んー想像がつかない。。
 
と、とにかく、、半端ない・・・

Qコンは計算時に量子テレポーテーションという現象を使用して計算を行うが、これを最近日本の大学が成功させた。
素晴らしい話だ。

ところが、Qコンにおいて懸念される問題がある。
ノイマン型コンピューターのセキュリティをありえない速さで解いてしまうこのQコン。
兵器として利用されてしまうのではないかと言われている。少なくとも、まず最初にQコンが開発されて最初に買うのは、ペンタゴンであろう。
他のQコン所持組織からのハッキングを簡単に受けてしまう可能性があるのだ。というか、Qコンの前には今までのセキュリティなどすべてないものと同じ。
銀行のATMのデータだって簡単に操作されてしまうでしょう。

それだけの計算能力だ。
情報戦・・CIAとかロシアだって、アメリカに乗じて負けじと金を出すだろう。そうなれば、条約ができて、制限され、将来、小さく安くなって企業がサーバーとして使えたりするということだってできなくなるかもしれない。


第二次世界大戦や第一次世界大戦で、技術は大きく向上した。戦争には必ず利益がある。だがそれと同じだけ損失もしている。
物理の世界。かならず+-0になる。
これは全てで一緒である。

でも、Qコンはそんな発展の仕方をしてほしくない。
人類が、各国のいろんな技術を使って作った、日本の技術の塊でもなければ、アメリカの技術の塊でもない、地球人の技術の塊、そして誇りとなれることを切に願う

[1回]

タイムラインコントロールにくっつけようとしている機能です。

 放物線運動や、複雑な物であれば歩行アニメーションなども、プリセットとして登録しておけば、モーションタイムラインに割り当てるようなことができるようにするものです。

また、プリセットコードにluaを含めることで、割り当てたいタイム間が異なった場合でもそれに応じた補完処理をすることが可能となり、若干先進的なプリセット機能となります。

DirectX担当が、3Dのほうの整備が終了するまでは、僕はこうして、いろんなコントロールの機能充実を図っていこうかと思っています。

[3回]

Xファイルってご存知でしょうか？もちろん有識者には何をバカなことを言ってるんだ的なほど簡単な質問ですが、DirectXでサポートされていたファイルの事です。

「た」と言ったのは、人によっての解釈によってXファイルへの見かたは変わるのですが、僕的には、「た」であると言っても過言ではないと思うのです。

というのも、すでに最新のDirectXでは、Xファイルのサポートはありませんし、拡張性を重んじるがあまり、描画速度の遅さが目立ちます。

僕らは、3D描画の第一歩としてこれを独自フォーマットに変換するという方法を考えてきました。
すでにサポートされていないと言っても過言ではないファイルを変換するのにはわけがあります。
3Dの世界において標準化されたファイル形式と言うのは極端に低いのです。

例えば、モデリングソフトによっては、階層情報を持ったものや、物理演算(パーティクルフィジックス)、アニメーションキーフレーム、IK(インバースキネマティクス)・・・ソフトによってあったりなかったりまた特徴的であったりする機能が多いのです。

そう、3Dの世界はまだまだ開拓途中で、固定されたものではないということでしょうか。

その結果、機能の相違=データの相違となり互換性の維持が難しかったのです。
その中、Xファイルは、もっとも標準的なファイルとして、DIrectXを経験する人が必ず経験すると言っていいような基本的なファイルでした。

しかし、機能が追加されていくと、同じような機能を持ったソフトが現れます。
アニメーションなどはほとんどのモデリングソフトで段々と実装されるようになってきました。
そうするとそのソフト同士で勝手にフォーマットが変換できるように作られてきます。

結果的に、今までの標準的なファイルは、使う事のない。だけども標準として依然として残されているファイルという事になるのです。

ところが、確かにXファイルは僕らにとって意味をなさない物ではありません。他によく使われているファイルフォーマットを分析、取り込み、表示、エクスポートするということよりも、まだ名残として残されているようなXファイルを取り込み、独自フォーマットに変換、表示、エクスポートなどさせたほうが製作のプロセスとして効率的です。

製作するソフトが、モデリングソフトではなく、そのモデリングされたデータを用いるソフトであるからなおさらです。

互換性と言うのは、僕らをかなり悩ませる問題の大きな要因ですね。

[1回]