mieki256's diary

DXRuby でフルスクリーン表示が上手くいかない問題ですが、DXRuby1.5開発版を使ったら改善されたことを追記しておきます。

ただ、同梱の、Atame/Ruby 0.0.2 に不具合があるようで…。一つ前の Ayame/Ruby 0.0.1 と組み合わせて使ったほうがいいのかもしれず。

Dropboxのpublicフォルダが死んだのでファイルの置き場所を変更。

Python は、「gotoだけ覚えてればいいんだよ！」みたいなノリを感じますし、Ruby は、「何をやろうとしているか明確にしないとダメだよ！」みたいなノリを感じますな…。

例えば、「n回ループさせる」てな処理を書きたいとき。

Python なら、たぶんこうなるのかな。

for i in range(5):
     print i

Ruby なら、こうでしょうか？

5.times do |i|
     puts i
end

Python は、range() を使って一旦配列 *1 を作って、0から4まで数値を入れて、その配列個数分取り出しながらループをしろ、てなことを指示するわけで。…プログラマーは、配列を作りたいわけじゃないのですがね。n回ループさせたいだけなのだけど、なんで配列を作らなきゃいかんのか…。しかし、Python は、「命令の種類はシンプルに」「色んな書き方ができたらダメ」という信条で作ってる言語だから、「この方法でループ処理は書けるんだからコレ使え」「コレさえ覚えとけば、配列に対して処理をしたいときも同じように書けるだろ？ 何にでも使えて便利じゃねえか」で済ませてる。それは、「goto使えば全部書けるんだから、gotoだけ使え」てな思考と結構近い気がします。

Ruby は逆に、n回ループさせたいと思ってるなら、一目でそれが分かる書き方じゃないとダメだろう、という信条があるんじゃないかと。だから、times というメソッドが登場するのかなあ、と。その代わり、どんなループ処理をさせたいかによって、書き方やメソッドがどんどん変わってくる。覚えなきゃいけないことが増えてくる。…まあ、「for i in 0..4 do puts i end」「(0..4).each do |i| puts i end」みたいな書き方もできるから、この例はあまり適切ではないんでしょうけど。

Ruby を覚えた人が、他の言語を触った時になんかしっくりこないのは、そのへんが関係してるのかな…と勝手に想像してみたり。プログラマーがその時何をしたいと思っていたのか、その思考のログがソースに残りやすいのが Ruby、なのかもしれないと。他の言語は、「このソースを書いた時の俺は、こう書くことで、一体何をしようとしていたのか…？」みたいな推測作業が細かいところでちょこちょこ要求されて、それが微妙に苦痛なのかなあ、と。

まあ、自分、プログラミング言語は全然詳しくないので、実際どうなのかは分かんないですけど。

色んな言語を触ってる人なら、もっと適切な事例を出して、各思想の違いをしっかり解説できると思うので、「お前が言ってることは違うよ！ 全然違うよ！」と思ったら、自身のblog等で解説してくれるとありがたいです。

DirectXを使ってフルスクリーン表示する際に、ビデオチップ側に、何かしらの機能でも必要になるのかなと。仮にそうだとして、その機能が自分の使ってる環境にあるかどうかをを調べる方法はないのだろうか…と思って検索してたのだけど。

ゴメンナサイ。何が何だかさっぱりわかりませんでした。DirectXを使ってプログラムを作るのって、めちゃくちゃハードル高いのですね…。そのあたりを簡単にするためのライブラリ等を開発してる方々に対して、ますます強い感謝の念が。

glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE)
# glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE)
# glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL)

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
glEnable(GL_BLEND)

teapotだけ、照明だのカリングだのの結果が妙な感じになってたのだけど。何でも、cube や sphere とは、面の向きが逆だそうで。

_球とティーポット - ゲームが作れるようになるまでがんばる日記

上記のページに遭遇するまで、ハマってました…。ありがたや。

テクスチャ画像も、teapot には反映されるけど、cube や sphere には反映されないらしい。cube に貼ろうとして、ハマってましたわ…。

_11 Geometric Object Rendering

ルーチンはライティングへの利用に対して正しく法線を生成しますが， （ティーポットを除き）テクスチャ座標は生成しません．

11 Geometric Object Rendering より

昨今のスクロールシューティングゲーム(以下、STGと記述)は、えてして縦スクロールなわけで。どうして縦スクロールばかりかと言えば、弾幕ゲーがほとんどになってしまったから。

どうしてそうなるのか、自分はよく分かってないのだけど。上から弾が降ってくると避けやすいけれど、横から弾がワラワラ飛んでくると避けにくい。誰かこのへん、分析してほしいのだけど。何にせよ、そういう理由で、弾幕ゲーはほとんどの場合、縦スクロールSTGとして作られる。STG市場は小さくなってしまったけれど、その中でも、主流は弾幕ゲー。弾幕ゲーになりづらい横スクロールSTGはますます激減。ということかなと。

だけど、縦スクロールSTGには、背景に関して魅力的な見た目をなかなか提供できない、という問題があるように思う。

何故かと言えば、人間は、地面を歩いてる生物だから。鳥のように、上空から真下を眺める生活なんかしてないので、風景に対する選択眼や想像力が鍛えられてない。上空から真下を見下ろした際、どんな風景がそこにあればハッときてグッとくるのか、そのあたり容易にイメージできない。イメージできないから、お客さんが「おおっ」と思うような背景を、なかなか滅多に作れない。「こういう場所を上から見たら、たしかにこう見えそうだよね」と思える背景は描けても、それ以上の何かを ―― お客さんが「うわ、この背景スゲエ」と思える何かしらを、そこに付加できない。

「しょっちゅう飛行機に乗ってあっちこっちに移動してる人間なら、そのあたりの想像ができるんじゃね？」という意見もありそうだけど。そう上手くはいかないだろうと思う。何故なら、飛行機の窓は、真下についてなくて、横にしかついてないので。飛行機に乗っていたとしても、基本的には、風景を横から眺めてばかり。それでは、そのあたりの鍛錬に繋がらない。

その点、横スクロールゲームは、背景に関しては「おおっ」と思う見た目を提供しやすいような気がする。

自分達は常日頃、風景を横から眺めてばかり。電車に乗っても、車に乗っても、部屋から外を覗いても、そこから見える風景は、横から眺めた風景。だから、横から眺めた風景に対しては、毎日ひたすら鍛錬を続け、選択眼を磨いてるので、どんな風景を見せれば「おおっ」と思ってもらえそうか勘所が分かっている。

ということで、見た目の風景・背景でお客さんを楽しませたいなら、横スクロールSTGを作るといいんじゃないかなと。それなら、凡人でも日頃から訓練してるので、まだなんとかなりそう。

そして、真下を眺めた時にグッとくる映像を思い浮かべることができる人は、これは極めて貴重な人材だろうなと。

宮崎駿氏や板野一郎氏は、空中をビュンビュン飛ぶ何かしらを思い描くことに関して、天才ともいえる能力を持っているけれど。縦スクロールSTGで魅力的な背景を打ち出せる人材は、ソレに近い能力を持っている気がする。だってフツーの人は、そんな想像力を ―― 鳥に近い視点で映像を思い浮かべる能力なんか欠片も持ってないし、日頃の生活の中で鍛えようもないわけで。

てなわけで、そういうのを作れる・描ける人を発見したら、大切に扱ったほうがいいよなと。その人、たぶん貴重品ですわ。極めて特殊な分野でのみ発揮できる稀有な能力を持った変人さんです。その能力を活かさない手はないので、イイ感じな配置・活躍場所を与えてやってほしいなと。

てなことを思ったので書き留めてみたけれど、なんかコレ、誰かが言ってたことの受け売りのような気がしてきた…。

自分達は日常的に、上から見た風景をほとんど目にしていないのだから、縦スクロールゲーの見た目は、ただそれだけでも「おおっ」と思うんじゃないか、という論も成り立ちそうな？

もっとも、それが成り立つとしても、他の縦スクロールゲーと見た目で差別化ができてるのか、という問題が残りそう。そういう場面でも、「こういう風景を見せたら驚いてもらえる」と思い描ける人がチームに居れば、差別化というか、商品の魅力を増すことも容易になるのだろうなと。

まあ、「どこにでもありそうな縦スクロールゲーの見た目しか作れない人」より、「誰も見たことないような縦スクロールゲーの見た目を作れる人」は、そりゃ強いでしょうよ、という話に過ぎないんだろうけど。ただ、そういう能力を持っている人を、そういう場所に配置しないと、能力発揮できないよなと。

「アルプスの少女ハイジ」のロケ話で、「宮さん(宮崎駿)は写真をほとんど撮らなかった」「なのに日本に戻ってきたら、あらゆる角度からアルプスの山々を描いてみせた」「どうやら彼は、ロケの最中、頭の中に形そのものを叩き込んできたらしい」とキャラデザの人が言及してた映像を見た記憶があるのだけど。そういえば、宮崎駿氏は建物の設定を作ったりするのが得意、という話もあったっけ。おそらく、立体で捉えるというか、空間把握能力が優れているのかもしれない。

その話を考えると、もしかするとこのへんの話は、単に空間把握能力があるか否かの違いなのかな、という気もしてきたり。

横から眺めた風景は、平面。上から眺めた風景は、立体。…単に、そういうこと？

だとしたら、日頃3DCGでモデリング等をやっている、立体に強いはずの人達が、縦スクロールSTGの背景の案出し作業に加わると、高さを利用した名案をポンポン出してくれる可能性があったり…するのだろうか？

被災地域で、車やケータイのバッテリーが切れて困ってる市民を見かけた戦隊が、変身アイテムで充電してやる光景が。…電流や電圧が違うから、車やケータイが「ボンッ」となるかな。ならないとしても、あまりにもたくさんの市民が群がってきて、充電してやってたら巨大ロボットを動かすエネルギーが無くなって戦隊ピンチ、とか。

味方の等身大ロボットのエネルギーが敵に吸い取られて動けなくなっても、変身アイテムを繋いで充電してやることもできそう。でも、変身アイテムは武器にもなるから、戦隊は苦戦。「俺のことはかまわずに、○○を使って戦ってくれ！」「馬鹿言うな！ そうしたらお前が動けなくなるだろ！ 皆！ ○○の充電率がせめて10％になるまで踏ん張るんだ！」「おう！」「…よし、10%になったぞ！ 待たせたな！」「そうか！ ここから逆転劇の始まりだぜ！」「スマン。今立ち上がったら9%になった。もう動けない」「…。皆！ 15%になるまで頑張るぞ！」「お…おう！」

戦闘中に、変身アイテムに被弾して破損すると大変なことになりそう。何せ、巨大ロボットをまるっと動かせるほどの動力源。おそらく街一つあっさり吹き飛ぶ。実際に爆発事故が起きて、市民が戦隊に対して反対デモを。「戦隊はー、東京からー、出て行けー！」「福島のようなー、ド田舎にー、 引っ越せー！」。そう言われても、敵がどこに出現するのかさっぱり分からないし。困り果てる戦隊。

変身アイテムが壊れてしまって使えなくなっても、代わりの動力源を確保できれば、巨大ロボットは動かせるんだろうな…。「一時しのぎですが、電源ケーブルを差したままなら動かせます！」みたいな。たぶん実況twitterは、「EVAかよ！」の書き込みだらけに…。巨大ロボットが敵の周りをグルグル回って、電源ケーブルで敵を縛り上げるという作戦を。巨大ロボットは途中で電源ケーブルが外れちゃって動けなくなるけど、敵も縛り上げられて動けない。…コレ、どうやって決着つけるんだろう？ フツーのクレーン車で巨大ロボットの武器だけ釣り上げて、一発ズドーンでトドメを、とか？

たぶん、戦隊以外の人物がその変身アイテムを入手しても、巨大ロボットを動かせてしまうのだろう…。

子供が変身アイテムを拾ってしまって、巨大ロボットを動かしてしまうとか。サンライズのロボットアニメ ―― そのへんのどこにでも居る少年が巨大ロボットを、みたいな展開に近づきそうな…。見ている幼児達が、「ボクもあのロボットを動かせるのか…！」とワクワクしたり、するのかな、どうかな。

敵が変身アイテムを入手して、巨大ロボットを動かしてしまうとか。まさしく、「○○を手にした者は、神にも悪魔にも」な展開。

ライダー555みたいに、変身アイテムの争奪戦が始まるかもしれない…。

ハリウッド映画なんかでは、車のキーが無くても配線をゴニョゴニョして車を奪う、みたいな展開があるけれど。戦隊の巨大ロボットでもそういうことができるのかもしれない。操縦桿の下の板を外して中の配線をゴニョゴニョして、「動いた！ これで戦えるぞ！」と。

STAR WARSで、R2-D2が宇宙船の電源ケーブルを繋いだものの電撃で吹き飛ばされる、みたいな描写があったけど。戦隊隊員が一人、巨大ロボットの電源ケーブルを繋ぐ行為に専念するのもアリだろうか。ビリビリする痛みに耐えながら、「頼むぞお前等…早く決着つけてくれ…クウッ…」と。で、その回のラストで、彼はそういう性癖に目覚めてしまう。嘘です。

なんかそういう戦隊があったような気もする。巨大ロボットが「ドルドルー」とか言ってた戦隊は、変身アイテムのコアが頭脳部分だったような…。頭脳というか、魂が入ってる、みたいな設定だったかな…。

頭脳部分なら、喋ったほうが面白いだろうな。喋るということは、巨大ロボットにもキャラクター性が付加されやすくなるわけで。

倒した敵の残骸を片づける際に、「なんで俺がこんなことを…」とブツブツ文句言ってサボってしまう巨大ロボットとか。敵の攻撃でくすぐられて笑い転げて戦いにならない巨大ロボットとか。

とにかく幼女が好きで好きでたまらない、愛読書がアレな巨大ロボットとか。イケメン声にメロメロになる巨大ロボットとか。…アキバレンジャーだな。

幼女と巨大ロボットが心の交流を、とか良さそうだなと思ったけど、 攻殻SACでやってたなと気付いた…。まあ、 タチコマみたいな会話をする巨大ロボットなら、なんだか面白くなりそうだなとも思えるけど。人間の文化が分からないから頓珍漢な会話になったり。…別に巨大ロボットでソレをやらなくても、という気もするけど。等身大ロボットや戦隊のマスコットキャラで、フツーにやってそうな。

