ドロちゃん賞 | 立て看板 | ドロップ |
---|---|---|
ビジネス賞 | 占い | 修正液 |
サイド(再度)ビジネス賞 | 電光掲示板 | 封筒 |
授業中に遊ぶのはヤメま賞 | 平安京エイリアン | スコップ |
ポリゴン3D継承 | フライトシミュレータ | 積木 |
叡知の結晶 | 理論科学シミュレーション | パズル |
ス^Hトリップ賞 | 森川くんの物理デモ | まねき猫 |
の大ベル賞 | Nishi君の落ち物 | クリスマスのベル |
オールナイト賞 | Marionette. | 関節炎の薬 |
ハンズ大賞 | 音声 | 音に反応するおもちゃ |
いっとー賞 | VR | あやとりの本 |
駒場祭を振り返って思うことは尽きません。正直言って、駒場祭がここまでうまく行くとは考えていませんでした。なにしろ祭り半月前の頃では、まだ占いのテキスト打ちすら行われていなかったのですから。それに他の出展予定の企画もなんだかよくわからない状態でした。さらに、持ち込む機材や持ち込む車の手配すらはっきりしていなかったのです。
これでよくすべて完璧にできたのか不思議なくらいです。きっと、みなさんの協力のおかげですね。みんなよく働いてくれましたよ。寒い中、夜間警備委員のステージ見張りをしてくれた星野君は特にお疲れさま。それから大岩君、徹夜して占い完成させて、さらに突っ込んでくるお客にちゃんと応戦できたのは凄いよ。他のみんなも、本当に本当にありがとう。
1年間TSGの部長をしていて良かったんだと思いました。いままで部長の仕事は書類書きとゴミ掃除くらいで惨めな思いをしていましたが、駒場祭ではみんな僕によく付いてきてくれました。このとき初めて部長の部長たる意義を感じました。
駒場祭準備で一番感謝したいのは安田君です。今年のTSGの駒場生には車を運転できる人が少なかったのです。免許を持っている人はいるのですが、ペーパーだとか車は実家にあるとかで実際に動ける人は安田君と岡村君のみでした。
準備の打合せのときに、当然安田君に車の運転をお願いしましたが、彼は編集長なので、パンフと名簿の編集印刷の重労働があるのです。加えて彼自信による音声認識の企画があったのです。なので当然彼は運転は避けたがっていました。
しかし岡村君だけでは車は足りません。先輩方にもお願いしましたがどうもうまくいきませんでした。車が無ければTSGの全企画が滅びます。駒場祭で失敗を犯したら、今後のTSGの将来に大きな暗い影をおとすことになります。
駒場祭には少なくとも4つの正式企画が必要です。なぜなら1号館という一等地の1部屋を占領するためです。安田君の音声認識の企画は企画数を4つにするために彼に考案してもらった企画なのです。
駒場祭数日前になると、どこからともなく新たな企画が次々あらわれました。5企画くらい出ましたね。そこで僕は安田君に音声認識の企画を切って運転をするよう頼みました。それでも彼には印刷の仕事があるので非常にたいへんなのですが、こうするしかなかったのですよ。
でも彼は忙しい仕事を本当に完遂してくれました。どうもありがとう。音声認識はまた今度にでもね。
今年の駒場祭で僕が感じたことをいくつか話します。来年の駒場祭のさらなる成功のための参考にしてください。
まず企画責任者と副責任者をどう振りわけるかということ。責任者は複数兼任できませんが副責任者は兼ねられます。なので今年は僕が1企画の責任者をして3つの副責任者をしました。こうすると4企画すべてを僕の学生証で動かすことができるからです。でもこれだと学生証の交換がうまくできませんでした。来年は部長はすべての企画の副責任者だけをしましょう。いざというときに便利です。
次に占いについて。1号館は占い館でしたね。あっちこっちいろんな占いをしていました。雰囲気的にかなわない占いもありました。それにお客さんたちには占いはかなり平凡に見えるようです。「理論科学グループによる本格派コンピュータ占い!!!」と言っても振り向いてくれるひとはわずかでした。やはり東大生の展示にはさらに凄いものが求められているのでしょう。
来年も占いをするのでしょうか? 技術的にも雰囲気的にもお客達に「さすが理論科学グループ」と思わせる占いにしなくてはなりませんね。それとも占いを辞めて、別な展示で資金を稼ぎましょうか?僕には良いアイデアがないので、何も言えませんが、よく考えていきましょう。
最後に展示の解説について。お客さんは大切にしましょう。自分の作ったプログラムはどんどん宣伝しましょう。お客の方から声をかけてくれることはありません。こちらから声をかけて解説しましょう。解説することがなくても話をするだけでもお客への誠実さを表すことになります。
今年の展示では、TSGerが展示品で遊んでいたり、だべっていたりで素通りしてしまうお客多かったです。
一般の人には怪しいとしか思えないコンピュータサークルの潔癖さを主張する絶好の機会なのです。みんなもっとお客に積極的にオープンになりましょう。
以上3点、今年の反省と来年への希望とします。
みなさん、本当にお疲れ様でした。
編集長やコンパ委員みたいに華のある役職と違って、部長の仕事は表からは見えない。学友会総会に出たとき、はじめて部長が何をしていたのか知った。学友会に加盟していることで得られる権利はいろいろあり、これら無くしてTSGの存続は不可能になる。こうした権利を維持するためには、数多くの会議・書類などの事務処理が必要となる。学館の壁に「−公示−」と書かれた貼り紙があるが、しばしば重大な事務連絡が書かれている。これらを漏らさず把握し的確に対処していたのが、部長だった。
駒祭の最大の功労者がなおであることも、疑う余地のない事実だ。自分の企画だけでも大変なはずなのに、駒祭直前の会議、書類、TSG内の他の企画への気配りはもちろん、わがままな編集長に運転を頼むストレスもあった。彼が指揮をとらなければ、TSGの駒祭は立往生していた。なおが信頼できる部長としてみんなに必要とされてきたことに、疑問を挟む人はいないだろう。
細かいことはよく知らないけど、会計のNishiやその他のみんなも、自分の勤めを黙々と果していたんだと思う。
なおに、「彼の気持ちを考えることを怠っていました。」と言われた。僕も、なおの気持ちを考えることを怠っていたと思う。自分の仕事ばかり気にして、周りへの配慮が足りなかったような気がする。もっと周囲の言葉に耳を傾け、目を開き、理解しようと努めるべきだったのではないか。
理解するとはどういうことなのだろう。僕にはよくわからないけど、うわべの言葉でわかったフリをすることでないのは確かだと思う。人はそれぞれ自分なりの価値観をもっているから、自分の憶測の通りに人が考え、行動するわけではない。それを忘れて思い込みだけで突っ走ると、大きな間違いを犯すかもしれない。一人だけの世界で考えていると、本当に狭い範囲しか見えなくなってしまう。理解することは簡単ではないが、そのための努力は続けなければいけないと思う。
まあなんとか終わったと言うのが正直な感想でしょうか。
結果的に言えば、「ペース配分は失敗したが準備はまあまあだった」という感じです。僕がプログラムを書き始めたのは6月下旬で、それも準汎用的な簡易ウィンドー描画システムからでした。実際の占いルーチンを書き始めたのは秋休みに入ってからで、その期におよんで参考書の情報の欠落に気がついたのでした。
また、「自分はプログラムできるぞー」という1年生が占い担当の僕とポリゴン担当のわたるしかいなかったこと、占いのルーチンが直列的で分担作業に向かなかったことがわざわいし、結局全部プログラムを1人でつくるはめになりました。
実質的に作業が進んだのは2学期に入ってからで、それも1年生の集まりが悪くテキストを分担したのが2週間前、揃ったのは2日前と言うありさまでした。げるには全データの整理・書式変更と足りない原稿の打ち込みを準備前日になってから、前日泊まっていた何人かにデータのタグ付けを準備日の夜にやってもらいました。
一方のプログラムのほうは、占いの結果判定が準備日の夕方、7月に完成した描画システム上での入力ルーチンが5日前、NAOさんに依頼した太陽の軌道計算は1週間前に、プリンタルーチンは準備日の夜に完成しました。テキストの表示ルーチンは7月にテスト用に作ったルーチンをそのまま使えたので、夜中までには一通りの動く形は完成しました。最終的にテキストがタグ付けされ、テキスト構成ルーチンが完成したのは当日の朝3時でした。部品の完成度をそれぞれ完全にまでしておいたので、一体化がスムーズに行ったのは我ながら感激物でした。
その後もプログラムの機能追加とバグ潰しは継続され、1日目の夕方に相性占いが完成し、3日目の朝には外字の出力ルーチンができて、字がJISに無いために正常に出せなかった漢字も無事に出力されました。
というわけでプログラムは無事に1日目の昼から稼動を開始したのですが、今回はTSGのある106へと繋がる通路の両端に占い団体があり、客が減ったのが痛恨です。また、なんだかんだ1年生が減り、結局受け付けと呼び込みが特定の人間に偏ってしまったのは事前の打ち合わせ不足を感じました。
出力量はB5で4枚にのぼり、おおむね評判は良好でした。ただ、どうしても四柱推命では矛盾する星がでてしまうケースが存在するので、結構多くの客から質問があり、そのたびに徹夜疲れの僕は眠い目を擦りつつ客に結果を読み解くことになったのは...。
結局目標の6桁には到達しなかったものの、前年の売り上げを上回ることができました。
結局苦情らしき苦情はCase 3の1件のみでした。
どうもありがとうございました。
せっかく松永さんに干支の絵をかいてもらったのに、とても MAG to ESC/P 変換まで手がまわらず、とうとう最終日まで絵はでずじまいでした。自分としてもくやしいです。松永さんごめんなさい。
駒祭総決起コンパでの私のホラはこんな感じでした。
「占いのプログラムは前日までに完成させます」
できた時間を第1日目の3時とみるか、準備日の27時とみるかはこれを読む皆様の御判断にお任せします。
こんなところでしょう。一人で総計2500行のソースを書くのはしんどいっす。
それでは。
ちょっと科学に興味のありそうなお客を捕まえては、長々と解説をしました。多分その解説を理解した人は少ないでしょう。でもそれでいいのです。僕の展示物は見て、それが何なのかを理解するのは容易でしょう。でもこれの制作は非常に大変なのです。その大変さのアピールは僕が機関銃のように話す解説で伝わったことでしょう。
他大のコンピュータサークルからのお客にはいっぱい解説してあげました。冷や汗を流していましたね。偉そうだけど素人そうなおじさんには、次世代のコンピュータ社会のあり方について熱論しました。教授のようなお客もいらしたので、慎重に解説しました。また来るとおっしゃられましたが会えませんでした。工学部の専門の学生に突っ込まれましたが、方法が違うので出来ないと言って逃げ、別の分野で攻め返してなんとか巻返しました。大学の授業でプログラムを始めたばかりという女の子たちには、コンピュータの楽しさを長いこと力説しました。
東大やお茶大の女の子の友達達をたくさん呼んで、長々と解説と談笑をして遊びましたがその間、たくさんのお客が通り過ぎていったような。
たくさんたくさん解説したので、のどがおかしくなってしまいましたが、TSGを理論科学グループにしたてあげれるという暴挙は成し遂げられました。来年こそはスパコンを使って、それにCGを綺麗にして出展してみせましょう。
2日目に、もっとすごい得点が出ていたのですが、なぜかハイスコア情報が残ってなく、(サーバーにバグがあるにちがいない)このような結果となりました。
僕は 4800 点位だったと思ったのですが、デバッグのため消してしまったので残っていません。
しかも未だに完成してないとゆー(T_T)
でわでわ。
ども,Makkenです。
前回の駒祭パンフ号の記事はお楽しみいただけたでしょうか?(笑)
何やら一部の方々には非常に評判が良かったようで,
「電車の中で読んだら,危うく爆笑しそうになった」
との報告も2件ほどいただいております。
今回も「あのノリ」で行かせていただこうかと思ったのですが,それでは
というイメージで定着してしまう恐れがあるので,少しはマトモに解説しようと思います。
さて。
Marionetteというのは,NERVじゃなくて僕が開発した関節エディタの零號機・・・プロトタイプです。
まだまだ発展途上で,本当に最低限の機能しかありません。
特にユーザインタフェースは難解を極めるので,選ばれたごく少数の人々しか使いこなすことができません。
僕でさえ操作中にシンクロ率が低下してくると,どのキーを押すとどこの関節が動くのか分からなくなります。
安定性にも不安があり,駒祭中には何とか動作していましたが,実験中には頻繁に暴走事故を起こしてくれたものです。そのときパイロットがエントリープラグに閉じ込められて・・・ってそれはいいって。
展示したのはMarionette本体ではなくて,
「Marionetteで作成したモーションを使い,
テクスチャマッピングされたポリゴンの人体を走らせるデモ」
です。
展示したのはあくまでデモであり,Marionette本体ではありません。
「なぜゲームにしなかったの!?」
という厳しいご指摘には ,
「いいじゃないですか。ウケたんだから」
と答えておきましょう。
この展示は急造のわりに,成功をおさめたと思います。
それにはやはり何といっても,新兵器デジタルカメラの功績が大きいでしょう。デジタルカメラは人類の至宝,まさに科学の勝利ですね。デジタルカメラを快く使わせてくださった油さん(須磨さん)に感謝いたします。
僕はデジタルカメラがあんなに遊べるモノだとは予想していませんでした。お金に余裕があれば早速入手するのですが,実はAT互換機購入計画もあるので,残念ながらデジタルカメラはだいぶん先になりそうです。
MIDI音源にひき続き230MBのMOドライブおよび新しいAT互換機の購入費・・・いったいいくらオモチャに金をつぎ込めば気が済むんでしょうね。まったく,国がひとつ傾きますよ。
それからもちろん,にこやかな笑顔を撮影させてくださった皆様にも感謝いたします。徹夜走り続けて,お疲れさまでした。
「みんな,何て楽しそうに走るんだろう!」
と評判でしたよ。
展示中にふと出てきた話なのですが,
「占いの呼び込みを来年からコレでやったら楽ではあるまいか?」
とのことです。そのときにはまた笑顔を提供してくださいね。
え? 自分の顔は使わないのかって? そうですね・・・展示されるのって
「かなり恥ずかしい」
ですし(爆)
技術的には,まだ大したことはやっていません。
テクスチャマップドポリゴンの描画ルーチンはそこそこ使い勝手の良いものが書けたと自分では思っています。しかし,ポリゴンプロセッサを搭載した使徒が100万台を突破しているご時世ですから,もはや兵器としては役に立ちません。あくまでもテクスチャマッピングは物体を表示するための
「手段」
に過ぎません。それよりも,関節の動きに注目してほしいと思います。モーションのキーフレームの設定には結構気を使っているんですよ。特にムーンウォークなどは短時間で作ったわりにはイイ感じかと。
でも,
「関節の動き」
もバーチャファイターや鉄拳のおかげで,今やごく当たり前のものになってきました。
Marionetteが最終的に目指すのは,もっと先にあるものです。
まだ具体的なイメージは出来ていませんが,
「柔軟なフォルム」
と,
「円滑なモーション」
そして,
「絶妙のタイミング」
を実現できたらな,と思っています。
そのために研究と称して毎週欠かさず・・・(以下略)
EVANGELIONのEVANGELIST,Makkenでした。
このフライトシミュレータは3Dポリゴンの習作として作りました。当初は『紅の豚』のようなプロペラ機のドッグファイトをやる計画だったのですが、ご多分に漏れずこの計画も妥協を繰り返し単なるフライトシミュレータにまで落ちてしまったのでした。(^^; 飛行機の運動は大変おおざっぱですが航空力学的な計算をしていますので、それらしい操縦感覚が味わえます。キーボードの入力処理が腐っているからダメだという話もありますが。(^^;;
《内部処理について》
大部分をC言語で書き、グラフィック関連の部分をアセンブラで作りました。計算には固定小数点を使っているのでコプロセッサなしでもそこそこ速く動作するはずだったのですが、 『山』のような大きなポリゴンを扱う場合は陰面処理でlongだとオーバーフローを起こすことが判明し、long long(gcc固有の64ビット整数)でもだめで、しぶしぶfloatを使ってしまいました。陰面処理の関数は行列掛け算の関数の次くらいに頻繁に実行されることがプロファイラによってわかっていますので、こいつは処理速度の低下になかなか貢献してくれたようです。物体の頂点の数が1200個を越えるとPentium 90MHzのマシンでさえ10fpsを割り込んでしまいました。 グラフィック画面は98MATEの256色パックトピクセル方式を使いました。本フライトシミュレータはプロテクトモードで動作しますから、VRAMにリニアアクセス可能なこの画面モードがとても便利なのです。16色プレーン方式について私がよく知らないせいもあります。それにしても、テクスチャーマッピングはおろかシェーディングすらしないあのベタ塗りポリゴンが、実は256色で描かれていたとは何人が気づいてくれたでしょうか。WinGのHalftone Paletteをパクっており(どのように使ってもよいとソースに書いてあったものですから(笑))フルカラーをディザ表示しているのです。フラットシェーディングをしたかったので移植したのですが無駄になってしまいました。ディザの副作用で画面につぶつぶが現れてしまい、かえって無様になったようです。
《今後の課題》
課題は直すのが嫌になるほど山積してますね。Makkenさんに高速なテクスチャーの貼り方を教わったので、次に皆さんにお見せする作品はもう少しましな見栄になるようがんばります。次に何か展示を展示する機会はオリエンテーションのときですから、見た目が重要そうです。
《謝辞》
いろいろな方からプログラミング上のアドバイスを頂きました。ありがとうございました。必ずしもそれを活かせなかったのは私のせいです。256色モード用の文字表示関数を作ってくれたり、仕様の厳しい地表データの作成やモデリングをしてくれた高野君に特に感謝します。
1haは-lh5-のフォーマットなんだけど、前の部分からのコピーを全く行いません。そんなわけでハフマン符号にしても元と同じになるので、LZHのファイルを見たら-lh0-(無圧縮)でないのに内容が見えるようになっています。むかし油くんと話していたときは、この-lh5-なのに中身が見えるところが売り(笑)だったのですが、Nishi君はそれを超々爆速アーカイバということにして作ったのですね。
確かに1haは圧縮(?)にかかる時間は短いんだけど、作った書庫をディスクに書くのに時間がかかってしまいます。そこで、あまり時間をかけずに適当に圧縮して、ディスクに書く時間を含めてなんとか1haに勝てないかなあとプログラムを作ってみました。
ぼくがむかーし作ったSFA 0.20は、圧縮率を落として高速化しようというものでした。SFAで30%くらいに縮まるファイルの場合、LHAよりも10倍速かったのですが、ディスクの書き込みが超いいかげんに作ってあったので、実は速くありません。SFA 0.40ではディスクの書き込みのあたりも一応考えて作ってあるので、そのLZSSの圧縮の部分を0.20の方法に変えたものを作りました。0.20ではどうやっているかというと、同じハッシュ値の文字列をリストにしておく所を、リストにしないで昔の(=遠い)文字列はすっぱり忘れるという方法です。キャッシュの用語だとダイレクトマップということになります。その他に、前の部分からのコピーをする場合、本当は1文字ずつずらした文字列をハッシュ表に登録しないといけないのですが、それもやっていません。ですからLZ77なんだけどLZ78のような感じになっています。ついでに、今回内容とは全く関係ありませんが、LHAは2.60以前は文字列をツリーに登録していたわけですが、この前からコピーした部分の文字列をツリーに登録する作業を高速化するために、Patriciaではなくてsuffix treeというデータ構造を使っています。LHA 2.60以降では、この部分は単にリストの先頭に追加していくだけなので、前からのコピーが多いファイル、つまり縮みやすいファイルでは昔のバージョンよりもだいぶ高速になっています。
そんなわけでSFA 0.20は、一致している文字列を探す部分でかなり手を抜いているのですが、そのあとでハフマン符号にするところは真面目にやっているので、MAGの絵のファイルのように、すでにLZSSで圧縮されているようなファイルの場合は圧縮率はあまり落ちません。そのかわりスピードもあまり速くないのですが(笑)。そこで、次はハフマン符号にする部分で手を抜く方法を考えましょう。もちろん手を抜いたら最適でなくなるので、ハフマン符号とは呼ばないかもしれませんが(笑)。
発行者 渡辺 尚貴
編集者 安田 知弘
HTML化 木原 英夫
発行所 東京大学理論科学グループ
〒153 東京都目黒区駒場 3-8-1
東京大学教養学部内学生会館 305
TEL 03-5454-4343