歴史が長いから、なんだかどのネタも、何かしらの戦隊で既にやってそうな予感。

ジョイスティックも読み取れるらしい。Python や Ruby で使えるようにした何かは無いのかな…。ググってみたら一応あるみたいだけど、 _Ruby bindings for GLFW library は 2008年頃で開発が止まってるらしく。 _pyGLFW は2007年頃。 _GLFW は2013年にも更新されてるようだけど…。というか、インストール方法が分からん…。

ちょっと気になるのは、文字描画が出来ないらしい点。動作確認用のアレコレを表示するのはちと面倒臭そう…？

まあ、自分は初歩の初歩の初歩を勉強してる状態だろうから、PyOpenGLで充分なのではという気もするけれど。

本来、以下だけで使えるはずだけど。

gem install ruby-opengl

実際にやってみると問題が。

ruby-opengl と一緒に、opengl というモジュール？ライブラリ？も入るのだけど。

opengl (0.8.0 x86-mingw32)
ruby-opengl (0.61.0)

ruby-opengl を使ったスクリプトを実行すると、その opengl.rb が大量の warning を出す。

C:/ruby/lib/ruby/gems/1.9.1/gems/opengl-0.8.0-x86-mingw32/lib/opengl.rb:44: warning: already initialized constant TRUE
C:/ruby/lib/ruby/gems/1.9.1/gems/opengl-0.8.0-x86-mingw32/lib/opengl.rb:44: warning: already initialized constant FALSE
C:/ruby/lib/ruby/gems/1.9.1/gems/opengl-0.8.0-x86-mingw32/lib/opengl.rb:44: warning: already initialized constant ACCUM
C:/ruby/lib/ruby/gems/1.9.1/gems/opengl-0.8.0-x86-mingw32/lib/opengl.rb:44: warning: already initialized constant ACCUM_ALPHA_BITS
(以下略)

opengl だけアンインストールすると…。

gem uninstall opengl

C:/ruby/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:45:in `require': cannot load such file -- glut (LoadError)
        from C:/ruby193mingw/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:45:in `require'
        from rubyopengltest1.rb:11:in `<main>'

試しに、ruby-opengl は入れず、opengl だけインストールすると…。

gem install opengl

C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/opengl-0.8.0-x86-mingw32/lib/opengl.rb:44: warning: already initialized constant TRUE
C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/opengl-0.8.0-x86-mingw32/lib/opengl.rb:44: warning: already initialized constant FALSE
C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/opengl-0.8.0-x86-mingw32/lib/opengl.rb:44: warning: already initialized constant ACCUM
C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/opengl-0.8.0-x86-mingw32/lib/opengl.rb:44: warning: already initialized constant ACCUM_ALPHA_BITS
以下略

どうやら opengl をインストールするだけでも、ruby から opengl が使えるようにも見える。ただ、この大量の warning は困る。

Ruby/SDLが絡んでた。rubysdl-2.1.1.1-mswin32-1.9.1-p243.zip を解凍してインストールする際、以下のファイルがコピーされるのだけど。ソレが、ruby-opengl 側の何かと競合するっぽい。

C:\ruby\lib\ruby\site_ruby\1.9.1\i386-msvcrt\opengl.so

また、ruby-opengl のサイトから辿って入手できる ruby-opengl-0.60.1-x86-mswin32-ruby19.gem (「mswin32」がついてる点に注意)をインストールすると、色々不具合が起きるという話も見かけた。

原因が分かるまで、5時間ぐらいアレコレやりました…。トホホ。

1. opengl、ruby-opengl をアンインストールしておく。(gem uninstall xxxx)
2. Ruby/SDL がインストールした C:\ruby\lib\ruby\site_ruby\1.9.1\i386-msvcrt\opengl.so を、リネームして使えないようにしておく。(opengl.so.sdl_ver とか。) これはこれで、もしかすると、Ruby/SDL使用時に問題が出るかもしれないけれど…。
3. ruby-opengl-0.60.1-x86-mingw32-ruby19.gem を入手してインストール。「mswin32」じゃなくて、「mingw32」なことに注意。

ruby-opengl-0.60.1-x86-mingw32-ruby19.gem は、 _ruby-opengl gem for Windows の一番下のほうで、Trebor777さんが公開してくれている。 _opengl + ruby on Windows - 田舎でプログラミング で紹介されてました。助かりました。

ちなみに、Ruby/SDL の opengl.so をリネームするだけでも、gem install ruby-opengl するだけでスクリプトが動いてるように見える…。けど、不安なので mingw32 版の ruby-opengl を入れておこうかなと。

_RubyでOpenGLをやってみる - フリップフラップ で書かれてるスクリプトを使って動作確認してみたり。teapot、たしかに表示されました。

映画監督と映画Pのコンビが繰り広げる○○劇、てな落語のネタにできないかなと。そういう設定だと、現代落語という扱いになるのだろうか？ 次々に話をでっち上げて苦境を脱したり苦境を呼び寄せてしまうPと、とにかく天邪鬼、かつ二言目には何でも「海に沈めるべき」と言い出す監督のコンビ。とか。

小説やドラマで言うところの、バディ物とやらの設定として使えないだろうか…。ちょっと間違えると「ラヂオの時間」になっちゃうかな…。

いっそジブリ作品の中に出せないか。おじさんコンビとしてそのまま描いちゃうとバレバレだから、ハウル並みの美少年二人組という設定にして。

天邪鬼少年は、気になる女子を目にしても素直に可愛いとは言えず、ブサイクだの何だのと本心と真逆なことを言ってしまって嫌われるのだろうな。そこらへんを突っついてからかう、あるいはキューピッド役を演じるもう一人の少年。しかし日頃からテキトーなことばかり口にする人物なのでさっぱり信用されず。みたいな展開を妄想。

モデルはあの御二方と分かった瞬間、気持ち悪い映画になりそうですかね。だけど、寅さんみたいに毎回失恋するなら全然アリのような気もしたり。

美少年二人組より、美少女二人組にしちゃうほうが、気持ち悪さ倍増で逆に面白くなるのかもしれない。監督をモデルにしたキャラのほうは、完全にツンデレ美少女になるだろうし。見ていてクラクラしてきそうな予感。

何の変哲もない(?)公園のど真ん中に、トライダーG7の頭が。放送が始まるとドキドキハラハラ。早く逃げないと下に落ちて怪我をするのだろう…。

ザブングルやボトムズ(AT)にも乗れるのだろうか。ワクワクするなあ…。

イデオン発動編のソロシップ内の惨劇をリアル体験できる施設なんてどうだろう。どう考えてもお客さんにトラウマを植え付けてしまうか…。というか、どうしてそのシーンをあえてリアル体験なのかと絶対ツッコまれそう。

お客さんが悟空になって何かしら体験するのは、その手の体験イベントとしては何かが違う気がする。なので、とりあえず、来場者は全員ヤムチャになって参加するという設定はどうか。右を見ても左を見てもヤムチャ。会場に集まった、たくさんのヤムチャ。そこに悟空の役が登場してイベントが進む…が、しかし、どんなシナリオなんだろう…。とりあえず悟空は、「おー、おめえ達、ヤムチャか？ 久しぶりだなあ。しかし、しばらく見ない間に随分増えたな…。まあ、いっか」で済ますであろう気がする。ヤツはそういうキャラだ…。

悟空が登場すると思ってワクワクしていたら、ナメクジさんやクリリンが出てきて。会場のどこかで「チッ」と舌打ちの音が。ウ○コを棒の先につけて振り回すメガネ娘や、頭が尻割れしてる宇宙人が出てくる日に比べたら、全然アタリの日なんだけどな。

• 球体の中にトトロの巨大人形(毛だらけ)がぶら下がってる。お客さんはその人形にしがみついて体験する。
• イベントが始まると、久石譲先生作の、あのBGMが。テッテレ、テッテーレ。
• 部屋の内部に、空中を飛んでいるかのような映像をプロジェクターで投影。
• トトロの目の部分にも、こっそりプロジェクターが。猫バスのライト状態。
• トトロ人形は上下左右前後に動く。しがみついてる客に疑似加速感を提供。
• 部屋の壁には送風口がいくつもあって、映像に合わせて色んな方向から風を送り、飛行感を演出。トトロが回転(=周りの風景が回転)するときは、不思議な感覚を味わえるはず。
• 足の先にはモータが。その先についてるコマが回転。気分を盛り上げる。
• 腕力が弱いお客さんのために、トトロ人形の周囲には椅子がついている。椅子は、マックロクロスケを数珠繋ぎしたような装飾。
• 子供がトトロの毛を時々むしり取っていくので、トトロの体はあちこちに十円禿げが。トトロにとって大変ストレスの高い職場であることが想像できる、などとデイリーポータルZの体験記事あたりでさらりと書かれそう。

個人的には、ナウシカのメーヴェ、ラピュタのフラップター、キキのデッキブラシを体験できる施設のほうが嬉しい気もするけど。

キキのデッキブラシはマズイか。上下に激しく動くたびに、「股が、股が裂ける！」「潰れる！○○潰れる！」と悲鳴を上げるお客さんが続出。地獄絵図だな…。ジブリ美術館以上に救急車がやってくる施設になりそう。

OpenGL.error.NullFunctionError: Attempt to call an undefined function glutBitmap Character, check for bool(glutBitmapCharacter) before calling

fullscreenopengl.py。pygame + PyOpenGLで、BG2枚 + 64x64ドット512枚を描画 + oggループ再生をするスクリプト。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

u"""
pygame + PyOpenGLでスプライトの表示テスト

"""

import pygame
from pygame.locals import *
import os

import sys
sys.path += ['.']

# if hasattr(sys, "frozen"):
#      if sys.frozen == "windows_exe":
#          main_dir = os.path.dirname(
#              unicode(sys.executable, sys.getfilesystemencoding())
#          )
#          sys.path.append(main_dir)
#          os.chdir(main_dir)
# else:
#      sys.path.insert(0, ".")

import math

# import OpenGL.arrays.ctypesarrays
# import OpenGL.arrays.ctypesparameters
# import OpenGL.arrays.ctypespointers
# import OpenGL.arrays.lists
# import OpenGL.arrays.nones
# import OpenGL.arrays.numbers
# import OpenGL.arrays.strings
# import OpenGL.platform.win32
# import OpenGL.raw.GL
# import dummy.Process
# import email.Generator
# import email.Iterators
# import numpy
import OpenGL.GL
import OpenGL.GLU
import OpenGL.GLUT
from OpenGL.GL import *
from OpenGL.GLUT import *
from OpenGL.GLU import *

from OpenGL.extensions import alternate
from OpenGL.GL.ARB.point_parameters import *
from OpenGL.GL.EXT.point_parameters import *

from ctypes import util
try:
    from OpenGL.platform import win32
except AttributeError:
    pass

SCR_RECT = Rect(0, 0, 640, 480)

tex = []

# 頂点配列を作成
vertices = [
            [  # ufo.png用
             0, 64, 0,  # 左下
            64, 64, 0,  # 右下
            64, 0, 0,  # 右上
            0, 0, 0  # 左上
            ],
            [  # BG用
             0, 512, 0,  # 左下
             512, 512, 0,  # 右下
             512, 0, 0,  # 右上
             0, 0, 0  # 左上
             ]
            ]

# テクスチャ座標配列を作成
texcoords = [0.0, 1.0,
             1.0, 1.0,
             1.0, 0.0,
             0.0, 0.0]

class MySprite:
    u"""スプライト管理用クラス"""

    def __init__(self, x, y, vx, vy, width, height):
        self.w = width
        self.h = height
        self.whf = self.w / 2
        self.hhf = self.h / 2
        self.fpx = float(x)
        self.fpy = float(y)
        self.fpvx = float(vx)
        self.fpvy = float(vy)
        self.rect = Rect(int(self.fpx - self.whf),
                         int(self.fpy - self.hhf),
                         self.w, self.h)

    def update(self):
        self.fpx += self.fpvx
        self.fpy += self.fpvy
        self.rect = Rect(int(self.fpx - self.whf),
                         int(self.fpy - self.hhf),
                         self.w, self.h)
        if self.rect.left < 0 or self.rect.right > SCR_RECT.width:
            self.fpvx *= -1
        if self.rect.top < 0 or self.rect.bottom > SCR_RECT.height:
            self.fpvy *= -1

def draw_bg(bx, by, texid):
    u"""BGを1枚分描画"""

    # 使うテクスチャを選択
    glBindTexture(GL_TEXTURE_2D, tex[texid])

    # 頂点配列、テクスチャ座標配列、カラー配列を指定
    glVertexPointer(3, GL_FLOAT, 0, vertices[1])
    glTexCoordPointer(2, GL_FLOAT, 0, texcoords)

    for ofs in [[0, 0], [512, 0], [0, -512], [512, -512]]:
        glLoadIdentity()
        glTranslatef(bx + ofs[0], by + ofs[1], -10.0)  # 平行移動
        glDrawArrays(GL_QUADS, 0, 4)  # 四角形を描画

def init_gl(w, h, fullfg):
    """OpenGL関係の初期化"""

    # OPENGL向けに初期化する
    modev = pygame.OPENGL | pygame.DOUBLEBUF
    if fullfg:
        modev |= pygame.FULLSCREEN
    screen = pygame.display.set_mode((w, h), modev)
    if not screen:
        return False

    glViewport(0, 0, w, h)
    glClearColor(0.0, 0.0, 0.0, 1.0)  # クリア色の設定

    # 隠面消去、カリング、照明を設定
    glDisable(GL_DEPTH_TEST)
    glDisable(GL_CULL_FACE)
    glDisable(GL_LIGHTING)

    glShadeModel(GL_FLAT)  # フラットシェーディングを有効化
    glEnable(GL_NORMALIZE)  # 法線の自動正規化を有効化

    # テクスチャの読み込み
    global tex
    glEnable(GL_TEXTURE_2D)  # テクスチャ有効化
    tex.append(loadImage('res/ufo.png'))
    tex.append(loadImage('res/bg1.png'))
    tex.append(loadImage('res/bg2.png'))

    # 座標系の設定
    glMatrixMode(GL_PROJECTION)  # 射影変換
    glLoadIdentity()  # 単位行列

    # 以後、平行投影で描画するよう指定
    glOrtho(0, 640.0, 480.0, 0.0, 0.1, 100.0)

    return True

def loadImage(image_fila_path):
    """テクスチャ画像をロード"""

    # pygameを使って画像ロード
    textureSurface = pygame.image.load(image_fila_path)  # 画像読み込み
    width = textureSurface.get_width()  # 横幅取得
    height = textureSurface.get_height()  # 縦幅取得

    # OpenGLに渡すために文字列化
    textureData = pygame.image.tostring(textureSurface, "RGBA", False)

    texture = glGenTextures(1)  # テクスチャを1枚生成
    glBindTexture(GL_TEXTURE_2D, texture)  # テクスチャとして登録

    # _S は横方向、_T は縦方向
    # テクスチャをリピートさせるかしないか
    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP)
    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP)

    # _MAG_FILTER は拡大時のフィルタ種類, _MIN_ は縮小？
    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST)
    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST)

    # glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL)
    # glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE)
    glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE)

    # テクスチャを設定
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA,
                 width, height, 0, GL_RGBA,
                 GL_UNSIGNED_BYTE, textureData)

    return texture

def draw_text(x, y, st):
    """文字列をビットマップフォントで描画"""
    glRasterPos3f(x, y, -3.0)
    for s in st:
        glutBitmapCharacter(GLUT_BITMAP_HELVETICA_10, ord(s))

def draw_info(cap):
    """現在の状態をテキスト描画する"""
    glLoadIdentity()
    glColor3f(1.0, 1.0, 1.0)
    lx = 16
    ly = 16
    lyadd = 20
    for s in [cap, "F2: Full/Wdw", "F3: SPR ON/OFF", "ESC,Q: EXIT"]:
        draw_text(lx, ly, s)
        ly += lyadd

def main():
    fullscreen_flag = False

    pygame.init()
    pygame.display.set_caption("Full Screen Demo")
    init_gl(SCR_RECT.width, SCR_RECT.height, fullscreen_flag)

    # スプライトを作成
    pmax = 512
    x = SCR_RECT.width / 2
    y = SCR_RECT.height / 2
    sprgrp = []
    for i in range(pmax):
        rad = math.radians(i * 360 / pmax)
        vx = 3.0 * math.cos(rad)
        vy = 3.0 * math.sin(rad)
        sprgrp.append(MySprite(x, y, vx, vy, 64, 64))

    # BGM start
    pygame.mixer.music.load("res/bgm32.ogg")
    pygame.mixer.music.play(-1)

    clock = pygame.time.Clock()
    cap = ""
    frame_count = 0
    bgx = [0, 0]
    bgy = [0, 0]
    sprdraw = True

    running = True

    # main loop
    while running:
        clock.tick(60)  # 60fps

        # OpenGLバッファのクリア
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)

        glMatrixMode(GL_MODELVIEW)
        glLoadIdentity()

        glFrontFace(GL_CCW)  # 頂点反時計回りを表として扱う
        glEnable(GL_TEXTURE_2D)  # テクスチャを有効に

        # テクスチャを透過にする
        glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
        glEnable(GL_BLEND);

        # 頂点配列、テクスチャ座標配列の有効化
        glEnableClientState(GL_VERTEX_ARRAY)
        glEnableClientState(GL_TEXTURE_COORD_ARRAY)

        # BG
        bgang = math.radians(frame_count)
        bgx[0] = -64 + (64 * math.cos(bgang))
        bgx[1] = -128 + (128 * math.cos(bgang))
        bgy[0] = (bgy[0] + 2) % 512
        bgy[1] = (bgy[1] + 6) % 512

        draw_bg(bgx[0], bgy[0], 1)
        draw_bg(bgx[1], bgy[1], 2)

        # スプライト座標更新
        for spr in sprgrp:
            spr.update()

        # スプライト描画
        if sprdraw:
            # 使うテクスチャを選択
            glBindTexture(GL_TEXTURE_2D, tex[0])

            # 頂点配列、テクスチャ座標配列、カラー配列を指定
            glVertexPointer(3, GL_FLOAT, 0, vertices[0])
            glTexCoordPointer(2, GL_FLOAT, 0, texcoords)

            for spr in sprgrp:
                glLoadIdentity()
                glTranslatef(spr.rect.x, spr.rect.y, -10.0)  # 平行移動
                glDrawArrays(GL_QUADS, 0, 4)  # ポリゴンとして描画

        glDisable(GL_TEXTURE_2D)  # テクスチャを無効に

        # 頂点配列、テクスチャ座標配列の無効化
        glDisableClientState(GL_VERTEX_ARRAY)
        glDisableClientState(GL_TEXTURE_COORD_ARRAY)

        # テキスト描画
        cap = '%5.2f FPS' % clock.get_fps()
        draw_info(cap)

        # pygameダブルバッファ交換
        pygame.display.flip()

        # ウインドウタイトルの文字列を設定
        pygame.display.set_caption(cap)

        # キー入力に対する処理
        for event in pygame.event.get():
            if event.type == QUIT:
                running = False
            if event.type == KEYDOWN:
                if event.key == K_ESCAPE or event.key == K_q:
                    # ESCキーかqキーで終了
                    running = False
                elif event.key == K_F2:
                    # F2キーでフルスクリーンモードへの切り替え
                    fullscreen_flag = not fullscreen_flag
                    init_gl(SCR_RECT.width, SCR_RECT.height, fullscreen_flag)
                elif event.key == K_F3:
                    # F3キーでスプライト描画のon/off切り替え
                    sprdraw = not sprdraw

        frame_count = frame_count + 1

    pygame.quit()
    sys.exit()

if __name__ == "__main__":
    main()

setup.py。py2exeに渡す設定が書いてある。

#! c:/Python26/python.exe
# -*- coding: utf-8 -*-

from distutils.core import setup
import py2exe

option = {
    "compressed"   : 1,
    "optimize"     : 2,
    "bundle_files" : 3
}

setup(
    console = [
        {"script" : "fullscreenopengl.py"}
    ],
    options = {
        "py2exe": {
            "includes": ["ctypes", "logging"],
            "excludes": ["OpenGL"],
            }
    },
    data_files = [
                  ('res', ['res/bg1.png',
                           'res/bg2.png',
                           'res/ufo.png',
                           'res/bgm32.ogg',
                           'res/VeraMoBd.ttf']),
                  ('', ['C:\Python26\Lib\site-packages\pygame\libvorbisfile.dll',
                        'C:\Python26\Lib\site-packages\pygame\libogg.dll',
                        'C:\Python26\Lib\site-packages\pygame\libvorbis.dll',
                        'glut32.dll',
                        ])
                  ],

    # zipfile = "lib/library.zip"
    # zipfile = None
)

スクリプトと同じフォルダに、

• glut32.dll
• res/bg1.png
• rse/bg2.png
• res/bgm32.ogg
• res/ufo.png
• res/VeraMoBd.ttf

が入れてある。VeraMoBd.ttf は今回使ってないけど、他のスクリプトの動作時に必要なので入れてある。

mkexe.bat。exeを作成するためのバッチファイル。py2exeを呼び出している。

@rem make exe

@echo フォルダを削除します
rmdir /s build
rmdir /s dist

@echo dist\fullscreen.exe を作ります
python setup.py py2exe
pause

@echo dist\fullscreenopengl.exe を作ります
python setup2.py py2exe
pause

@echo 必要なファイルをコピーします
mkdir .\dist\OpenGL
xcopy C:\Python26\Lib\site-packages\OpenGL .\dist\OpenGL /e

@rem mkdir .\dist\ctypes
@rem xcopy C:\Python26\Lib\ctypes .\dist\ctypes /e

@rem copy C:\Python26\Lib .\dist

pause

ocraを使ってスクリプトをexe化しようとしても、エラーが出てexe化できず。以下のようなエラーメッセージが表示される。

> ocra --windows fullscrtestdxruby.rb
=== Loading script to check dependencies
C:/ruby193mingw/lib/ruby/1.9.1/uri/common.rb:860:in `block in <module:URI>': 内部エラー - DeleteAyameList (AyameError)
        from C:/ruby193mingw/lib/ruby/1.9.1/uri/common.rb:858:in `times'
        from C:/ruby193mingw/lib/ruby/1.9.1/uri/common.rb:858:in `<module:URI>'
        from C:/ruby193mingw/lib/ruby/1.9.1/uri/common.rb:12:in `<top (required)>'
        from C:/ruby193mingw/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:45:in `require'
        from C:/ruby193mingw/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:45:in `require'
        from C:/ruby193mingw/lib/ruby/1.9.1/uri.rb:104:in `<top (required)>'
        from C:/ruby193mingw/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:45:in `require'
        from C:/ruby193mingw/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:45:in `require'
        from C:/ruby193mingw/lib/ruby/site_ruby/1.9.1/rubygems/dependency_resolver.rb:5:in `<top (required)>'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:474:in `const_get'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:474:in `block (3 levels) in attempt_load_autoload'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:468:in `each'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:468:in `block (2 levels) in attempt_load_autoload'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:466:in `each'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:466:in `block in attempt_load_autoload'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:460:in `loop'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:460:in `attempt_load_autoload'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:694:in `build_exe'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:1153:in `block in <top (required)>'

「AyameError」なる文字列が気になる。DXRuby1.5開発版に同梱してあった Ayame/Ruby 0.0.2 で、Ayame/Ruby 0.0.1 を置き換えたのだけど、それが絡んでる…？

いくつか実験。

• DXRuby は1.5開発版のままで、Ayame.dll、Ayame.so を、0.0.1 に戻してみた。 → ocra でexe化できた。
• Ruby 1.9.3 ではなく、Ruby 1.9.2p290 mingw32版で、DXRuby 1.5開発版 + Ayame/Ruby 0.0.1 を使用。 → スクリプトは動作するし、ocra で exe化もできた。
• Ruby 1.9.2p290 mingw32版で、DXRuby 1.5開発版 + Ayame/Ruby 0.0.2 を使用。 → スクリプト終了時に不正終了する。

ocra がエラーを出すだけならまだしも、スクリプトが不正終了してしまうわけだから、おそらく Ayame/Ruby 0.0.2 に何かしらの不具合がありそうな予感。

ちなみに。

• スクリプトソース中のフラグ(?)一つで、Ayame/Ruby 0.0.1、0.0.2 に合わせて、ちゃんと処理が変わるようにして実験。0.0.2 は、prefetch、predecode が無くなったのですな…。
• Ruby 1.9.3 と 1.9.2 の切り替えには pik を利用。gem list で表示される一覧が全然違うので、切り替えはちゃんとできているのだろうと思う。

それにしもて、Ruby 1.9.3 上では不正終了しないのに、1.9.2 上で不正終了するのは…なんでだろ…。自分の環境に何か問題が…？ mingw版は速いという話をどこかで見かけて、 _RubyInstaller for Windows からDL・インストールしてるけど。 _ActiveScriptRuby を入れたら、結果が違ってくるのだろうか…？

とりあえず、当面、Ayame/Ruby 0.0.1 で実験をすることに。録画用PCとネットブック機に、Ruby 1.9.3 mingw版 + DXRuby 1.5開発版 + Ayame/Ruby 0.0.1 でexe化したファイルをコピーして動作確認。

どちらのPCでも、フルスクリーン表示時にチラつき無し。メインPCも含めて、自分の手元にあるPC3台では、どれも見た目問題無し、であります。

一応FPSもメモ。録画用PCは、ウインドウ表示もフルスクリーン表示も、60FPS。低消費電力CPU + AMD785Gチップセットのオンボードビデオでこれだけ動けば充分のような気もする。

ネットブック機は、ウインドウ表示が11FPS前後。フルスクリーン表示は30FPS前後。ふと思いついて、ネットブック機の画面色数を16ビットにして動かしてみたら、ウインドウ表示が16FPSぐらいに向上。フルスクリーン表示は結果変わらず。なんだかちょっとWin95時代を思い出したり。あの頃はPCスペックが低すぎて、そんな感じのアレコレをたまにやってたっけ…。

_fullscrtest_dxruby_20130510.zip (3.8MB)

Dropboxのpublicフォルダが死んだのでファイルの置き場所を変更。

フルスクリーン表示をすると、画面の上部にウインドウ枠が残ったり、そこだけ黒い表示のままになったりする。メインPC上では症状が発生しないが、録画用PC上ではそういう症状が起きる。

以下の2点を加えたところ、症状は見られなくなったけど…。

• フルスクリーン表示とウインドウ表示を切り替える際、pygame.display.set_mode() を呼ぶ直前に、pygame.display.quit()、pygame.display.init() を呼んでおく。
• pygame.display.set_mode() を呼んだ後、glutInit() を呼んでおく。

他のPC上では違った結果になるのかもしれないので、このあたり、なんとも怪しい…。

glut32.dll がバグ持ちなのかと思って、glut32.dll を freeglut.dll で差し替えてみたけど、これは関係なかった模様。ただ、freeglut.dll で置き換えた際に、「glutBitmapCharacter() を使いたかったら glutInit() を事前に呼んでおけ」とエラーが表示されたので、glutInit() を呼べるなら呼んでおいたほうがいいのだろう。たぶん。

ちなみに、freeglut.dll は、 _freeglut Windows Development Libraries から入手できる。freeglut.dll を glut32.dll にリネームしてスクリプトのあるフォルダに置けば使えるみたい。

pygame + PyOpenGL でフルスクリーン表示をすると、画面内に横線が入っているかのような見た目になることに気付いた。おそらく、ダブルバッファを切り替えるタイミングが見えているのではないかと。ティアリングと呼ぶのでしたっけ？

メインループの書き方がよろしくないのだろうか。それとも、垂直帰線期間だか vsync だかそのへんが関係しているのだろうか。OpenGL関係でフルスクリーン表示をすると、画面書き換え(バッファ切り替え？)のタイミングが vsync で固定される、てな話を海外掲示板で見かけたりもしたわけで。

症状が出ている録画用PCは、液晶ディスプレイにHDMI接続しているのだけど、まさか、HDMI接続の場合はvsyncが正確に得られない、等の問題があったり…したら手の打ちようがないのだろうな…。そもそも液晶ディスプレイでvsyncがどうこうってのもなんだかおかしい気もするけど。ブラウン管なら原理からして、そのへんが絡んでくるけれど…。液晶ディスプレイの場合は、どういう仕組み・やり取りになってるんだろうか…。

pygame は SDL を使って描画している。その SDL は、Windows 上で動く際、windib とやらを使って描画している。環境変数 SDL_VIDEODRIVER に 'directx' を指定することで、windib ではなく、DirectX が使われるはず、なのだけど…。

Ruby/SDL上ではそのあたりの切り替えが上手くいかなかったのだけど、pygame 上では反映されるようで、喜んで(?)設定してみたり。しかし、ウインドウ表示中はともかく、directx で一度でもフルスクリーン表示をすると、その後、スクリプトの終了時に、必ず不正終了してしまう。

検索してみたところ、海外掲示板でも同様の不具合報告を見かけた。しかし、どの報告でも、「pygameでDirectXを使うな。OpenGL使え」で話が打ち切られてるようで。…たしかに、マルチプラットフォームを意識すれば、DirectXを選択肢に入れるのはおかしい。でも、ちょっと前までは、SDLもDirectXを活用してた記憶があるわけで。

pygame の標準描画(= SDL = windib による描画)は結構遅いので、directx にして速くなるなら使ってみたい。が、directx にすれば必ず速くなるわけでもないようで。自分のメインPC上で、directx + フルスクリーン表示をすると、画面の書き換えが「ペロン、ペロン」という状態に。たぶん、1FPSすら出ていない…。pygame.HWSURFACE や pygame.DOUBLEBUF を指定してみても劇的変化は無く。

pygame だけで60FPSのゲームを、と考えること自体が無謀なのだろうか。かもしれん…。

pyglet とやらを使えば、また違ってくるのかな。どうなんだろ。

oggのループ再生もできた。

source = pyglet.media.load('res/bgm32.ogg', streaming=False)
self.player = pyglet.media.ManagedSoundPlayer()
self.player.queue(source)  # キューに入れる
self.player.eos_action = self.player.EOS_LOOP  # ループ再生を指定
self.player.play()  # 再生開始

こんな感じっぽい。

pyglet は、ジョイスティックにも対応しているらしい。ただし、pyglet 1.2以降(1.2 alpha1 1含む)で対応、という条件付きだけど。

手持ちのデジタルパッドを接続して実験してみたら、たしかに読み取れている模様。であれば、描画が遅い pygame をわざわざ使わなくても済みそうな予感も。

スクリプト実行中にジョイスティックを引き抜いたらどうなるのか試してみたら、エラーが出て終了してしまった。「応答なし」になったりしないあたりは助かるけれど、終了しちゃうのもよろしくない。接続状態をチェックしてスクリプトの動作に反映させられるのだろうか。try - except を使えばどうにかなるのかな。そのへんまだ調べてない。

メインループの書き方、というか、座標等の更新処理(update())と描画処理(on_draw())がどんな順番・流れで呼ばれているのか、そのあたりがちょっと分からなくて少しアレだなと。画面が時々カクッとなるのだけど、そのへんが絡んでたりするのだろうか。どうなんだろう。

pygletを使ったスクリプトをpy2exeでexe化しようとしてハマる。ちなみに環境は、Windows7 x64 + Python 2.6.6 + pyglet 1.2alpha1。pyglet 1.2 alpha 1 は、 _Python Extension Packages for Windows - Christoph Gohlke から入手したもの、だったと思う。

不具合その1。モジュールが無い云々のエラーが出て起動しない。以下のようなエラーが出る。

D:\pub\exe_test\test_pyglet>fullscrpyglet.exe
Unexpected error loading library D:\pub\exe_test\test_pyglet\library.zip\pyglet\media\avbin: 指定されたモジュールが見つかりません。
Unexpected error loading library avbin: 指定されたモジュールが見つかりません。
Traceback (most recent call last):
  File "fullscrpyglet.py", line 35, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "pyglet\media\__init__.pyo", line 1469, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "pyglet\media\avbin.pyo", line 68, in <module>
  File "pyglet\lib.pyo", line 111, in load_library
  File "ctypes\__init__.pyo", line 431, in LoadLibrary
  File "ctypes\__init__.pyo", line 353, in __init__
WindowsError: [Error 126] 指定されたモジュールが見つかりません。

これは、avbin.dll が必要ということだったらしい。avbin.dll は、

C:\Python26\Lib\site-packages\pyglet\media\avbin.dll

あたりにあるので、exe化した .exe と同じフォルダにコピーする。音声の再生に使うのだろう…と思ったけれど、後になって、どうもそういう感じではなさそうな気もしてきた。

不具合その2。.exe終了時にエラーを吐く。エラーというか、正確には warning なのだけど。以下のようなログが出力されて、「ログを残したよ！」とダイアログが開いて鬱陶しいわけで。

C:\home\prg\_wk\PythonPygletTest1\src\dist\library.zip\pyglet\lib.py:118: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
C:\home\prg\_wk\PythonPygletTest1\src\dist\library.zip\pyglet\lib.py:119: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
C:\home\prg\_wk\PythonPygletTest1\src\dist\library.zip\pyglet\lib.py:120: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6

これは、pyglet 1.2 alpha 1 に入ってる lib.py 内の記述がマズいらしい。

C:\Python26\Lib\site-packages\pyglet\lib.py

というファイルなのだけど。 _1.2 Alpha and Python 3 - Google グループ に報告があったので、試しに書き換えてみたところ、終了時にエラーが出なくなった。

エラーは出なくなったけど、現状では別PCに持っていっても動くところまでできていない。メインPC上ならexe化したファイルも動いてるように見えるけど、録画用PC上では画面全体の色がランダムに変わるだけで、スプライト等の表示が一切できず。しかしoggは再生されている…。pygame + PyOpenGL が動いてたから、OpenGL 関係は一切扱えないPCというわけではないのだろうけど。AMD 785G を乗せたM/Bなわけだし…。

また、ウインドウアプリではなく、コンソールアプリとして exe を作ったら、avbin モジュールが無いとメッセージが表示された。

D:\pub\exe_test\test_pyglet>fullscrpyglet.exe
Unexpected error loading library D:\pub\exe_test\test_pyglet\library.zip\pyglet\media\avbin: 指定されたモジュールが見つかりません。

何をどうすればいいのか、さっぱり分からず。

_python - FPS with Pyglet half of monitor refresh rate - Stack Overflow
_python - Can't draw() sprites in pyglet - Stack Overflow
_Pyglet Tutorial - Vidya Dev Wiki


setup.py 記述の参考例。

_Pyglet/examples/astraea at master ・ adamlwgriffiths/Pyglet ・ GitHub


ジョイスティック関係の参考ページ。

_Working with other input devices ・ pyglet v1.2dev
_http://pyglet.googlecode.com/svn/trunk/examples/joystick.py
_Joystick Class ・ pyglet v1.2dev

一応、前述の動作サンプルも置いておくです。

_noisy_drawtest_20130513.zip

• 解凍して、dist/noisy_drawtest.exe を実行すれば動く…はず。たぶん。
• スペースキーを押すとボールが増える。
• Zキーで3種類の描画方法を切り替え。
• Radeon系は描画方法を「blit()」にしないとボールが表示されない。と思う。ドライババージョンによって結果が違う可能性有り。

_Fix checking for unexpected errors while loading a library - 6aaa0e5 - mammadori/pyglet - GitHub
_History for pyglet/lib.py - mammadori/pyglet - GitHub

昨日、pyglet を使ったスクリプトを py2exe でexe化した際、.exe を実行するとエラーが出て困ってたのだけど。どうやら lib.py の該当部分を GitHub 上の最新版と同様に修正すれば、そのエラーは出なくなる模様。たぶん。

Dropboxのpublicフォルダが死んだのでファイルの置き場所を変更。

Dropboxのpublicフォルダが死んだのでファイルの置き場所を変更。

Windows7 x64 + Python 2.6.6 + pyglet 1.2 alpha 1。

ビデオカード(ビデオチップ)周りの情報は以下の通り。 _HWiNFO32 で取得。

ATI/AMD Radeon HD 4200 (RS880)
	 	
[General Information]
	Device Name:	ATI/AMD Radeon HD 4200 (RS880)
	Original Device Name:	ATI/AMD Radeon HD 4200 (RS880)
	Device Class:	VGA Compatible Adapter
	Revision ID:	0
	Bus Number:	1
	Device Number:	5
	Function Number:	0
	PCI Latency Timer:	0
	Hardware ID:	PCI\VEN_1002&DEV_9710&SUBSYS_97101849&REV_00
 		
[System Resources]
	Interrupt Line:	N/A
	Interrupt Pin:	INTA#
	Memory Base Address 0	D0000000
	I/O Base Address 1	D000
	Memory Base Address 2	FE9F0000
	Memory Base Address 5	FE800000
 		
[Features]
	Bus Mastering:	Enabled
	Running At 66 MHz:	Not Capable
	Fast Back-to-Back Transactions:	Not Capable
 		
[Driver Information]
	Driver Manufacturer:	Advanced Micro Devices, Inc.
	Driver Description:	ATI Radeon HD 4200
	Driver Provider:	Advanced Micro Devices, Inc.
	Driver Version:	8.970.100.7000
	Driver Date:	16-Nov-2012
	DeviceInstanceId	PCI\VEN_1002&DEV_9710&SUBSYS_97101849&REV_00\4&2417585A&0&2808 

Driver Version は、8.970.100.7000 なので、前述のページで書かれていた 8.961.0.0 より新しい…と思う。たぶん。

動作確認に使ったスクリプトは以下の通り。コピペしてきただけ…。

import pyglet

window = pyglet.window.Window(640, 480)
w, h = window.get_size()

vl = pyglet.graphics.vertex_list(4,
                                  ('v2i', (100, 0, 100, h, 200, h, 200, 0)),
                                  ('c3B', (255, 255, 255, 255, 0, 0,
                                           0, 255, 0, 0, 0, 255)))

batch = pyglet.graphics.Batch()

x = 220
y = 10
width = 70
height = 200
color = 127, 127, 0, 127
color2 = 0, 127, 0, 127

batch.add_indexed(4, pyglet.gl.GL_TRIANGLES, None,
                    [0, 1, 2, 1, 2, 3],
                    ('v2i', (x, y,
                             x + width, y,
                             x, y + height,
                             x + width, y + height)),
                    ('c4B', tuple(color * 4)))

x += w / 2

@window.event
def on_draw():
    window.clear()

    vl.draw(pyglet.gl.GL_QUADS)
    batch.draw()

    pyglet.graphics.draw(4, pyglet.gl.GL_QUADS,
                          ('v2i', (400, 0, 400, h, 500, h, 500, 0)),
                          ('c3B', (255, 255, 255, 255, 0, 0,
                                   0, 255, 0, 0, 0, 255)))

    pyglet.graphics.draw_indexed(4, pyglet.gl.GL_TRIANGLES,
                    [0, 1, 2, 1, 2, 3],
                    ('v2i', (x, y,
                             x + width, y,
                             x , y + height,
                             x + width, y + height)),
                    ('c4B', tuple(color2 * 4)))

pyglet.app.run()

一応実行ファイルとソース一式も置いとくです。
_test_pyglet_v2i_20130515.zip

• pyglet_v2i.exe を実行すれば、"v2i"指定版が起動。
• pyglet_v2f.exe を実行すれば、"v2f"指定版が起動。
• src/以下にスクリプトソース入り。

_The AMD Driver Bug Thread - [H]ard|Forum にまとまってた。結構あるんだなあ…。

「昔のOpenGL仕様を使ったアプリを動かすとマズイことになる」てな話が気になる。今回の不具合も、そのあたりが絡んでるのだろうか。わからんけど。

なんだか ATI/AMD だけdisってる感もあるけど、NVIDIAのドライバも結構バグがあるはずなので…。一時期は、 _ビデオカードを熱で故障させちゃうドライバ を出しちゃってたし。ハードウェアを壊しちゃうのは、さすがにクリティカル過ぎる…。

なので、ATI/AMDはとにかく糞と言いたいわけでもなく。どれを選んでも何かしら抱えてるはずだろうと。…まあ、OpenGL使いたいなら、ATI/AMD は今でも避けるのがどうやら無難っぽいですなあ、ぐらいの話で。

ビデオチップは複雑な処理をするハードウェアだし、次々に新チップも出さなきゃいかんし、基本的には DirectX重視の市場だろうから、仕方ないのかも、てな気もしています。

Dropboxのpublicフォルダが死んだのでファイルの置き場所を変更。

Yahooブックマークも、2013年7月でサービス終了だそうで…。ブックマーク先をキャッシュしてくれるのが売りのサービスだったので、ブックマーク先が消滅してもちょっとは安心かなと思っていたけど、サービス自体が終了するのでは、使ってた意味が全然無かったなと…。

ブックマークしたページをオンラインストレージ上に溜め込んでくれるサービスでもあればいいのだろうけど。ネットバブルが弾けたらしい今現在では、実現は難しいのだろうな。

ファイル復元ソフトを使う場合、復元したファイルを別HDDへと書き出すのが鉄則。同じHDDに書き出してしまうと、書き出したファイルが、まだ復元してないファイル群を上書きして、復元できなくなる可能性があるらしく。だから、別HDDに書き出さないとダメ。

なので今回、USB接続外付けHDDを念のために持っていったほうがいいだろうなと。たぶんあちらには無いだろうし。

お邪魔する場所は、比較的古いPCばかりだった記憶があるので、おそらくサーバも古いOSで動いてそうだなと。であれば、外付けHDDをFAT32でフォーマットしておいたほうが安全かな、と考えて準備作業を始めたり。…この時点で、自分は勘違いをしてた。それはともかく。

フォーマットしようとしたところで困ってしまった。Windows7 は FAT32 でHDDをフォーマットできなかったのですな…。NTFS と exFAT だけをサポートしてるのか…。今まで知らなかった…。

Windows7上でも、 FAT32でフォーマットできるツールを検索。 _Fat32Formatter 、 _I-O DATA ハードディスクフォーマッタ に遭遇。

しかし、どちらも動作せず。前者は、何かするたびにエラーダイアログが開くし、後者は、「実行」を押したところで無反応になる。外付けHDDのアクセスランプも光ってない。

OS再起動やら何やら色々試したのだけど。結局以下のことをして、Fat32Formatter が動くようになった。

• USB3.0接続していた別の外付けHDDを外して、フォーマットしたいHDDだけ繋いだ状態にした。
• Alcohol 52% Free Edition で設定していた仮想DVDドライブを無効に。
• Dataram RAMDisk で作っていたRAMディスクを停止。
• Fat32Formatter のデバッグバージョンを使用。

これでようやく、USB接続外付けHDDを FAT32 でフォーマットできた。ここまでの作業で1時間ぐらいかかってしまい、約束の時間を延ばしてもらうための電話を入れる羽目に。

…これを書いてる今になって気がついたけど。外付けHDDは、BUFFALO HD-H300U2 だった。白いケースだから I-O DATA製とばかり…。それでI-O DATAのツールが動かなかったのかな…。自分、アホだなあ…。

さておき。フォーマット中に気がついた。そもそも昔のサーバ用OSとなると、Windows NT だったりしないか？ USB接続で外付けHDDを繋げるのだろうか？

調べてみたら、NT4.0あたりは、NTFSしかサポートしていないし、そもそもUSBには未対応、てな話が。…だったら FAT32 はかえってマズイじゃん。それに、HDD持っていっても繋げないかもしれん。どうしよう。

とりあえず、NTFSでフォーマットだけして、一応持っていくことに。FAT32フォーマットで悪戦苦闘した意味ないじゃん。トホホ。

USB接続できなかったら、その時は泣こう。嘘。その場合は、他PCで共有フォルダを作って、サーバ側から覗いてどうにかするしかないだろう。でも、操作方法を調べてる時間は無い。とりあえず現物を見てから考えよう…。

サーバは Windows Server 2003 だった。良かった。全然新しい。だけど、USB接続できるのかな…。端子はついてるけど…。

繋いだら認識してくれた。助かった。

HDDには、あらかじめ _Recuva の _Portable版 を入れておいたのでソレを実行。思いのほか、ファイルを救い出せた。ラッキーだった。

外付けHDDをクライアントPCに繋ぎ変えて、ファイルを選別してもらおうとしたけれど、サーバ機から外そうとしても使用中と表示される。困った。

仕方ないので、あくまで一時的に、クライアントPC上で共有フォルダを作成してもらい、そちらに転送。

転送直後に気がついた。最初から、クライアントPCに外付けHDDを繋いで、共有設定をしてサーバから覗いて作業したほうが早かったのでは…？ 自分、無駄な作業ばかりしてるな…。いや、ネットワーク上のソレを実行するのと、直接接続されてる外付けHDDから実行するのでは、動作が違う可能性もあるか…。

またしてもコレを書いてる今になって気付いたけど。サーバ側で外付けHDDの該当フォルダを共有フォルダ化すれば、クライアント側で共有設定せずともファイルを持ってこれたのでは…？ まあ、サーバ機の操作方法なんて自分は分からんし、かえって時間がかかったかもしれないか…。

知識のある人から見たら、おそらくはやっちゃいけないことをいくつかやらかしてそうな、そんな不安が。まあ、目的は果たせたはずだから、多少は勘弁してもらうしか…。

他の事項はGRPでメモ。

新パッケージの eneloop と、Victor販売のBD-R 5枚組を購入。

_Fusion というソフトが使える。最新版は有償ソフトだけど、昔の古い版がフリー版として公開されてる模様。

_はやしのなか :: FusionというフリーのHDR合成ソフトがわりとすごい件について
_はやしのなか :: HDRソフトFusionのズレ補正とゴースト除去はスグレモノかも

上記の記事で知りました。ありがたや。

1. 位置合わせしたい画像をD&Dして読み込む。
2. 左側に、読み込んだ画像ファイル名が並ぶ。
3. ツールバー上の、「Align Images」ボタンをクリック。しばらく計算して位置合わせをしてくれる。
4. 左側の画像ファイル名をクリックして選んで、ツールバー上の「Save Result」ボタンを押して、別名保存。それを画像ファイル数分、繰り返し。

まとめて保存してくれないあたりはちょっと面倒な気もする。実はそういう機能がどこかにあるんだろうか？

Hugin関連で、位置合わせをしてくれるコマンドラインツールもあったような気がする…。 _2013/03/24の日記 でメモってた。align_image_stack というツール名だった。

_Photomatix Pro なる有償ソフトでも位置合わせができるらしいので、体験版を試しに触ってみたり。

1. 「ブラケットした写真のロード」をクリック。
2. ダイアログに画像ファイルをD&D。その際、「処理前に32bit HDRイメージを表示」にチェックを入れておく。
3. 「前処理オプション」ダイアログで、「画像のズレを調整」にチェックを入れて、処理内容を選ぶ。
4. 位置合わせをしたHDR画像が出来上がる。ファイル→名前を付けて保存。.hdr、.exr、.tif あたりを選んで保存する。

みたいな流れ、だと思う。

鼻ゲー、脇ゲー、耳ゲー、歯ゲー、なるアレも浮かんだけど、操作方法についてイメージが湧かず。語感(?)はイイんだけど…。誰でも動かせるものじゃないし、何かを発する部位でもないし。

チンゲーは、反応速度を考えたら操作には使えないなと思ったけれど。考えてみたら、セガから発売されて話題になってたことを思い出した。吹きゲーのアプローチだよな…。何かを放出することにも使える部位なら、利用できる可能性がある、ということだろうか。

屁ゲー。…いや、ソレは、自分の望むタイミングで出せるもんでもないし。

ファミコンの2コンマイクは、吹きゲー要素も多少入ってた気がする。もっとも、on/offしか取れなかっただろうし、後に削られた機能だから、それほど使いようもなかっただろうけど。音量を測定できたら、もう少し違う使い方があったのだろうか？

だったらスマホあたりでも、そういうゲームが作れそう。マイクに吹き込んだ声の大きさでプレイヤーキャラのパラメータが変化する、とか。でも、その仕様では、電車の中でプレイすることは許されないし、部屋でプレイしても壁ドンだろうから、プレイできる場所がほとんどないか。

そのあたりを考えていくと、昨今のゲーム商品は、お通夜みたいな状態でプレイできる内容が望まれる、ような気もしてきた。でもないか。一時期流行った音ゲーは真逆か。もっともアレは、ゲーセンでプレイするのがデフォとして考えられてただろうし。

電車の中で腰ゲーをプレイしてる人が居たら大迷惑な予感。

Ubuntu上で Krita を試用する際、Wacom製タブレット等を使って筆圧の入力をしないと、ペン機能の実力のほどがよく分からんな、と。

ということで、Ubuntu でペンタブレットを使用可能にする手順を検索してみたところ、どうやら Ubuntu は最初からペンタブレットを使うためのアレコレが入ってたようで。知らなかった…。

_hikaruさんのブログ ≫ Blog Archive ≫ VM上のUbunru(Linux)でペンタブレットを使ってGimpで絵を描く方法 を参考に、VMware 上でペンタブレットを利用可能にするための設定を .vmx に書いた程度で、すんなりペンタブレットが動いてしまった。当然筆圧も検知されてる。素晴らしい…。

と思ったけれど。 _KO GmbH - Downloads には、Krita 2.6、2.7 はタブレット関係が壊れてる、みたいな一文があるようにも見える。Windows版限定の話なのか、それとも *NIX版も適用される話なのか。どうなんだろう…。

例えば、「ジャイアントゴーグ」「クラッシャージョウ」の安彦キャラデザを見て、「ガンダムみたい」って言い出す人は、まず居ない、ような気が。

例えば、初代「聖闘士星矢」の荒木キャラデザを見て、「ベルばらみたい」「バビル二世みたい」って言い出した人も、さほど居ないだろうと。

例えば、「ウェディングピーチ」の只野キャラデザを見て、「セーラームーンみたい」って言い出す人も、そんなに居なかったんじゃないかなあ。

でも、馬越キャラデザは違う。「ハートキャッチ」の時は、「どれみみたい」「キャシャーンみたい」と言われて。 *1 「聖闘士星矢Ω」が始まったら、今度は「プリキュアみたい」と言われて。結構絵柄を変えているように見えるのだけどなあ…。

毎回こんな感想を持たれるキャラデザの人って珍しいのではないかと。どんだけ飛び抜けた、個性的な画風をお持ちなのかと。パッと見で絵にパワーがこもってるのかと。それでいながら他作品にもフツーに原画として参加して、そこだけ浮いたりせずに溶け込んじゃってるし。「ママレードボーイ」「ベルセルク」などのキャラデザもやってましたし…。

試しに、ガンダムシリーズの新作があり得るなら、馬越キャラデザにしてもらいたいなあ、と思えてきたり。馬越キャラデザが、1st、Z、V、G、W、X、∀、SEED、OO、AGE、全部上書き消去して、「ガンダム」＝馬越キャラデザのガンダム、になるんじゃないかと妙な期待を。もちろん放映中は、「このガンダム、聖闘士星矢みたい」って言われ続ける予感。

マクロスシリーズのキャラデザでもいいなあ。と思ったけど、あっちはその時々で、エロスを感じる娘さんキャラを描いてくれそうなキャラデザの人を、というポリシーがありそうな気もしてきたり。となると…それはちょっと微妙に違ってくるのかな…。

作業した流れだけど。まず、ミラーボール部分だけが残っているかのような、正方形の形にトリミングをして。

GIMP上では、フィルタ → Panorama Tools → Remap を選んで、PSphere に変換するところまでは大丈夫っぽい。Convex mirror → PSphere を選んで、HFOV、VFOVを360度にしてOKを押せば、上下左右がむちゃくちゃになった展開図っぽいのが出来上がる。ちなみに、 _Panotools plugins Readme - PanoTools.org Wiki によると、Remapで変換できる組み合わせには制限がある模様。

これを、フィルタ → Panorama Tools → Adjust で、真っ当な向きに戻してやればいい…はずなのだけど。

開いたダイアログで、setボタンを押して、元画像の形式を選ぶけど、そこがおかしい。PSphere に変換したわけだから、元画像の形式は PSphere を選ばないといけないはずが、何故かラジオボタンが反応しない。押しても押しても別の何かが選ばれる。

バグ持ちバージョンなのかと思って、 _Panorama Tools - Browse /gimp plugin/gimp-2.0 at SourceForge.net から古い版をDLして入れ替えてみたりもしたけれど、状況は同じ。どうなってるんだ…？

_GIMP パノラマツール から入手した pano12.dll を、GIMPのプラグインフォルダに入れちゃってるのだけど、それがマズいのだろうか？ ならばと、本家のバイナリを入れて試してみたり。 _Jim Watters - PanoTools から、PanoTools12_2007Apr25.zip をDLして、解凍、setup.exe を実行してインストール。C:\Windows\SysWOW64\ 以下に、pano12.dll がコピーされたように見える。ファイルは、2007/04/23、バージョン 2.8.6.0。今まで入れてた pano12.dll は、2006/12/16、バージョン 2.8.0.0。

しかし、GIMPの動作に変化なし。コレが原因ではない、ということかな…。

Photoshop 上なら panotools もちゃんと動くのだろうか？ Photoshop Elements 8.0 上で試してみたり。

PanoTools12_2007Apr25.zip をインストールした際、C:\Program Files (x86)\Panorama Tools\Photoshop plugins\ 以下に .8bf がコピーされてるので、それを Photoshop Elements のプラグインフォルダに ―― 自分の場合は、マイドキュメント内に、プラグインを追加するためのフォルダを作成して設定してる ―― に入れる。

Photoshop Elements 上で、フィルター → Panorama Tools → PTRemap を実行してみたところ、「pano12.dll がロードできねえ」と文句を言われて動かない。… SysWOW64 以下に入ってるんだけどなあ。 .8bf と同じフォルダにコピーしてみたけど、それでもダメ。

_Panorama-ダルマのつぶやき Windows 7 64bit 環境下での パノラマ作成−誰か試しましたか？ というページで、「 _PTGui をインストールしないと動かないよ」という話が。PTGui は、有償ソフトなんだけど…。とりあえず、PTGui Proの体験版を試しにインストール。ちなみに体験版は、作成画像にウォーターマークが入る。

今度は、Photoshop Elements 上でも、Pannotools が動いた。しかし、Remap が正常動作しない。横方向に、微妙に縮小されたかのような結果画像が出てくる。どういうことやねん。

ちなみに、PTGui をインストールしても、SysWOW64 以下の pano12.dll は変わってなかった。PTGui は、一体どこに何をコピーして、どんな設定をしているんだろう…？

PTGui をアンインストールしてみた。…やっぱり動かなくなる。うーん。

関連ドキュメントを眺めていたら、アプリと同じフォルダに pano12.dll を入れるのもアリ、と書いてあった。Photoshop Elements のインストールフォルダに pano12.dll をコピー。…動いた。そこに置いとかないとダメなのか。

しかしやっぱり、各フィルタを実行すると、正常動作しない。どうも設定したパラメータが、「OK」ボタンを押した瞬間、毎回必ず初期化されてるように見える。

_Jim Watters - PanoTools をよく読むと、「Windows Vista の場合は、『管理者として実行』しろ。設定をファイルに書き出す必要があるのだ。管理者権限で実行しないと、dllと同じ場所にファイル書き込みできんのだ」と書いてあるように見える。古いから仕方ないのだろうけど、とんでもない糞仕様…。そこはユーザフォルダあたりにしておけよ…。いや、自分も他人のことは言えない。ちょっと前に公開したプログラムも、同じフォルダに設定ファイル書き出してたっけ…。ヤバイな…。

とりあえず、Photoshop Elements を管理者として実行。すると、また、「pano12.dllがロードできねえ」と言ってきた。いいかげんにしろ。

そもそも Photoshop Elements のインストールフォルダが謎な状態であることに気付いた。スタートメニューのショートカットファイルは、
C:\Program Files (x86)\Adobe\Elements Organizer 8.0\Photoshop Elements 8.0.exe
を呼び出しているけど、実体は、
C:\Program Files (x86)\Adobe\Photoshop Elements 8.0\PhotoshopElementsEditor.exe
のように見える。なんで2つもあるの？

前者で実行すると、「ロードできねえ」が出ることに気付いた。後者を「管理者として実行」してみたり。

動いた。ようやく意図通りに動作した。

「管理者として実行」を強要するのはいかがなものかと思うけど、もうメンテナンスされてないツール群らしいので、仕方ないのだろうな。せめて、GIMP上で動いてくれればスッキリするのだろうけど、どうして GIMP上では、PSphere が選べないんだろう…？

閃いた。GIMP側でPhotoshopのプラグインを使える、 _PSPI を使ったらどうなるだろう。Photoshop Elements ではプラグインが動いているのだから、それをGIMPから呼び出して使えば…。

ダメだった。PTRemap はそれらしく動作するのだけど、PTAdjust は、RGBチャンネルがおかしくなったような画像が出来上がってしまう。なんでだろ。

ミラーボール撮影画像を使って、IBLレンダリングにも使えそうなHDRIを作るのはシンドイなと。というか、ちと無理だなと。

• 撮影が大変。
• 撮影後のスティッチも大変。
• 撮影者やデジカメや三脚を切り抜くのも一苦労。
• それでいて、画質は酷いし。

こんな結果しか得られないなら、フツーはやらないよなと。でもまあ…

• 低コストでやれる。
• これでもまだ、撮影時間が比較的短くて済む。

この2つはメリットだろうけど。

• フツーのコンパクトデジカメだけでやろうとしたら、ゴイスな画質は得られるけど、何十枚も撮影することになるので手間と撮影時間が大変。
• 一眼レフデジカメ + 魚眼レンズ + ノーダルポイントを設定できるパノラマ撮影専用雲台なら、そこそこの画質が比較的短い撮影時間で得られるけど、お金がかかる。

貧乏人はミラー撮影ぐらいしか手が無い感じ。「金額」と「手間・画質」は、比例してる気が。

スティッチ作業の大変さは、有償ソフトでもあれば ―― 例えば _HDR Shop 等を使ったら軽減されるのかもしれない。体験版すら存在しない・入手できないようなので、どのくらい違うのかは分からなかったけど。フリーソフトの _Hugin で無理矢理やり遂げようとして、ますます大変なことになってたような気もする。

画質の悪化には、ミラーボールの品質も関係してるのだろうか。何せ、赤ちゃん用の玩具、 _「5分はもちますゴハンまで」 から取り外したソレで実験してたので。コレ、値段は安いけど、表面が波打ってるので、もうその時点で画質は…。いや、デジカメの画素数のほうが問題かしら。Canon PowerShot A570 IS は700万画素程度だけど、1600万画素等のコンパクトデジカメなら、もうちょっと違うのかな？ たいして違いはないかな？

ゴイスな望遠レンズを使えたら、撮影者が小さく写って、各作業が楽だったかもしれない。コンパクトデジカメだったから、それは無理だったけど。

フォーカスを合わせるのも大変。マクロ撮影で合わせてたけど、オートだとボケボケになるので、そこからさらにMFを使って合わせないと…。でも、太陽光の下では、液晶画面は見えない。調整のしようがない。ほとんど当てずっぽう。

まあ、問題山積みってことで。

ミラーボールを4方向 x 3露出で撮影。こんな感じ。

場所その1。


場所その2。


ちなみに、こういうアームを自作して撮影してました。 三脚に固定してたので、デジカメとミラーの位置は、一度設定すれば後から変更する必要はないのだけど。強度が問題だった…。

方向に関しては、どうも4方向では足りないような気もする。5〜8方向ぐらいから撮影しないと、画質の面ではダメな印象も。

あるいは、「画質が悪くてもいいから、とにかく早く撮影を終わらせるぞ」と割り切って、1方向だけ、もしくは90度だけずらした角度で2方向のみ、撮影して済ませるのもアリかも。ミラーボールは、周辺の歪みはともかく、一応360度分の風景が映り込んでるし。どうせミラーボールを撮影してる時点で画質は期待できないのだし。IBLレンダリング用の光源画像として使うのだと割り切れば、それでもOKかも。

ミラーボールは、球が全部入った形で撮影したほうがヨサゲ。そのほうが、後の作業が楽。中途半端に球が切れちゃってると後々面倒臭い。今回はそのへん失敗した。

ミラーボールの固定部分は、ガッシリしたものが必要。そうじゃないと、ブラケット撮影(露出を変えて撮影)した際、各画像の位置がずれてしまう。今回は、固定アームの強度がダメダメで、そよ風が吹くだけでフラフラして、撮影画像の位置合わせ作業が入ってきてますます面倒なことに。

方法はなんでもいいから、自分 ＋ デジカメ ＋ 三脚が小さく写る状態を実現するよう心掛けたほうが後で楽。

• ゴイスな望遠レンズを使って遠くから撮影するとか。
• 撮影する瞬間、三脚の後ろからミラーボールの後ろに、マッハで移動するとか。…ちゃんと撮影できたのか確認する手間が増えるけど。
• 三脚の足と同化して見えるような、JoJo立ちっぽいポーズを新発明しながら撮影するとか。

なんだか馬鹿馬鹿しいけど、一番綺麗に写る部分に、自分の姿がいつも写ってるのは、画質的にもったいないので。

まず、画像の回転や左右反転をする。ミラーだから左右逆なので反転させないと。今回は、 _XnView の「高画質JPEG変換」を使って済ませた。まあ、この作業は、どこの段階でやっても構わないですけど。

撮影画像の位置合わせ。 _Fusion Free版 を使った。ずらした分、周辺に黒枠ができることに注意。…もし、三脚やミラーボールがガッシリ固定されて、ブラケット撮影時も位置が全然ずれてないなら、この作業は必要ないはずですが。

画像を GIMP等でトリミング。ミラーボールがまるっと入った、縦横幅が同じ画像 = 正方形の画像を作る。
ここからは、Hugin で作業。

トリミングした画像群を、Hugin で読み込む。ミラーボール撮影画像の場合、「Equisolid、等立体角」を選ぶのだと思う。水平画角は適当で。どうせ後で自動調整されるし。180〜360とか打ち込んどけばいいのでは。わからんけど。

Hugin 上で、露出の違う画像をまとめて「スタック」にしておく。スタックを使うことで、「この画像達は、撮影位置は同じで、露出が違うだけだよ」と Hugin に教えてやる、らしいですが。スタックの指定の仕方は、画像タブで、画像を複数選んで「新規スタック」だったかな…。

とりあえず「配置」をさせてみる。邪魔なものがたくさん入った状態のプレビュー画像が見れるはず。

• マスクを設定。邪魔な部分を除外していく。
• コントロールポイントが足りてなかったら、手作業で追加したり。
• 「最適化」タブや「露出」タブで、アレコレ選んで最適化。
• 「カメラとレンズ」タブで、画像ごとに露出(EV)が変わってることを確認したり。

イイ感じになったら、スティッチャータブでスティッチする。本来は Hugin からいきなりHDR画像を出力できるのだろうけど、今回、いくらやっても、まともなHDR画像が出力できなかった。仕方ないので、全画像の再マッピングだけをして出力することにした。「再マッピング： 露出補正なし、普通のダイナミックレンジ」にだけチェックを入れて「スティッチを実行」。
4方向 x 3露出の、再マッピングされた画像群(RGBA、8+8+8+8bit)が出力される。
これを、enblend を使って合成する。露出がほぼ同じ4枚(=4方向分)を、1枚にする。

enblend.exe -w -l 29 -o m0.tif 00.tif 03.tif 06.tif 09.tif
enblend.exe -w -l 29 -o m1.tif 01.tif 04.tif 07.tif 10.tif
enblend.exe -w -l 29 -o m2.tif 02.tif 05.tif 08.tif 11.tif

結果、露出が違う3枚が得られる。GIMPで開いて、見た目がおかしいところをレタッチ。
露出の異なる3枚の画像から、HDR画像を作成。今回は、 _Photomatix Pro 体験版 やら、 _Luminance HDR やらを試した。 _Picturenaut でも作れると思うけど、Hugin が出力した再マッピング画像は、どうも細かいところで位置が合ってない感じなので、位置合わせをしてHDRにするソフトのほうがいいのかなと…。

HDR画像からLDR画像を作るのは、Picturenaut や Luminance HDR を使った。

どう考えても面倒臭いです。馬鹿馬鹿しいです。

ボタン一発で360度をブラケット撮影できる低価格なカメラ or 撮影機材とか出てこないかな。まあ、低価格ではミラー方式になって低画質、てなことになりそうだけど。

DropboxのPublicフォルダが死んだので自宅サーバにファイルを置き直し。

本当にIBLレンダリングできているのか自信ないけど。
Shade 12 でIBLレンダリングする場合は、以下のような設定でいいのかなと。

• 背景 → 光源としての明るさを1.0より大きく。
• 無限遠光源 → 明るさを下げる。影をぼやかしたいなら、ソフトネスを0.0より大きくする。
• レンダリング設定で、手法を「パストレーシング」に。大域照明を「パストレーシング」に。

何か間違ってるかもしれないけど。でもまあ、見た目は変わってるし、たぶん合ってる…のかな…？

今現在入手できる版はメニュー項目が英語表記になっていて、設定の仕方がよくわからなかったのだけど。どうにかできた、かもしれず。

• Scene → Volumes を選択。
• Sky Light の項目で画像ファイルを選択。

本当に合ってるのかな…？ 自信なし。

影を落とす方法は、以下の記事が参考になりました。ありがたや。

_Aether　「哀愁の昼休みモデラー」のブログ IBLとオブジェクトの親和
_Aether　「哀愁の昼休みモデラー」のブログ IBLとオブジェクトの親和2

1. 背景だけをレンダリングして画像保存。背景だけレンダリングするには、Clip設定を使う。Scene → Eye → Clip に 10000ぐらいの値を指定。これで、0〜10000の間はレンダリング対象から除外される。
2. Clip を 0 に戻して、本番レンダリング。
3. View → Background → Enable にチェックを入れて、先ほど作成した背景だけのレンダリング画像を指定する。かつ、影だけにしたいオブジェクトを選択して、Background と Compsite Illumination の両方にチェックを入れる。

そんな感じですか？ たぶん。

原発事故の特徴として、「広範囲、かつ、長期」に渡って事故の影響が残るという点があるわけで、そこが鑑みられてないのはいかがなものかと。原発に比べたら、他の発電方法の事故は、「局所的、かつ、短期」で終わると言える。 *1 原発は他の発電方法と色々違う面があるわけですが、事故時の性質も違うわけですよ。

そういった、議論する上では基礎知識レベルの部分も見ずに、一方向だけから見た数値データを持ち出して判断を下しちゃうのは、これはもう暴論というか、思考としてあまりに杜撰というか。…ぶっちゃけ、実にいやらしい手口ですなあと。似非科学だのインチキ健康食品だのでよくやるアレですよね。全体を見ず、一部にだけ注目したデータを持ち出して、相手をその気にさせるやり口。詐欺師の手口ですわ。 *2

どうしても数字で比較したいなら、事故が完全に収束するまでにかかるコストを並べて比較するのが妥当じゃないかと。

• 死者数云々も、遺族に対する補償金等の形で組み込めるはず。
• 農作物に対する補償、除染費用、長期に渡ってそこに住めなくなった人達をどうにかするためのコストやらも、計算に含められるはず。

「全部でいくらかかるのか」で計算すれば、範囲と期間まで網羅した、つまりは事故の性質の違いまで吸収した、全体を眺めた数字が得られるだろうと予想しますが。

もっとも原発関係は、金がかかるはずのアレコレを計算に含めないよう画策するのが常なので、出てきたデータの中身を精査して、抜けがないか粗探しをしないと、本当のコストが見えてこないあたり面倒臭いですが…。

そもそも、廃炉作業すら未来の新技術をあてにしてる状態なのに、正確性を持ったコスト計算ができるのかね、という気もしてきたり。

そんなことを考えていくと、原発関係で何かしらの具体的な数字を元に、切れ味のいい主張を出してきた時点で、「ああ、コイツは俺を騙そうとしている」と疑ってかかるのが正解のような気もするのでした。現状が分かってる人なら、「おそらくは」とか「たぶん」とか、実にぼんやりした言い方しかできないはずなので。低線量被ばくの問題もそうですけど、「分かってない人ほど分かってる振り」をして「本当に分かってる人ほど『分からない』と答える」のが現状の原発関係のアレコレ、ではあるまいかと。や。わかんないですけど。

これからちょっと酷いこと、脈絡のない思考を、書き留めておきますけど…。

原発が許容されないのは、事故発生時、一般市民に対して「とばっちり」がくるから、ですよね。どうして原発を田舎に建てるのか。事故が起きても、都会はその被害から免れたいからで。電力の利用者側は、「何か問題が起きるとしても、俺には関係ないところでやってくれるなら、別に構わんよ」と常に思ってる。

原発は、今まで「とばっちり」は来ないだろうと思われてた。田舎に作っとけば大丈夫だろ、被害を受けるのはどうせ田舎者だけだ、俺達には関係ねえやと。もちろん、知識のある人達は、自分達にも「とばっちり」がくるとちゃんと分かってたから反対してたけど、ほとんどの人は無知だったので、「とばっちり」はないと信じ込んでた。

でも、事故が起きて、「とばっちり」があるのだと分かった。おいおい、話が違うじゃねえか。俺が口に入れる水や魚にまで毒を入れられるなんて聞いてねえよ。だったら原発はねえわ。

…という話なのだろうと思うわけですよ。

今後、世間様はそこらへんを多少考えて、各発電方法の是非を考えていくのだろうけど。そこに、事故の死者数データを持ち出してみても、意味ないよなと。大半は、「現場がどうなろうと知ったこっちゃねえ」「俺にとばっちりが来るかどうかが問題なんだよ」と思ってるんじゃないかと。事故の死者数なんて気にするのは、よほどのオヒトヨシぐらいなもんだろうと。…まあ、そこにオヒトヨシしか居ないなら、見事に騙されてくれるのでしょうけど。

それはともかく。その「とばっちり」云々を逆に考えると、事故が起きても敷地内だけで影響が収まる原発が発明されたら、原発は肯定されるだろうなと予想するのです。極端な話、敷地内の全員が即死する、トンデモで恐ろしい仕組みだったとしても、そこから外部に影響が出てこないなら、世間様は原発を許してしまうだろうと。

まあ、そんな技術・設計は、今現在存在しないわけですけど。ただ、目標地点としては設定できるはずで。いかにして「とばっちり」を減らす仕組みを実現するか。そこが達成されていくかのように嘯いていけば、原発は「アリ」になる。だから、原発政策を継続していきたいなら、そのあたりが目標として見えてくる方針を打ち出さないと。そうじゃないと世間様が、「そういう仕組みなら、まあいいか。俺には関係なさそうだ」と思ってくれない。

でも、ベントフィルタつけたくないとか、活断層の上にある原発を使い続けたいとか、そういうこと言われちゃったら、いくらなんでも反対するしかないですわ。「とばっちり」を減らす気ゼロじゃん。わけがわかりませんよ。本当に原発政策を続けたいと思ってんの？ 続けたいならポーズぐらいは取れと。建前すら守る素振りを見せないって何だソレ。…まあ、アイツラ、福一事故を、自分達には関係ない出来事と思い続けてるから、そういう主張をするのでしょうけど。「チェルノブイリは俺達に関係ない」という思考が、「福一事故は俺達に関係ない」に変化してるような気がします。

結局、「どこか遠い場所で起きてる、自分達には関係ない出来事」と一度思い込んでしまったら、状況改善するために役立つ前例やヒントも見事にスルーしちゃうのだろうなと。まあ、原発に限らず、なんでもそうなんでしょうけど…。

以下を参考にして初期設定。

_Aptana + XAMPP によるローカル開発環境の構築 ・ XAMPP導入編 | milestoner
_XAMPPの使い方
_XAMPP管理ページにユーザー認証を設定 - XAMPPの使い方
_XAMPPのインストール｜インストール・動作環境設定｜PHP｜PHP & JavaScript Room

場合によってはポートの80番その他を既に使ってしまっている時もあるそうで。

_ポート番号の確認 - XAMPPの使い方

C:\xampp\install\portcheck.bat を実行して、C:\xampp\install\portcheck.ini の内容をチェックすれば、既に使われてるかどうかが分かるらしい。もちろん、Apache等動かしてる状態で実行すれば「BLOCKED」になるけど。

Windows7 x64 上で、バーチャルホストを使おうとして hosts ファイルを書き換えるときは、若干注意が必要らしい。

_hostsファイル（Windows7 64bit版)｜まりっくのブログ

現在SP1のWindows7のnotepadもいつも間にか64bitアプリ化されたようで、もはやsysnativeへのアクセスは不可能である。で、現在の私の環境では結局Windows\System32\Drivers\etcのhostsファイルが使用されていた。つまり32bit版と同様であった。

hostsファイル（Windows7 64bit版)｜まりっくのブログ より

_64bit版Windowsのhostsファイルって、どうなってんの？ - 銀の鍵 (The Silver Key)
_VirtualHost（バーチャルホスト）の設定 - XAMPPの設定 - Web77
_windows7のXAMPPでバーチャルホストの設定をする - YATのBLOG

「sysnative」という単語が書いてある解説記事は現状と合ってない、ということで。

面倒臭がって、4.0.2のファイルで上書きしたら、アイコン表示がめちゃくちゃになった…。面倒臭くなって、もう一度 XAMPP を再インストール。

以下のページを参考にして、php.ini や my.ini を変更。改善された。バージョンによって記述が違ってるらしいので注意。

_php.iniファイルの確認と修正 - XAMPPの使い方
_XAMPP on WindowsでMySQLの文字化け対策: T-1000の日記

phpMyAdmin 上でテーブルだの何だのを作成する際に、照合順序で utf8なんたらを選んでおかないと、phpMyAdmin 上でも文字化けするっぽい。

Word が、細かいテーブルをたくさん作って、全体グリッドに沿って配置する機能を推してたら、Excelで無理矢理レイアウトをする事例は減ったかなと想像するのだけど。そういう機能を要求するのって、日本人だけなのだろうか…。

見た目は Excel とクリソツだけど、表計算ソフトじゃなくてDTPソフト、てな感じのソフトを作ったら、日本国内で大ヒットするのだろうか？ Excelでレイアウトする際に使う機能ってそんなに多くないだろうから、作れないことはないだろうと思うけど。どうせ、セルの結合とかそのくらいだよね…？ いや、セルの結合って、意外と実現が難しいか。でもないか。HTMLのテーブルでも、やれてるのだから、わざわざ土台から作らなくても、流用できるアレコレはありそうな気もする。

それにしても、どうして日本人はテーブルレイアウトが大好きなのだろう…？

内容を変更しても、他の要素との相対位置 ―― 縦横の配置が狂わないし、幅を自動調整してくれるから、だろうか？ いや、幅は、各自手作業で調整してる事例が多そうな気もする。だとすれば、各要素を縦横に自動で綺麗に並べてくれるあたりが好まれてしまうのかな？

であれば、Word等も、配置・alignの機能さえ充実してれば、Excelを使う必要はなくなるのかもしれないか。この要素と、この要素は、縦に綺麗に並ぶのだ、みたいな属性を持たせておいて、そういうレイアウトを…。まあ、一々そういう設定をするのは面倒臭いだろうから、「ここからここまでの要素はグリッド上に配置」みたいな機能でもあればいいのかな。デスクトップアイコンの自動整列機能に近い感じで。

行で管理するのではなくて、セルで管理してるように見せかける必要もありそうな。内部では、セルと呼ばれる段落、あるいはテキストボックスとして扱われるのだろうけど。

全体にグリッドを表示・スナップする機能は、Word 98 あたりでも既にあった気がするのだけど。Word 2007 で確認してみたら、グリッド線＝横線のみ、に見えた。機能を削っちゃったのかな…？ それとも隠してあるのだろうか…？ 原稿用紙設定、てのもあるけれど、それはちょっと違うな…。

まあ、そういったことをいくら考えてみても、「Excelあるからいいじゃん」と言い出す人が出てきて、さっぱり解決しないのだろうけど。

Excelは、「表やセルの見た目に関して、バージョン間の互換性を持たせませんよ」「例えば印刷結果はバージョンによって全然違うけど、最初からそういう仕様として作ってますよ」「これは表計算ソフトで、DTPソフトではありません」とMicrosoftが明言してるソフトなので、Excelだけあっても全然ダメダメなんですけどね。あくまで「表計算ソフト」。印刷文書を作るためのソフトじゃないわけで。

例えば。

_美文書作りには「方眼紙」シートを使う：日経ウーマンオンライン【仕事が早くなるエクセル術】

上記のページで示されてる作例。これは本当に、Wordその他で作れないのだろうかと。

_Word 2007 で試してみた。 SkyDriveに置いてみたけど、見れるのだろうか…？ それはともかく、フツーに作れてしまった。まあ、この程度なら当たり前か…。「表」を作って置いてることに違いはないし。

Word 2003、2007は、PDF出力するとなんだか変な線が入るあたりが少し気になった。CubePDFでPDF化すると、そういうゴミは入らないのだけど。

さておき。表の各列幅を調整するあたりは、Word を使うほうが、はるかに自由自在で。その点 Excel は不自由極まりない。不自由だからこそ、「方眼紙シート」なんてアホなことを始めるのだろうけど。

人間、枠だの制限だのを与えてしまうと、その枠の中だけでどうにかしようと馬鹿げた部分最適化を始めてしまう。その一例が「方眼紙シート」なのだろうと思えてきた。

ただ、Wordのデメリットにも気付いたり。

• Excelは、セルの書式設定を指定できる。例えば、売上の列に「通貨」を指定すれば、「54000」等、数値を打ち込むだけで表記を「\54,000」にしてくれる。しかし、Word は、セルの書式設定が指定できないようで、手打ちで「\54,000」と打ち込まないといけない。実に馬鹿馬鹿しい。修正作業が入ってきたら大変。
• Excelは、オートフィル機能があるので、少ない手順で大量のデータを入力することができる。Word ではソレができない。全部手打ちかコピペするしかない。
• Excelは、セル内容を使って計算結果を出せる。Word では、できない。

もしかすると、Excel と Word を連携することで、上記の問題は解決するのかもしれないけど。Wordだけでは、どうにかできそうにないなと。…まあ、解決策を自分が知らないだけかもしれないですが。とりあえず、「入力作業」「データの活用」という面を考えると、Word はちょっとアレですなと。…当たり前か。ワープロソフトだもの。

ついでに、Libre Office (Writer) 4.0.2.2 でも同じ作業をしてみたけれど。こちらは、表のセルに対してフツーに書式設定ができるどころか、合計を求める計算まで、まるで表計算ソフト並みにフツーにできてしまった。Libre Office、スゲエ。しかも無料で使えるし。惚れた。…さすがにオートフィルはできないみたいだけど。それと、表内で文字列を縦書きにする方法が分からなくて困ったり。セルを選択して右クリックして「表」を選んで、とかフツー分からないですわ。

ちなみに、Libre Office Draw でも試してみたけど、これはさすがに無理だった。表の中を縦書きにする方法が分からん…。

とりあえず。Word にしても Libre Office Writer にしても、マス目を作って埋めていくというレイアウト方法ができるようには見えず。Excel でテーブルレイアウトを使うやり方に慣れ過ぎてしまうと、やはり Word等は使いづらいのだろうかと想像を。

前述の作例とは関係ない話だけど。

複雑怪奇なレイアウトをやろうとすると、

• 各要素が奥から手前に積み重なって表示されている「階層」「レイヤー」「Z軸」「奥行」を意識したり
• 何か大きな枠組み、例えばグループ化などで「入れ子」にしていくことを意識したり

そこらへんを作業中にイメージできないと厳しい場面も出てくるかなと思うのだけど。一般の人は、このあたり、あまりイメージできないのかなと邪推したりもして。そういう方々は、全てがマスの中に納まってるはずのテーブルレイアウトが ―― マスをクリックすればそこに何かあるはずだし、マスを空欄にすればスペーシングもできるはず、というやり方が分かりやすいのだろうかと。

各アプリの見た目だけでは、階層や入れ子がそこにあるとは分からないので、イメージしづらいのも仕方ないような気もする。かといって、それらを示す情報を表示してしまうと、WYSIWYGから離れてしまうし。

WYSIWYG…。そうか、なるほど。Excelは、WYSIWYGではないのに、WYSIWYGと勘違いされてるあたりが問題なのだな。

だとすれば、Excelの見た目と印刷結果が、著しく乖離する仕様にすれば、状況改善に繋がりそうな気もしてきた。中途半端に、見た目と印刷結果を一致させてるから、勘違いする人が出てくるのだろうと。

_121ware.com > Word 2007で方眼紙のようなグリッド線を表示する方法
_☆ノートや方眼紙（ワードのグリッドの設定） - Office2007（Word2007 Excel2007）を楽々使おう！

わかりづれー。そんなところにあったのか…。

グリッド線を表示して、テキストボックスをガンガン挿入して配置していったら、Excelレイアウトっぽいことができた。これでいいんじゃないのかな…。

3日後には、やり方忘れてそうな予感。

触ったことないからさっぱり分からんのだけど。印刷前提のチラシ等を作るならイケてるらしいとも聞くわけで。

_Microsoft Publisher | デスクトップ パブリッシング ソフトウェア - Office.com
_Microsoft Publisher - Wikipedia
_PowerPoint／Illustratorユーザから見たMicrosoft Publisher - 情報科学屋さんを目指す人のメモ（FC2ブログ版）

相手先にファイルを渡して、眺めてもらったり、修正してもらう、みたいな使い方は、普及率の問題で無理だろうけど。

体験版、ないのかな…。考えてみたら、Microsoft Office の製品群って、体験版は皆無だよなあ…。システムにがっちり食い込んでくるから、迂闊にインストールさせられない・インストールしたからにはOSと一蓮托生、等の事情もあって、体験版なんか作れないのかもしれないけど。

風の谷のナウシカにおいて、巨神兵の作画を庵野氏が担当してたわけですけど。庵野氏は、人物を描くのがとにかく下手だったので、最後のあたりは宮崎駿監督が、「もうお前はキャラの顔を描くな！ マルチョンだけ描いとけ！ 後で俺が描く！」と怒ってた、という話があって。…宮崎駿監督を原画アシスタントとしてこき使っちゃう庵野さんパねえス。

それはともかく、その、「マルチョンだけ描いとけ！」方式を、3DCGでやれないのですかねえ…。

例えば、ベルセルク劇場版では、3DCGで出力した画の上に、アニメーターさんが手描きで修正作業をしていったらしいですけど。ソレの逆はできないのかなと。

手描きで描かれた何かしらの上に、3DCGを載せてく作業って、その作業担当者に、技術をさほど要求しないですよね…。

• 3DCGモデルは、スーパーモデラーの方が既に作ってるから、モデリング能力は要求されないし。
• 自分で絵を描くわけでもないから、原画を描いてる人達のように高い作画能力を要求されるわけでもないし。

原画に描かれたガイドに沿うよう、3DCGモデルを配置して、場合によっては、せいぜいマスクを切るぐらいなものだろうと。だったら、全コマに対してそれを繰り返す根気さえあれば、誰にでもできる作業じゃないのかと。

でも、そういう作業ができている現場はあまり多くないのかなあ、と。やれてたら、進撃の巨人みたいな話は出てこないであろうと。既にノウハウを持ってるスタジオもあるのでしょうけど、まだ持ってないスタジオも多いのかなと勝手に想像しているのですけど。実際はどうなんでしょうね。

もしかすると、その「マルチョン」「ガイド」のフォーマットが考案されてないのかな、とも。

どういうガイドを描かせるかを、プログラマーなり、3DCGソフトを使ってる人に提案させると、たぶん絵描きさんがゲロ吐きそうな決まりになって、「手で描いたほうが早い」と言われて、結局誰も使わないであろう予感も。

なので、絵描きさん側から提案してもらわないとマズイだろうなと。実際にスイスイと手を動かしてみて、「ここに3DCGがポンと入ったら楽だよなー」と夢想できそうな、そういう形のガイドじゃないといかんような気がしたり。…それって、どういうガイドなんだろう？ 自分は、絵描きとしての能力が低いので、今一つ想像できないのですが。

3DCGを扱う側からすれば、x,y,zの角度、大きさ、画角が瞬時にわかるガイドじゃないと困るでしょうな…。最低限、線分がいくつ描かれたら、角度、大きさ、画角、この3つを算出できるのでしょうかね…。線を2本描くだけでもイケないか？ という気もしてますが。無理かな。どうなんだろ。

タブレットで、スッ、スッ、と線を引いて。あるいはマウスで、カチカチカチカチ、と数回クリックして。たったそれだけで、その位置に、3DCGモデルがポンと置かれたら楽なんじゃないのかなと夢想するのですが。…既にそういうツールはありそうな気もするけれど。

何にせよ、アニメーターさんが楽できる仕組みが登場することを願うのでした。そんな細かい絵は機械に描かせて、アニメーターさんには、人間様にしか描けない絵を描くことに専念させてあげてほしいなと。でもまあ、何か問題がそこにあるのだろうなあ。

前述のgifアニメを作ってて、疑問も湧いたり。

コレ、技術的に可能なんですかね…？

例えばコレが手描きのパース図なら、4つの点座標から、消失点を2つ＋モデルの中心点、を求めるところまでは可能でしょうけど。 パース定規機能がついてるお絵描きソフトなら、似たようなことができた記憶もあるし。ただ、2点透視ならともかく、3点透視で描画したいなら、線分の指定がもうちょい欲しいのではないか、3つ目の消失点も必要になったりしないかと。…まあ、そこは、2点透視＋画面の回転(Z軸の回転？)で済ませちゃう、という制限を設ければなんとかなるのかな？ しかしどうせなら、3点透視の見た目にしたいですわな…。そもそも手描きのパース図を描く時の手順を、いかにもな3DCGの計算に変換できるのかしら？ どんな計算をすればいいのやら。

もう一点。コレ、絵描きさんにとって、本当に楽な指定の仕方になるのかねえ？ と。

絵描きさんにとっては、まだ箱を描くほうが楽だったりしないかと。ただ、おそらく、箱を描いて指定するなら、厳密な描き順を要求されそうな予感も。どの線が「前」なのか。どの線が「奥行」なのか。そういうところを描き順で規定するはず。すると途端に面倒臭くなる。やってられないよなと。

ひょっとすると、3DCGを専門にやってる人ならば、「まだこういうマルチョンのほうが俺達楽だよ」「こういうガイドが描いてあれば、全キャラのアイテムを逐一配置していくのも夢じゃないね」てな別の解もあるのかなと想像したりもして。自分は3DCGに詳しくないので、イメージが湧かないですが。

技術的にできるのか。手順として本当に楽なのか/使ってもらえそうなのか。そのあたり怪しいなあ、と思ったのでした。

後者はともかく前者については、プログラマーに対するクイズみたいなもんですな…。こういう仕様を実現してくれと言われたら、自分は馬鹿だから頭抱えますけど。どうやればいいんだ、コレ。

_C4D 3Dオブジェクトを実写に合成したいのだ… プラグインPhotoMatchがなくても、ある程度カメラを調整: 村人とC4D
_C4D 3Dオブジェクトを実写に合成したいのだ… 消失点が背景画像の外にある場合はどうするんだい…: 村人とC4D

上記の記事では、実写と合成するための座標軸の設定を、手作業でやってるわけですけど。コレを自動でやれたら…基準になる矩形を描くだけで座標系をぐるりと合わせてくれたら、随分楽になりそうだなと夢想するわけですよ。…自動的にやってくれるプラグインとか無いのかな。いや。単に自分が無知なだけで、当たり前のように存在してそうな気も。

実写合成の場合、マッチムーブだかトラッキングだか、そういう技術が使われるそうですけど。そういうのって、アニメ制作にも流用できないんですかね…。と思ってググってみたら。

_カメラトラッキングからマッチムーブまでをAfter Effectsで自動処理するプラグイン：CameraTracker on Vimeo

凄いな…。コレ、手描きアニメには使えないのかな。だけど手描きアニメって、カメラで撮影したような厳密な絵にはなってないから、おかしな結果になったり…いや…どうなんだろう…。

前述のgifアニメの元画像は、CLIP STUDIO PAINT で作ったのですけど。3DCGモデルをD&Dして回転させた際にゲンナリしてしまったり。角度で見え方を調整していくのはやはりシンドイなと。ココにこの方向で置きたいのに、何故そっちを向く…！？ みたいな。このあたり、何かいい手はないものかと。

もっとも、CLIP STUDIO PAINT のソレは、あくまで下絵の参考用として描画するソレだから、3DCGをポンポン置いてく作業を改善してもあまり意味は無いような気も。大量の画像を扱わなければいけないソフトでは、そういう改善も必要になるのかもしれないけど。

そういや、コミPo！の体験版を触った時も、似たような違和感があったような。漫画のネーム描く時に、こんな手順を要求されるかなあ？ フツーはマルチョンでやるもんじゃないの？ みたいな。

一時期、3DCGソフトが流行りそうだったのに今一つ流行らなかったわけですけど。なんかこのあたりも絡んでそうな気もするのでした。フツーの人は、目の前の物体が、x、y、z軸上でどのくらいの角度で置かれているか、なんて考えながら生活してないわけですし…。

以下のページが興味深かった。

_速報！　国連科学委員会　福島事故最終報告書　「福島はチェルノブイリではない」: 農と島のありんくりん
_国連科学委員会議長の福島第１原発事故の人体に対する影響の見解: 農と島のありんくりん
_国連放射線影響科学委員会(UNSCEAR)ウォルフガング・ワイス委員長の現時点でのコメント: 極東ブログ

• 去年の2月ぐらいから出ていた話なので、今になって急に出てきた話ではない。
• 「事故時の測定データが不足してるので、不確定要素はあるよ？」との言及もついている。

後者の話を聞いて、なんだか信憑性が増してきたなと。本当に分かってる人は、どこらへんが怪しいのか、ちゃんと言及してくれるので…。分からない部分をさっぱり口にしないで「危険だ」「安全だ」と断言しかしない人はあてにならないけど、分からない部分・不明な部分をわざわざ説明してくれる人は結構あてになる、ような気がしますよ。 *1

MSVCR90.DLL についてアレコレ試してた際に、最新版をインストール。古い版をアンインストールしてから新版をインストールした。

• ImageMagick-6.8.5-8-Q8-x86-dll.exe
• GraphicsMagick-1.3.18-Q8-win32-dll.exe
• LuxRender 1.2.1 x64 NoOpenCL Setup.exe

LuxRender は、MSVCR90.DLL を使わなくなった模様。

ImageMagick、GraphicsMagickは、もしかすると x64版や Q16 を入れたほうがよかったのかもしれないけど。何かしらのLLで書いたスクリプトをexe化して他のPCに持っていく際、もしこのへんから必要なファイルを持ってきて混ぜられてしまうのであれば、一番無難な版を入れといたほうがいいのかなと。でも、そういう場面あるかな…。あったとしても、黙ってファイル持ってきちゃうものなのかな…。

赤は、男子が苦手。
緊張して何も喋れなくなり挙動不審にもなる。
引っ越し・転校で不安を抱えていたが…
転入先のクラスには、元気いっぱいで破天荒、
ガサツなようでいて気配り上手な青が居た。
男子への態度についてフォローしてくれた青と、
友達になれそうな流れになり安心するが。
実は、青は、男の娘と判明。
てのが1話。
(雨でびしょ濡れ → シャワー浴びなよ風邪ひくよ
 → うっかり脱衣所のドアを → 股間を凝視 → 悲鳴、
というテンプレ展開で。)

青が男子と知り、避けはじめる赤。
しかし青は何かとまとわりつく。
最後には赤がキレる。
「私、男子の前では何も喋れなくなるの！
　だからまとわりつかないで！」
「え？ 今こうして喋れてるじゃん」
「…アレ？」。
友達になろうよとの青の申し入れを受け入れる赤。
てのが2話。

赤は、メガネをかけてる自分の容姿は醜いとか、
真面目すぎる自分が嫌いとか、
それでいて○○を許せないとか、
コンプレックスや固定観念等、その手のアレをたくさん抱えてるけど。
それを青が一つ一つ解きほぐしていく、
てのがその後の話。

青がどうして男の娘をやってるのか、設定を明かす回もあり。

しばらく経って、赤は、
他の男子ともフツーに話せるようになったことに気付く。
青のおかげだ、男子に慣れたのだ、と喜ぶ赤。
青も一応喜んでくれるが、少し複雑な表情。

他の男子から告白される赤。
ついつい青に相談してしまうが、青は大反対。
感情的な反応を見て、赤も反発。大ゲンカに。

なんやかんやあって…

赤は、青を異性としても好きになってることに気付いて(以下略

目が覚めてから、少し考えた。

昔どこかで、「そろそろプリキュアにも男の娘が登場すべき！」という意見を見かけて、「いやいやいや。それは無理だろう」と思った記憶があるのだけど。こうして、夢の中で見たソレを書き留めてみたら、男の娘設定も意外とアリというか、全然イケるんじゃねえの？ と思えてきたり。ベタな展開並べてくだけでも、まとめられるんじゃないのかな…。

考えてみれば…。視聴者は、1年間描かれてきたプリキュア娘達に、かなりの親近感を持っているはずだよなと。何十回も敵とバトルをする中で、あるいは学園生活を送る中で、お互いを助け合い、支え合ってきたキャラ達の、性格だの信頼感だのを知っている。

であれば、最後に、そのキャラ同士がラブラブカップルになることは、視聴者にとってはこれ以上もなく自然な展開であり、実に納得できるラストになりそうだなと。…まあ、長期連載の少女漫画なんかは、ほとんどがそういう構成なので、珍しくもなんともないよくある構成ですけどね。

例えば、いきなり出てきたゲスト男子キャラに、プリキュア娘がほの字になっても、プリキュア娘に思い入れを持ってしまっている視聴者としては、「お前は一体何者なのだ。どこの馬の骨ともわからんヤツに娘はやれん！」という気持ちになるだろうと。1〜2話程度では、その男子キャラの魅力・性格等、なかなか描き切れないですし。しかし、1年間一緒に戦ってきたキャラと結ばれるなら、「お前になら安心して娘を嫁に出せる…。どうか娘を幸せにしてやってくれ…」という気持ちになりそうだなあ、と。…まあ、それは、プリキュアをお父さんみたいな気持ちで見ている、大きいお友達ならそうなるんじゃないの、という予測ですけど。

本来のターゲット層である、幼女達はどう思うのだろう？ たぶん、「よかったねえ」とニコニコして終わるのであろう気もしたり。途中でちょこちょこと、ラブ展開になるのかな、どうかな、と、うっすら匂わせながらさらっと流してヤキモキさせておいて、最後はやっぱりそうなるわけだから、落ち着くところに落ち着いた、的安堵感を得て満足してくれそうな。一番仲良しだったんだから、そのままカップルになる。コレ、何かおかしい流れかな。全然おかしくないよなと。…もちろんソレを同性同士でやったらギョッとさせちゃうだろうけど。男の娘なら、大丈夫。

ただ、問題があるとすれば、男の娘設定に対して生理的嫌悪感を最初から持たれて、番組を見なくなってしまう可能性がありそうなことで。

しかしそのあたり、成功事例もあるわけで。東映出身の演出家である佐藤順一監督が担当したファイブレインというアニメでは、男の娘キャラがメインキャラとしてフツーに溶け込んでた。NHK教育で全国放送したアニメなのに…。子供達もたくさん見てたのに…。佐藤順一監督のバランス感覚、メジャー性、スゲエですよ。

であれば、今の東映アニメ演出陣も、やれるんじゃないのと。先輩がやってみせたんだぜ？ だったら、後輩だって…東映で育ったなら、できるんじゃねえの？ と。 *1

本来マイナーだったはずのアレコレを、メジャーなものに転換してみせるあたりは、東映の演出家陣の十八番だし。そもそも、セーラームーンやプリキュアだって、女の子がバトルするという、マイナー作品にありがちなソレを、メジャー作品に見事転換してみせた実例。であれば、男の娘設定も、上手に組み込んで使いこなしてくれるのでは、と期待してしまうわけですよ。マイナー性にどっぷり足を踏み込んで視聴者をドン引きさせる、その直前で踏み止まり、美味しいとこだけ取り込んでみせるバランス感覚を持ってるから、東映アニメを作れてるはずだし。東映の演出家陣なら、やれるやろと。絶妙なさじ加減を見せてくれるんじゃないの、と。

と言っても、プリキュアシリーズにラブ要素は御法度、という方針もあったか…。

そこも、ちょっと違うんじゃないかと思うのだよなあ…。視聴者が納得できるカップリングが実現できないならやめておけ、という話じゃないのかという気もしていて。見ている人達が、そうなるのが自然だよね、そうなってくれて嬉しいな、と思える見せ方・話の流れが作れたら、特に禁止事項にはならないのではと思えたり。

結局は、幼女がニコニコしながら見てくれそうならどれもアリ、なのかなと。幼女が渋い顔しそうならブレーキかける、みたいな。…男の娘設定やラブ要素は、どうなんだろう。渋い顔するのかな。見せ方次第のような気もするけれど。

別に、男の娘プリキュアを見たいわけではないのですけどね…。無理だろうと思い込んでたけど、やろうと思えばできるんじゃないかと、自分はちょっぴり思えてきました、というだけの話でして。

そんなことをもやもやと考えましたよ、とメモ。

_BlenderでIBL - ILO - I love compositing!!
_扉の先の無限の世界 〜Blender 2.5 & 2.6 で作る3DCG〜 影のみを受けるシャドウキャッチャーオブジェクト
_Improved “Shadows Only” Material | Blender Code
_CyclesでIBLを使う: 豆腐アラモード
_Cyclesレンダーで地面に影はあるけど地面は透過な背景透過画像をレンダリング | 面白いゲーム > trick7
_3DCG blender(4): pikesgtsのブログ