mieki256's diary

「AutoHotKey」じゃなくて「AutoHotkey」なのですな。前者と思い込んでた。他の日記ページを修正。

; 三項演算子のテスト

a=D

; OK
b := a="D" ? 1 : 0     ;=> 1
MsgBox % b

; NG
b := a=D ? 1 : 0       ;=> 0
MsgBox % b

; NG
b = a=D ? 1 : 0        ;=> a=D ? 1 : 0
MsgBox % b

ExitApp

~!Q::
  ExitApp

二番目の書き方をしてしまって、思ったように動かなくてハマったり。

AutoHotkeyには、配列の種類が少なくとも2つあるようで。

• StringSplitで配列にした場合。
• Object() を配列のように使った場合。

混在させて書いてしまったものだから、そこでハマった…。

; StringSplit を利用して文字列を分割、配列にする例
; 結果は、Object を使った配列相当とは違う種類の配列になる模様

inputvar := "Pen Pineapple Apple Pen"
StringSplit, outvar, inputvar, %A_space%

; Display the length of the array. 配列の長さを表示
MsgBox % outvar0           ; OK
MsgBox % outvar.MaxIndex() ; NG
MsgBox % outvar.length()   ; NG

; Display elements of an array. 配列の要素を表示
MsgBox % outvar2    ; OK
MsgBox % outvar[2]  ; NG

; Loop, Parse を利用して文字列を分割、配列にする例
; Objectを配列相当として扱う

inputvar := "Pen Pineapple Apple Pen"
outvar := Object()
Loop, Parse, inputvar, %A_space%
  outvar.Insert(A_LoopField)

; Display the length of the array. 配列の長さを表示
MsgBox % outvar0           ; NG
MsgBox % outvar.MaxIndex() ; OK
MsgBox % outvar.length()   ; OK

; Display elements of an array. 配列の要素を表示
MsgBox % outvar2    ; NG
MsgBox % outvar[2]  ; OK

Object()を使うと連想配列っぽいことができるようで。

; スペース区切りの文字列を分割してObject()を連想配列として扱いつつ記録していく例
; Object() へアクセスする記述もテスト

ks=a b c d e `, -

ks := Trim(ks, " ")
cnt = 9000

lst_a := Object()
lst_b := Object()

; like StringSplit
Loop, Parse, ks, %A_space%
{
  k=%A_LoopField%
  v=%k%
  lst_a.Insert(k, v)          ; a: "a"  
  lst_b.Insert(k, cnt)        ; a: 9000
  cnt+=1
}

For k, v in lst_a
{
  If lst_b[k]=9002
  {
    s := k . " : " . lst_b[k]
    MsgBox % s
  }
}

; picture display test
;
; use AutoHotKey v1.1.24.05

appliname=picture_display_01
appliver=0.0.1
wtitle=%appliname% %appliver%

; 0 is transparent. 255 is opaque
transparentv=210

bgcol=336699
fgcol=FFFFFF
fontsize=32
fontweight=700

; Window init

; Gui, +Owner +AlwaysOnTop +Resize -SysMenu -MinimizeBox -MaximizeBox -Disabled -Caption -Border +ToolWindow
Gui, +Owner +AlwaysOnTop +Resize

Gui, Margin, 8, 0
Gui, Color, %bgcol%

cdir=%A_ScriptDir%
opt=X0 Y0 AltSubmit BackgroundTrans
Gui, Add, Picture, %opt% vIconBas, %cdir%\mouseicon_000.png
Gui, Add, Picture, %opt% vIconLMB, %cdir%\mouseicon_001.png
Gui, Add, Picture, %opt% vIconMMB, %cdir%\mouseicon_002.png
Gui, Add, Picture, %opt% vIconRMB, %cdir%\mouseicon_003.png

Gui, Font, C%fgcol% S%fontsize% W%fontweight% Q2, Arial
Gui, Add, Text, x+0 yp+0 Vbtnstext, Alt+Q ... Exit
Gui, Show, NoActivate, %wtitle%
WinSet, Transparent, %transparentv%, %wtitle%

; GuiControl, , btnstext,
GuiControl, Hide, IconLMB
GuiControl, Hide, IconMMB
GuiControl, Hide, IconRMB

; work init

btnslist := Object("LButton", "IconLMB", "MButton", "IconMMB", "RButton", "IconRMB")
nowstate := Object()
oldstate := Object()
For k, v in btnslist
{
  nowstate.Insert(k, 0)
  oldstate.Insert(k, 0)
}

Loop
{
  ; check status of mouse button
  For k, v in btnslist
  {
    oldstate[k] := nowstate[k]
    GetKeyState, s, %k%
    nowstate[k] := s="D" ? 1 : 0
      
    If (nowstate[k] + oldstate[k]) <> 1
      Continue
    
    If nowstate[k]<>0
    {
      ; pushed button
      GuiControl, Show, %v%
      GuiControl, , btnstext, %k% On
    }
    Else
    {
      ; released button
      GuiControl, Hide, %v%
      GuiControl, , btnstext, %k% Off
    }
  }
  
  Sleep, 16   ; 60 FPS
}

EXIT:
GuiClose:
  ExitApp
  
~!Q Up::
  ; Alt + Q ... Exit
  ExitApp

ずっと無限ループさせてるけど、何もwaitを入れなかったらマウスボタンを押した際に処理待ち？のアイコンが出てしまって少し困ったり。60 FPS程度で回ることを期待して Sleep, 16 を入れてみたら出にくくなった。ちなみに Slepp に指定する数値の単位はms(ミリ秒)。

_Sleep - AutoHotkey Wiki

また、ループするたびに画像の表示/非表示を設定すると該当部分がチラチラしてしまった。ボタンの状態に変化があった時だけ表示/非表示を変更する、みたいなソースにしておかないと表示が見苦しくなるなと。

ボタンの押し下げ状態は、GetKeyState で取得できる。

GetKeyState, 変数, ボタンやキー種類

という形で書く。キー種類の後ろに「, P」もつけられるけど、「P」をつけるとキーカスタマイズソフトの類がキー割り当てを変更してしまう前の状態を返してくるので…。例えば、キー操作・ボタン操作を表示したい、といった場合は「P」をつけないほうが目的を果たせる気もする。要は、とにかく「P」をつけとけばいいのだ、というわけでもなさそうだよ、と。

_GetKeyState - AutoHotkey Wiki

画像の表示は Gui, Add, Picture, を使うけど。表示した画像の表示/非表示の切り替えは、GuiControl, Show, xxxx や GuiControl, Hide, xxxx でいいらしい。対象を指定する xxxx の部分は、Gui, Add, Picture, Vxxxx , 画像ファイル名、と言った形で指定しておく。「v」「V」のどっちを書いたらいいのかは、よく分からない。大文字小文字は区別するのか、区別しないのか…。こういうところにも微かなトラップ臭が。

キーを連続で叩いた時にそれが分からないという問題が。「G x 2」「W x 4」みたいな感じで表示できればいいのだけど、どう書けばいいのやら。

ていうかやっぱり、履歴が残っていかないと、ちと分かりづらいよなと。しかし、どういう処理をすればいいのだろう…。

; wheel up/down check
; use AutoHotKey v1.1.24.05

#SingleInstance, Force
#InstallMouseHook

appliname=wheelupdown_check_01
appliver=0.0.1
wtitle=%appliname% %appliver%

; GUI settings

; Gui, +Owner +AlwaysOnTop +Resize -SysMenu -MinimizeBox -MaximizeBox -Disabled -Caption -Border +ToolWindow
Gui, +Owner +AlwaysOnTop +Resize -MinimizeBox -MaximizeBox
Gui, Color, 336699
Gui, Font, CFFFFFF S26 W700 Q2, Arial
Gui, Add, Text, Vkeystext, Alt+Q ... Exit
Gui, Show, NoActivate, %wtitle%
; GuiControl, , keystext,
WinSet, Transparent, 220, %wtitle%

cwheeldown = 0
cwheelup = 0
check_cwheeldown = 0
check_cwheelup = 0

ks=WheelDown WheelUp Space Up Down Left Right BS
keyslist := Object()
nowstate := Object()
oldstate := Object()
Loop, Parse, ks, %A_Space%
{
  k=%A_LoopField%
  v=%k%
  keyslist.Insert(k, v)
  nowstate.Insert(k, 0)
  oldstate.Insert(k, 0)
}

Loop, 
{
  For k, v in keyslist
  {
    n := nowstate[k]
    oldstate[k] := n
    nowstate[k] := 0
    If k=WheelDown
    {
      If cwheeldown<>%check_cwheeldown%
      {
        check_cwheeldown := cwheeldown
        nowstate[k] := 1
      }
    }
    Else If k=WheelUp
    {
      If cwheelup<>%check_cwheelup%
      {
        check_cwheelup := cwheelup
        nowstate[k] := 1
      }
    }
    Else
    {
        nowstate[k] := GetKeyState(k)
    }
  }
  
  keys=
  For k, v in keyslist
  {
    If (nowstate[k] + oldstate[k])=1
      If nowstate[k]<>0
        keys=%keys% %k%
  }
  keys := Trim(keys, " ")
  
  If keys<>
    GuiControl, , keystext, %keys%
  
  Sleep, 16
}

EXIT:
GuiClose:
  ExitApp

~*WheelDown::
  cwheeldown += 1
  return
  
~*WheelUp::
  cwheelup += 1
  return

~!Q Up::
  ; Alt + Q ... Exit
  Goto, EXIT

以下のやり取りを参考にして書いてみたり。

_getkeystate wheel (Getkeystate not wheely good!) - Ask for Help - AutoHotkey Community

GetKeyStateを使ってホイール回転を検出しようとすると、ホイールを回した途端、そこからずっとOnが返ってくる状態になってしまう。しかし、ホットキーラベル(WheelDown::、WheelUp:: 等)を使うと、そこはホイールを回した瞬間だけ呼ばれるようで。なので、そこで変数の内容をインクリメントして、メインループ内で「変数の内容が今までと違っているか」を調べて、ホイール回転があったかどうかを判断してる。

GetKeyState は、「GetKeyState, 変数, キー種類」という形でも書けるけど、「n := GetKeyState(キー種類)」という形で書けば、1/0で状態を取得できるらしい。

; gui context menu test
; use AutoHotKey v1.1.24.05

#SingleInstance, Force
#InstallMouseHook
CoordMode, Mouse, Screen

appliname=contextmenu_test
wtitle=%appliname%

; set context menu
Menu, ctmenu, Add, %wtitle%, SettingsLable
Menu, ctmenu, Add,
Menu, ctmenu, Add, Settings, SettingsLable
Menu, ctmenu, Add, Exit, EXIT

; GUI settings
; Gui, +Owner +AlwaysOnTop -Resize -SysMenu -MinimizeBox -MaximizeBox -Disabled -Caption -Border -ToolWindow
Gui, +Owner +AlwaysOnTop +Resize
Gui, Color, 336699
Gui, Font, CFFFFFF S24 W700 Q2, Arial
Gui, Add, Text, Vkeytext, ...( RButton : ContextMenu )
Gui, Show, NoActivate, %wtitle%
; GuiControl, , keytext, Alt+Q : Exit
; WinSet, Transparent, 200, %wtitle%

Loop
{
  Sleep, 16
}

EXIT:
GuiClose:
  ExitApp

GuiContextMenu:
  Menu, ctmenu, Show, %A_GuiX%, %A_GuiY%
  Return
  
SettingsLable:
  MsgBox, Settings
  Return
  
~!Q Up::
  ; Alt+Q ... Exit
  Goto, EXIT

GuiContextMenu というラベルを書くと、ウインドウ上で右クリックした時にそこに飛んでくるらしい。

メニューは、Menu コマンド？で生成しておくようで。

_Menu - AutoHotkey Wiki

メニュー(カスタムメニュー)への項目追加は以下のような記述になる模様。

Menu, カスタムメニュー名, Add, メニュー項目, その項目が選ばれた時の飛び先のラベル名

メニューの表示は以下。

  Menu, カスタムメニュー名, Show, %A_GuiX%, %A_GuiY%

%A_GuiX% , %A_GuiY% は、イベント発生時のマウスカーソル座標。

例えば髪の毛がアレな人だったら、「ああ、体は光りませんけど、ココは光ってますよ？」と言いつつ頭をペチン、とかやって返せそう。それともアレかな。「また髪の話してる…」とつぶやいて「そっちじゃねえよ！」的ツッコミを誰かが入れてくれるのを待つとか。

いや、髪の話にすり替えるのも微妙か。それも放射能絡みになっちゃうか。「俺の髪がこんな状態になったのも東電のせいですよ東電許せませんよ一族皆この頭ですよひいおじいちゃんの代からコレですよ東電マジ許せない」てのはどうか。もちろん「お前ソレ遺伝だろ！」のツッコミ待ちなんですが。

「体は光りませんが瞳は若々しさで常に輝いてます。さりげなくギンギラギンです」てのはどうか。カッコつけすぎか…。ていうか「さりげなくギンギラギン」って言い出すあたり全然若くねえ…。

「そうなんですよ懐中電灯要らずでコレ結構便利、ってねえから！ 光らねえから！」と話に乗りつつキレて〆るとか。芸人さんがよくやってますな。

「体は光りませんが俺のビッグマグナムは光るらしいです。コレ使うと相手の方がスパークするともっぱらの噂で」てのはちょっと意味分かりづらいですね何言ってんだこいつ的冷たい視線に晒されそう。

全然関係ないけど本当に股間が光ったらそれはそれで面白いんだけどな。福島県人がズボンとパンツをすっと下ろすと激しい光がカッ！。周囲の人達が「うわああ！」「目が〜目が〜！」とムスカ状態ってソレ一体どんな光景やねん。「福島県人には気をつけろ。やつらはバルスを持ってる…」って無いから。残念ながらこれっぽっちも光らないので。何？ そんなもん見たら違う意味で目が潰れる？ 貴方酷いことを仰る。

などと他県人からアレコレ言われることを想定して上手い返しができないものかと繰り返しシミュレーションしているうちにそれらの返しが蓄積かつ洗練されて結果「原発漫才」「フクイチ漫才」と呼ばれる新ジャンルが福島県人の中から誕生してしまうのです。「逆境を笑いに転化して乗り越えていく福島県人のタフさを如実に感じさせる文化である」とWikipediaあたりに書かれちゃったりしてってないか。その展開は無理があるか。全然タフじゃないし。既にかなりグロッキー状態だし。

アメコミヒーローみたいに放射能を浴びて特殊能力が身に付いたならまだしも何もないですからね…。目からビーム出せるようになるとか特典ぐらいつけろよと。いや実際ビーム出たら困るけど。これじゃ被曝損ですよ…。せめて何か捻って少しは美味しい状況に持っていけないか。難しいか。難しいな。かなり難しい…。

銀河鉄道999に、そういう設定の回があったような…。ゲストの美少女キャラがそのことで コンプレックスを抱えていて部屋の隅で小さくなって「見ないでください…見ないでください…」と口走るんだけど、見てしまった鉄郎が思わず 「綺麗だ…」ってつぶやくんですよね…。

「もし、お前の体が光ったとしても、俺が鉄郎のように 『綺麗だ』って言ってやるよ」とか言いながら口説けるぐらいの男になってみせろ！ てのは無理か。そもそも福島県人は光りませんので。

考えてみたら銀河鉄道999のソレで出てくる光は、夢とか希望とかその手のメタファー、だった気がしてきたり。

「福島県人の体は光らない。でも、心の中には○○と言う名の光がある」ぐらいのことを言えるようになりたいなあ。や、その○○がさっぱり思いつかないんですけど。 コシヒカリとかどうか。なんでや。意味分からん。コメントに困りますな。米だけに。

真面目な話、「放射線を浴びて体が光る」という与太話の元ネタが _ロシア(ソ連)の原潜絡みのジョーク らしい、というのは分かったけど、そのジョークの元ネタが分からないなと。ちょっとググった程度では出てこなくて。まあ、検索キーワードが悪いのだろうけど…。

仮に、「放射線を浴びた物質が光る」という現象が存在するなら、「人体が光るほどの放射線を浴びるとなると○○シーベルトを浴びなければならないがその○○分の一の○○シーベルトを浴びた時点で人間は即死する。故に、放射能で光るようになった人間が目の前に居たとしたらその人は生まれた時から地球人ではなかった可能性が極めて高いので放射能がどうこう言ってる場合じゃないですぞ？」みたいな似非理系っぽい返しもひょっとするとアリなんじゃないかと妄想したのですが。そもそも「放射線を浴びた物質が光る」という現象が実在しなかったらそんな返しもできないし、同時に、「そのジョークって一体どこから連想したの？」「どうして光ると貴方達は思ってしまったの？」という謎が浮かんでくるわけですよ。

まあ、専門家さんや、あるいはSF作家さん、SF考証をやってる方なら、「ああ、あのネタの元ネタはねえ…」と解説できるのかもしれませんが…。

まさか、映画「ゴジラ」からの連想だったりしないだろうな…。となると、日本人は「アレはロシアのジョークが元ネタだから」とか言ってロシア人のせいにしてたけど、実は元凶は日本人じゃねえか！ って話になってきそうで嫌な感じだなと。日本人は一体どんだけ罪を重ねれば気が済むのか。なんと恥ずべき民族であらうか。

でもまあ、その場合、「そもそも生物だったはずのゴジラを、どうして光らせようと思いついたんだろう？」「ゴジラは何故光るのか？ 元ネタは何なのか？ どうしてそんな発想に至ったのか？」という話に繋がっていきそうですけど。当時劇場で見ていた人達は「なんで生き物が光るんだ？」と疑問を持たなかったのだろうか。持たなかったとしたらそれは何故か。まあ、蛍なんかも光るけど、蛍とゴジラはデザイン的にも飛躍し過ぎてないか、とも。

やっぱり _このあたり とか _このあたり からの連想なのかな…。しかし、電球も、蛍光灯も、LEDだって光るよな…。「TVばかり見てると液晶TVの電磁波で体が光るようになるよ！」とか言われてもおかしくなさそうだけど、そういうことはあまり言われないのは何故だろう。

どうも世の中、「これは体に移らない」「これは体に移るかもしれない」的な境界線が非科学的に引かれている可能性が。どこにその境界線があるのか分からんけど、何か奇妙な心理というか、判断基準が日本人の中にありそうな気がする。いや、日本人に限った話じゃないか。外国でもその手のジョークが存在するわけだし。

まあ、個人的には、件のジョークの元ネタが気になるなと思った次第です。謎だ。どうして我々人類は、「放射能を浴びると光る」と思ったんだろう…。

Windowsは、キーを押しっぱなしにするとキーリピートが働いて、連続でキー入力されるわけだけど。その種類の入力をAutoHotkeyで検出する方法が分からなくて。AutoHotkey関連ページを色々眺めてみたものの、ヒントすら見つからず。

AutoHotkeyのメインウインドウを表示して key history を確認すると、キー押しっぱなしの連続入力時も履歴が残っているのだけど…。GetKeyState だけを使ってどうにかするのは難しい、ということかもしれず。

blenderでテキトーなモデルを作成して .obj (.mtl) でエクスポートしてみたのだけど。行頭に「l」が入ってる行が。何だろコレ…。もしかして、ランプ？ いや、違うな…。ランプを削除してから .obj をエクスポートしても相変わらず存在するし。何だろコレ。

_Object Files (.obj) を眺めていて分かってきた。「l」は「Line」の「l」か…。って、なんでそんなものが入っちゃっているのやら。

blender側で、メッシュ → クリーンアップ → 孤立を削除、を選んでみたら、どうやら孤立してた辺を削除できた模様。

画面を眺めていて気になったところが。おそらくは撮影段階で、手描きっぽく見える何かをかけている感じがして。線をかすれさせたり、若干塗りミスがあるかのように色の範囲を少し膨張させたり等。パッと見の雰囲気はイイ感じだなと。

しかし、なんだか不思議な状況になってきているような…。昔、セルでアニメを作ってた頃は、トレス線がかすれるとか、塗りが線からはみ出すなんてのは基本的にNGというか許されないこと、てな方向で努力してたはずなのだけど…。 *1

デジタル制作に移行して、仕上げ前の線画は二値化されたから線がかすれてしまうこともなく、バケツツールで塗るから線から塗りがうっすらはみ出てしまうなんてこともなくなったはずなのに。そこにフィルタの類を適用して、わざわざ線をかすれさせてボソボソゴツゴツさせたり、塗りミスっぽく見えるギリギリのところを攻めてみたり…。

セルで作ってた当時であれば、今のデジタル制作のソレは、ある面では理想と言うか究極の仕上げ状態・映像に思えたはずだよなと。なのに今、当時の感覚では「プロならこんな仕上げをやっちゃダメ」てな状態を、あえて苦労して再現してるという…。

当時追い求めていたはずの「綺麗なアニメ映像」って、一体何だったんだろう？ ソレは、苦労して神経擦り減らして追求すべき理想の映像だったんだろうか？ そんなところにアニメとしての価値はあったんだろうか？

それは同時に、今のアニメが追求してる映像の方向性にも疑問が湧いてしまうわけで。例えば、やたらめったら線が多くて手描きアニメーターさんが地獄を見ているそういう方向の映像って、これは本当に追及すべき理想の映像なんだろうか。十数年後「アレは一体何だったんだろう」「何のためにあんなことしてんだろう」「○○使えば一発だったのにわざわざ手描きして…」とか言ってたりして。

とりあえずそんな感じで、なんだか不思議な状態になってるなと思いました。とメモ。

ソースは以下。wavefront形式のファイルを読み込むクラスと、gosu + opengl で描画するスクリプトの2つ。

_wavefrontobj.rb - gist
_gosu_opengl_test3.rb - gist

動作確認に使ったモデルデータは以下。suzanne.* 以外は自作データなので、CC0 / Public Domain ってことで。

_wavefront_models_20170310.zip

各ファイル・フォルダを以下のように置いて、ruby gosu_opengl_test3.rb を実行すれば描画される。また、カーソルキーの左右でモデルを変更できる。

./
|   gosu_opengl_test3.rb
|   wavefrontobj.rb
|
+---wavefront/
        *.obj
        *.mtl
        *.png

gosu や opengl のインストールについては、 _2017/02/07の日記 を参考に。と言っても、 _RubyInstaller for Windows がインストールされてる環境なら、

gem install gosu
gem install opengl
gem install glu
gem install glut

をするだけでいいのかな。たぶん。

OpenGLで複数のテクスチャを使用するやり方が分からなかったのだけど。結局、wavefront形式のファイルを読み込む際に、マテリアル別、というかテクスチャ別に面情報を配列に記録して、描画する際はマテリアル毎、というかテクスチャ毎にガーッと面の描画を一気に指定、みたいな形になってしまったり。

_gosu-opengl-tutorials/lesson10_advance.rb も複数のテクスチャ画像を扱って描画してたので参考にしたのだけど、モデルデータであろう _world.json を眺めると、テクスチャ画像別に面情報を列挙して、テクスチャ毎に描画の指定をしてるようで。そういうやり方が無難なのかなと。

wavefront(.obj)形式ファイルは、blender 2.78、及び、Metasequoia 3.1 からエクスポートして用意した。

Metasequoia 3.1 から wavefront形式でエクスポートする際は、マテリアル(材質設定)のシェーダをランバート以外にして各数値を弄らないとOpenGL上では妙な見え方になった、とメモ。現行版の Metasequoia 4.x は持ってないので、そちらではどうなるのか不明。

前述のソースは、opengl の glBegin, glEnd を使ってチマチマと面の描画を指定してるのだけど。ググってたら OpenGL 3.0 以降は glBegin, glEnd は非推奨、てな話を見かけて。10年ぐらい前から、VBO を使え、ということになってるっぽい…。DirectX を使って描画する際もVBOのようなソレを使う、てな話を見かけたので、そういうやり方も勉強してみないと…。

そこまでできれば、DXRuby開発版の CustomRenderTarget を使って…とかできたりするのだろうか。どうなんだろう。

前述の記事によると OpenGL 1.1 で頂点配列を渡せるようになったらしいので、まずはそこから試してみたり。以下のようなソースになった。

_gosu_opengl_11.rb

ソース中で、UVグリッドのテクスチャ画像を使ってるけど、以下で公開されてる画像を使わせてもらったり。Public Domainらしいので安心して使えます。ありがたや。

_Arahnoid/UVChecker-map: A collection of free images what can be used during unwrapping of 3D models

ちなみに、他にもヨサゲなUVグリッド画像があったりしないかとWeb上で結構探してみたものの、えてしてどれもライセンスが CC-BY だったりして。サンプルソース等に同梱したい、てな時は CC-BY は不便ではないのかと思うのだけど…。その点、上記の画像群は実にありがたい。作者様にはひたすら感謝。

さておき。とりあえず、ソース中のポイントになる部分だけメモ。「Ruby + opengl ではこう書く」みたいなところだけでも伝わればいいかなと…。

頂点配列をそのまま渡して描画する例。glDrawArrays を使う。

  # 頂点配列を渡して三角形を描画する例
  def draw_triangle
    glEnableClientState(GL_VERTEX_ARRAY)  # 頂点配列を有効化
    glEnableClientState(GL_NORMAL_ARRAY)  # 法線配列を有効化

    # 頂点配列の指定
    glVertexPointer(
                    3,  # size. 1頂点に値をいくつ使うか。x,yなら2 x,y,zなら3
                    GL_FLOAT,    # 値の型
                    0,           # stride. データの間隔。詰まってるなら0
                    @vertexs_a   # 頂点データが入った配列
                    )

    # 法線配列の指定
    # 法線は1頂点につき必ずx,y,zの3値を持っているのでsize指定は不要
    glNormalPointer(
                    GL_FLOAT,    # 値の型
                    0,           # stride
                    @normals_a   # 法線データが入った配列
                    )

    # 頂点群を渡して描画. glDrawArrays を使う
    glDrawArrays(
                 GL_TRIANGLE_STRIP,  # プリミティブの種類
                 0,                  # スタート地点
                 3                   # 頂点数
                 )

    glDisableClientState(GL_VERTEX_ARRAY)  # 頂点配列を無効化
    glDisableClientState(GL_NORMAL_ARRAY)  # 法線配列を無効化
  end

頂点配列と、頂点インデックス番号の配列を渡して描画する例。glDrawElements を使う。

  # 頂点配列とインデックス配列を渡してcubeを描画する例
  def draw_cube
    glEnableClientState(GL_VERTEX_ARRAY)         # 頂点配列を有効化
    glEnableClientState(GL_NORMAL_ARRAY)         # 法線配列を有効化
    glEnableClientState(GL_TEXTURE_COORD_ARRAY)  # uv配列を有効化

    glVertexPointer(3, GL_FLOAT, 0, @vertexs_b)  # 頂点配列の指定
    glNormalPointer(GL_FLOAT, 0, @normals_b)     # 法線配列の指定
    glTexCoordPointer(2, GL_FLOAT, 0, @uvs_b)    # uv配列の指定

    glEnable(GL_TEXTURE_2D)            # テクスチャ有効化
    id = @texinfo.tex_name
    glBindTexture(GL_TEXTURE_2D, id)   # テクスチャ割り当て

    # インデックス配列を渡して描画. glDrawElements を使う
    glDrawElements(
                   GL_QUADS,           # プリミティブ種類
                   @indices_b.size,    # インデックス数
                   GL_UNSIGNED_SHORT,  # インデックスの型
                   @indices_b          # 頂点インデックスの配列
                   )

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

    # 頂点配列、法線配列、uv配列を無効化
    glDisableClientState(GL_VERTEX_ARRAY)
    glDisableClientState(GL_NORMAL_ARRAY)
    glDisableClientState(GL_TEXTURE_COORD_ARRAY)
  end

ところで。頂点インデックス配列、法線インデックス配列、uvインデックス配列を別々に渡せないっぽいあたりで首を捻ったり。

頂点を共有できれば扱うデータ数は少なくなるわけだけど…。頂点座標、法線ベクトル、uv座標の全てが他の頂点とピッタリ一致することってまず無いので、つまり各頂点が共有される場面なんてほとんどあり得なくて、結局はずらずらと重複値を並べていくことになるわけで。これじゃわざわざインデックスを使う意味ねえなと思いました。

いや、待て。自分の書いたソースは四角形で描画してるからそうなっちゃうのか。これがもし、全部三角形で描画するとなれば、一つの四角形を二つの三角形で表現することになるから、共有可能な頂点が結構出てくる、のかな。であれば、インデックスを使う意味があるか…。

前述の、頂点配列を渡して描画するやり方は、頂点データがメインメモリ上に載ってるので、ちと処理が遅いらしくて。

GPUが管理してるメモリ(VRAM？)上にそれらデータを置けたら処理を速くできるんじゃね？ そっちにデータを置いちゃおうぜ！ てのがVBO(Vertex Buffer Object)、らしいです。それが OpenGL 1.5 あたりから使えるようになった、と。

ということで、ソースは以下。

_gosu_opengl_15.rb

ポイントになるところをメモ。

    # VBOを作成

    # 頂点、法線、uv、インデックス用に、4つのバッファを生成
    @buffers = glGenBuffers(4)

    # 頂点群
    glBindBuffer(GL_ARRAY_BUFFER, @buffers[0])  # バッファの種類を設定
    vtx = @vtx_b.pack("f*")
    glBufferData(GL_ARRAY_BUFFER, vtx.size, vtx, GL_STATIC_DRAW)

    # 法線群
    glBindBuffer(GL_ARRAY_BUFFER, @buffers[1])
    nml = @nml_b.pack("f*")
    glBufferData(GL_ARRAY_BUFFER, nml.size, nml, GL_STATIC_DRAW)

    # uv群
    glBindBuffer(GL_ARRAY_BUFFER, @buffers[2])
    uv = @uvs_b.pack("f*")
    glBufferData(GL_ARRAY_BUFFER, uv.size, uv, GL_STATIC_DRAW)

    # インデックス群。他と違って GL_ELEMENT_ARRAY_BUFFER を指定してることに注意
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, @buffers[3])
    face = @face_b.pack("S*")
    glBufferData(GL_ELEMENT_ARRAY_BUFFER, face.size, face, GL_STATIC_DRAW)

• Ruby上では、配列を作って、ソレを pack して渡すことで VBO が作れるらしい。
• 頂点群、法線群、uv群は GL_ARRAY_BUFFER を指定するけど、インデックス群は他と違って GL_ELEMENT_ARRAY_BUFFER を指定する。
• VBOは毎フレーム作らなくてもいいらしい。初期化処理時に一度作って、毎フレーム使い回す模様。

ちなみに、2番目の、GL_ELEMENT_ARRAY_BUFFER を指定するあたりに気づかなくてハマりました…。

描画は以下のような感じ。

  # VBOを使ってcubeを描画
  def draw_cube
    # バッファのデータと関連付け
    glEnableClientState(GL_VERTEX_ARRAY)         # 頂点配列を有効化
    glEnableClientState(GL_NORMAL_ARRAY)         # 法線配列を有効化
    glEnableClientState(GL_TEXTURE_COORD_ARRAY)  # uv配列を有効化

    # 頂点配列を関連付け
    glBindBuffer(GL_ARRAY_BUFFER, @buffers[0])
    glVertexPointer(3, GL_FLOAT, 0, 0)

    # 法線配列を関連付け
    glBindBuffer(GL_ARRAY_BUFFER, @buffers[1])
    glNormalPointer(GL_FLOAT, 0, 0)

    # uv配列を関連付け
    glBindBuffer(GL_ARRAY_BUFFER, @buffers[2])
    glTexCoordPointer(2, GL_FLOAT, 0, 0)

    # インデックス配列を関連付け
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, @buffers[3])

    glEnable(GL_TEXTURE_2D)                          # テクスチャ有効化
    glBindTexture(GL_TEXTURE_2D, @texinfo.tex_name)  # テクスチャ割り当て

    # 描画
    glDrawElements(
                   GL_QUADS,              # プリミティブ種類
                   @face_b.size,          # インデックスの個数
                   GL_UNSIGNED_SHORT,     # インデックスの型
                   0                      # バッファオフセット
                   )

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

    # 頂点配列、法線配列、uv配列を無効化
    glDisableClientState(GL_VERTEX_ARRAY)
    glDisableClientState(GL_NORMAL_ARRAY)
    glDisableClientState(GL_TEXTURE_COORD_ARRAY)

    # バッファを削除
    # glDeleteBuffers(@buffers)
  end

「使い終わったらバッファを削除せよ」と、その手の説明ページには書いてあったのだけど。C++での書き方は載ってるものの、Ruby でどう書けばいいのかが分からなくて。こういう書き方でいいのだろうか…？

「使い終わったら」の意味もちょっと不明で。毎フレーム、描画が終わったタイミングで削除しないといかんのかなと試してみたら異常終了するようになってしまって。いや、次回のフレームでも描画に使うんだから当たり前だろうけど。「もう、このデータを使って描画する機会は今後無い」という状態ならバッファを削除せよ、という話なのかも。

_算譜記録帳: OpenGLでの頂点データの扱いの変化
_Ruby/Qt/OpenGL でバーテックスバッファーオブジェクトを使ってみる - tuedaの日記
_床井研究室 - 頂点配列
_床井研究室 - Vertex Buffer Object
_頂点配列
_（あかん） - おっさんプログラマの戯れ言

「CG」「ワイヤーアクション」等の単語が出てくるあたり、映画の時代設定はどう見ても現代、それも比較的近年の設定だろうけど。それにしては、登場人物の各職種に対する差別意識が昭和ノリで。

例えば、ベテランのスーツアクターさん、スタントマンさん、スタッフさんを一段下に見て馬鹿にしてる、売り出し中の若手イケメンアイドル俳優なんて今時居るかよと。お前は昭和かと。おじさんキャラならともかく、今の若者を馬鹿にし過ぎてないかと。しかも本人は ハリウッドで通用するアクション俳優になりたがってて、だけどベテランのスーツアクターさんを馬鹿にして話も聞こうとしないとか…。どう考えても夢と行動が矛盾してる。

いやまあ、嫌な感じのキャラを置いとかないとドラマが盛り上がらないのだ、こういうキャラを途中で浄化させると観客は喜ぶのだ、と判断してそうしたことは分かるのだけど。にしても、もうちょっとどうにか…。いくらファンタジー部分と言っても、コレはちと杜撰では。

スタントマンやスーツアクターという職種が、顔出し俳優への単なる通過地点、という捉え方を最初から終わりまで描いてたのもなんだか引っ掛かったり。ソレ、違くねえか…。と言っても、主人公を演じてる方にとってはまさしくそういう感じでやってたんだろうから、ある意味ではリアルと言えるのかもしれんけど、しかしやっぱりソレって昭和感覚じゃねえのかなあ、と…。

例えば、昔は「声優」という職種を恥ずべきものとして捉えて、「私は声優じゃない。役者だ」と主張してた方が居たけれど、今はそうじゃないわけで。特撮ヒーローモノも同様に…。いや、アニメと違って実写の世界は未だに昭和のままで止まってるのだろうか。どうなんだろう。

クライマックスのあたりも、ツッコミどころが多過ぎて。劇中のアクション監督が、 「CG無し、マット無し、ワイヤー無し、ワンカットで！」と無茶苦茶なことを言い出したから主人公が、という展開なのだけど。肝心の映画の映像が、 「CG合成をすることが前提のグリーンバックのセット」+ 「ワイヤーアクションで吹き飛ぶ斬られ役」+ 「殺陣のシーンはカット切替しまくり」なので、「コレ、主人公が演じる必然性が無かったのでは…」「 危険だからと演じることを拒否した本来の役者が演じても全然OKな状況では…」「この映像では、状況設定が全部台無しじゃん…」と、もやもや。

本編中で主人公が、「脚本は、自分が出るシーンだけを読むんじゃなくて、全部目を通して自分の役どころを掴まないとダメだぞ！」みたいなことをイケメンアイドル俳優に指導するシーンがあったけど。もしかして、この映画のクライマックスシーンを担当したアクション監督さんは、脚本全部に目を通していないのではという疑念すら。脚本上の台詞や姿勢を、この映画のスタッフは一丸となって全否定してるという、なんだかメタな状況が…。いや、もしかすると、わざとかな。一応脚本は全部読んだけど、「こんな馬鹿なこと言いだすアクション監督なんて居ねえよ！ なんだこの脚本！ アクションの現場を舐めてんのか！ ふざけんな！」と激しい怒りを感じて、わざとこういう映像にしたのかも…などと邪推してしまうほどにチグハグな作りで。

主人公の思想にも共感はできなくて。「子供に夢を見せるために」と言いながら自分の行動・選択を正当化してたけど、撮影現場で事故起こしてたら子供に夢を見せるどころじゃないわけで…。だから、事故を防ぐことは大前提で撮影に挑むのがプロ意識だろう、それでも時々事故は起きてしまうのだろうと想像するのだけど、生死が怪しくなるほどの無茶な要求に最初から無策で挑むのはどう考えてもNGで、お前は「子供に夢を」とか語る資格なんてねえ、プロじゃねえ、プロになってるつもりなだけのなんちゃって野郎だ、などと自分は思ってしまって萎えちゃったわけで。

とは言え、日本人は特攻大好き民族だから…。このほうがドラマとして盛り上がると判断して脚本を書いたのだろうな、てなあたりも分かってしまうし、しかも昭和の頃はとんでもないエピソードが実際に散らばってたりするので、ある意味リアルといえばリアルだったりして、「これはこれでいいのかなあ…。でも、こういう愚かしさを美化して見せてちゃダメだよなあ…バカ映画ならアリかなあ…にしてはバカ映画と分かるように作ってないんだよなあ…」などと悩んじゃうのですけど。うーん。

ちなみに、視聴後、脚本家さんのインタビュー記事をググって読んでみたら、ちゃんと取材して脚本を書いてたらしくて。つまり、本当は現状を知ってるけどドラマとして盛り上げるためにあえてこうしたとか、あるいは脚本として連名で名前が出てるプロデューサーが見るも無残な改変をしていったとか、そういうところかなと邪推したりもして。もしも前者であれば、まあ良し、という気もしてきたり。この手のソレは、リアル＋ファンタジーのバランスが肝要だったりするし、分かっててやってるなら…「このほうがウケるんだ」「こっちが正解だ」と自信を持ってやったなら、それはそれでOKだろうと。

てな感じで、もやもやもやもやしてしまったのだけど。しかし、スーツアクターさんが主人公と言う設定がレアだし、しかも演じてる人が昔実際に、てな点もメタだし、なんだか扱いに困るなと。企画の時点で「勝ったなガハハ」状態の映画というか。特撮ヒーローモノが好きな人間としては、この映画の存在を肯定せざるを得ない…。

ということで、「ツッコミどころは多いけど、その分しっかりお話を盛り上げる方向に舵を切ったのであろう映画だから、見ても損は無い、かもしれない」「ツッコミ入れまくって楽しむも良し。フツーに盛り上がって見るも良し。誰でも何かしら楽しめる部分が見つかるんじゃないかなあ」てな感じの映画、だったような気がしました。

もし、この映画が昭和の頃の時代設定なら、さほどもやもやしなかったような、そんな気もしてきたり。時代設定って大事なんだな…。

とは言え、本気で昭和を描こうとしたら、映像面では「三丁目の夕日」シリーズと張り合う覚悟が必要になりそうだけど、当然そんな予算も、技術のあるスタッフも確保できないし…。であれば、やはり現代を舞台にしつつ、しかし昭和感覚と平成感覚を分離することを意識した脚本を、とかなるのかな…。となると、おそらく世代衝突とか世代交代とかそういうアレも描けたりするのかしらん。どちらかを悪にするのではなくて、昔の良かったところ、悪かったところ、今の良いところ、悪いところの両面を描いていけば、などと妄想。

例えば、blender でこういうモデルデータを作成して、Wavefront(.obj)形式でエクスポート。


ちなみに、Wavefront形式は、三角形ポリゴンと四角形ポリゴンを混在できるのだけど…。後になってからRubyスクリプト側で、面配列(頂点インデックス配列)のみを眺めてそれぞれ三角ポリゴンか四角ポリゴンかを判別するのはおそらく不可能。故に、エクスポート時に「三角面化」にチェックを入れて、全てのポリゴンを三角ポリゴンにしちゃったほうがいいと思う。


tinywavefrontobj.rb を使って整形出力。

ruby tinywavefrontobj.rb sample.obj

こういう結果が得られる。

@vertexes = [
  1.0, -1.0, 0.0,  # 0
  -1.0, 1.0, 0.0,  # 1
  -1.0, -1.0, 0.0,  # 2
  1.0, 1.0, 0.0,  # 3
]

@normals = [
  0.0, 0.0, 1.0,  # 0
  0.0, 0.0, 1.0,  # 1
  0.0, 0.0, 1.0,  # 2
  0.0, 0.0, 1.0,  # 3
]

@faces = [
  0, 1, 2,  # 0
  0, 3, 1,  # 1
]

これをRubyソースに貼り付ければ実験に使えるだろうと。

json や yaml でも出力できる。

ruby tinywavefrontobj.rb sample.obj --json > sample.json

{"vertex":[1.0,-1.0,0.0,-1.0,1.0,0.0,-1.0,-1.0,0.0,1.0,1.0,0.0],"normal":[0.0,0.0,1.0,0.0,0.0,1.0,0.0,0.0,1.0,0.0,0.0,1.0],"face":[0,1,2,0,3,1]}

ruby tinywavefrontobj.rb sample.obj --yaml > sample.yml

---
vertex:
- 1.0
- -1.0
- 0.0
- -1.0
- 1.0
- 0.0
- -1.0
- -1.0
- 0.0
- 1.0
- 1.0
- 0.0
normal:
- 0.0
- 0.0
- 1.0
- 0.0
- 0.0
- 1.0
- 0.0
- 0.0
- 1.0
- 0.0
- 0.0
- 1.0
face:
- 0
- 1
- 2
- 0
- 3
- 1

Rubyスクリプト側で、例えば以下のような感じで書けば、jsonファイルを読み込んで、頂点配列、法線配列、uv配列、面配列(頂点インデックス配列)を得られる。

    require 'json'
    ...
    vertex_array = nil
    normal_array = nil
    uv_array     = nil
    face_array   = nil
    File.open("sample.json") { |file|
      hash = JSON.load(file)
      vertex_array = hash["vertex"]
      normal_array = hash["normal"] if hash.key?("normal")
      uv_array     = hash["uv"] if hash.key?("uv")
      face_array   = hash["face"]
    }
    ...
    if uv_array
      puts "use texture"
    end
    if normal_array
      puts "use normal"
    end

以下のように書けば、Rubyソース内から呼び出して使うこともできる。

    require_relative 'tinywavefrontobj'
    ...
    o = TinyWaveFrontObj.new("sample.obj", true, true)
    vertex_array = o.get_vertex_array
    normal_array = o.get_normal_array
    uv_array     = o.get_uv_array
    face_array   = o.get_face_array
    ...
    if o.use_uv
      puts "use texture"
    end
    
    if o.use_normal
      puts "use normal"
    end

まずは、三角形のみを描画してみる。

_gosu_opengl_20a.rb

こんな感じの結果画面に。

ポイントになる部分だけをメモ。

  # プログラマブルシェーダの初期化
  def init_shader
    # 頂点シェーダ(Vertex Shader)のソース
    # gl_position に (x, y, 0.0, 1.0) を渡してる
    vert_shader_src_a =<<EOS
#version 120
attribute vec2 coord2d;
void main(void) {
  gl_Position = vec4(coord2d, 0.0, 1.0);
}
EOS

    # フラグメントシェーダ(Fragment Shader)のソース
    # gl_FragColor に (r,g,b,a)=(0, 0, 1, 1) を渡してるので、青一色になる
    frag_shader_src =<<EOS
# #version 120
void main(void) {
  gl_FragColor = vec4(0.0, 0.0, 1.0, 1.0);
}
EOS

    # (r,g,b,a) の r,g をx,y座標で変化させるのでグラデーションになる
#     frag_shader_src =<<EOS
# #version 120
# void main(void) {
#   gl_FragColor[0] = gl_FragCoord.x / 640.0;
#   gl_FragColor[1] = gl_FragCoord.y / 480.0;
#   gl_FragColor[2] = 0.5;
#   gl_FragColor[3] = 1.0;
# }
# EOS

    # 頂点シェーダを設定
    # ----------------------------------------

    # 1. シェーダオブジェクトを作成
    vert_shader = glCreateShader(GL_VERTEX_SHADER)

    # 2. シェーダのソースを渡す
    glShaderSource(vert_shader, vert_shader_src_a)

    # 3. シェーダをコンパイル
    glCompileShader(vert_shader)

    # 4. 正しくコンパイルできたか確認
    compiled = glGetShaderiv(vert_shader, GL_COMPILE_STATUS)
    abort "Error : Compile error in vertex shader" if compiled == GL_FALSE

    # フラグメントシェーダを設定
    # ----------------------------------------

    # 1. シェーダオブジェクトを作成
    frag_shader = glCreateShader(GL_FRAGMENT_SHADER)

    # 2. シェーダのソースを渡す
    glShaderSource(frag_shader, frag_shader_src)

    # 3. シェーダをコンパイル
    glCompileShader(frag_shader)

    # 4. 正しくコンパイルできたか確認
    compiled = glGetShaderiv(frag_shader, GL_COMPILE_STATUS)
    abort "Error : Compile error in fragment shader" if compiled == GL_FALSE

    # 5. プログラムオブジェクトを作成
    @shader = glCreateProgram

    # 6. プログラムオブジェクトに対してシェーダオブジェクトを登録
    glAttachShader(@shader, vert_shader)
    glAttachShader(@shader, frag_shader)

    # 7. シェーダプログラムをリンク
    glLinkProgram(@shader)

    # 8. 正しくリンクできたか確認
    linked = glGetProgramiv(@shader, GL_LINK_STATUS)
    abort "Error : Linke error" if linked == GL_FALSE

    # 9. シェーダプログラムを適用
    glUseProgram(@shader)

    # 設定が終わったので後始末
    glDeleteShader(vert_shader)
    glDeleteShader(frag_shader)

    # シェーダに渡す属性のインデックス値(0,1,2,3等)を得る
    attr_name = "coord2d"
    @coord2d = glGetAttribLocation(@shader, attr_name)
    abort "Error : Could not bind attribute #{attr_name}" if @coord2d == -1
  end

OpenGL 2.0 でシェーダを用意する手順としては…。

1. シェーダオブジェクトを作成
2. シェーダのソースを渡す
3. シェーダをコンパイル
4. 正しくコンパイルできたか確認
5. プログラムオブジェクトを作成
6. プログラムオブジェクトに対してシェーダオブジェクトを登録
7. シェーダプログラムをリンク
8. 正しくリンクできたか確認
9. シェーダプログラムを適用

更に、1から4までは、頂点シェーダとフラグメントシェーダの2回分、処理を行うようで。

_DXRubyのShader と同様なのだけど、Ruby + OpenGL を使って実験する際、Rubyスクリプトのソース内に、シェーダプログラム(GLSL)のソースを直接ずらずらと書けるあたりはありがたいなと。気軽に実験できるというか。

正直なところ、シェーダをどんな風に書けばいいのかまだ全然分かってない状態なのだけど。以下の記事で参考として紹介されてるシェーダを使わせてもらって、もう少し複雑な描画を試してみたり。

_床井研究室 - 第1回 シェーダプログラムの読み込み
_床井研究室 - 第2回 Gouraud シェーディングと Phong シェーディング
_床井研究室 - 第3回 テクスチャの参照

Rubyスクリプトは、こんな感じに。

_gosu_opengl_20g_read_json.rb

• jsonファイルになってるモデルデータは、tinywavefrontobj.rb を使って用意した。
• 頂点シェーダのソースファイル(.vert)と、フラグメントシェーダのソースファイル(.frag)は、前述の参考記事内で紹介されてるものを利用させてもらって実験。

結果画面は、こんな感じに。



ということで、Ruby + gosu + opengl を使っても、OpenGL 2.0風の書き方はできるみたいだなと。

今回、マテリアル(材質設定)を一種類に決め打ちして描画したけれど。複数のマテリアルを使ったモデルデータを描画したい場合は、どういう書き方をすればいいのかなと…。

_glBegin と glEnd を使って描画した場合 は、処理が遅い代わりに、ポリゴン一枚ごとに材質設定をし直すこともできたので、複数のマテリアルを使っていても描画ができたけど。頂点インデックス配列を渡して一気に描画する場合は…。

もしかしてそのあたり、マテリアル毎に分割した頂点インデックス配列を用意して対応することになるのだろうか。それとも、「この面にはこのマテリアルを使う」てな指定も可能になる書き方があったりするのだろうか。マテリアル情報をVRAMに転送しておいて、マテリアルインデックス配列を渡して、みたいな。…そんなことできるのかな。

テクスチャを使ってる時と使ってない時で、違うシェーダを使って処理してるあたりも気になる。1つのシェーダでどちらにも対応できないものか…。

_Ruby/Qt/OpenGL で GLSL を使ってみる - tuedaの日記
_床井研究室 - 第1回 シェーダプログラムの読み込み
_床井研究室 - 第2回 Gouraud シェーディングと Phong シェーディング
_床井研究室 - 第3回 テクスチャの参照
_算譜記録帳: OpenGLでの頂点データの扱いの変化
_OpenGLプログラミング - Wikibooks
_OpenGLプログラミング/モダンOpenGL イントロダクション - Wikibooks
_OpenGLプログラミング/モダンOpenGL チュートリアル 02 - Wikibooks
_OpenGLプログラミング/モダンOpenGL チュートリアル 03 - Wikibooks
_GLSL編01 - OpenGL de プログラミング

先日作成した tinywavefrontobj.rb を使って、Wavefront形式(.obj)の3Dモデルデータファイルを、実験用モデルデータへと変換出力しようとしたのだけど。

調べてみたら OpenGL と DirectX は座標系からして違うようで。OpenGLは +z が手前だけど、DirectX は +z が奥らしい。なので、OpenGL用に書いた件のスクリプトは、そのままでは使えなくて。

_OpenGLの座標系

また、現状の CustomRenderTarget、というか VertexBuffer は、頂点インデックス配列を使わないらしい。DXRuby開発版の readme.txt にはそのように書いてある、ように見えた。

■４-7. VertexBufferクラス

(中略) このバージョンではIndexBufferは用意されていません。

ということで、tinywavefrontobj.rb に、いくつかオプションを追加して、DXRubyから使えるデータにも変換できるように修正。

_mieki256/tinywavefrontobj

とりあえずだけど、DXRuby で使えるデータを出力したいなら、--no-index --zflip --color --hexcolor オプションをつければなんとかなる、かなと…。

ruby tinywavefrontobj.rb sample.obj --no-index --zflip --color --hexcolor --json > sample.json

オプションの効果は以下。

• --no-index : 頂点インデックス配列をつけない。
• --zflip : z値を反転。OpenGLとDirectXはz軸の向きが逆、らしいので。
• --color : 頂点カラー配列も出力する。とりあえず、Wavefront形式(.obj)ファイル内の、マテリアル(材質設定)のdiffuse色を、頂点カラーとして代用。
• --hexcolor : 色を 0xAARRGGBB の形で出力。

jsonファイルにしておけば、Rubyスクリプト側では以下のように書いて読み込める。

require 'json'

...

vertex_array = nil
normal_array = nil
uv_array     = nil
color_array  = nil

File.open("sample.json") { |file|
  hash = JSON.load(file)
  vertex_array = hash["vertex"]  # 頂点配列
  normal_array = hash["normal"]  # 法線配列
  uv_array     = hash["uv"]      # uv配列
  color_array  = hash["color"]   # 頂点カラー配列
}

ところで、色の並びは 0xAARRGGBB でいいのかしらん。DirectX はそのへんどうなってるのかググってもよく分からなかったのだけど、0xRRGGBBAA とか 0xAABBGGRR もあるのだろうか…。

_RubyのMatrixクラス の中に look_at() なんてメソッドは見当たらないのに、サンプルは動いているぞ、どういうことだ？ などと悩んでしまったりして。

コレ、DXRuby開発版自体に、Matrix という名前のクラスが含まれていたのですな…。考えてみたら、DXRubyのサンプル側では require 'matrix' が書かれていないから、Ruby標準添付ライブラリの Matrix じゃなくて DXRuby が持ってる Matrix が使われるのだな…。

_3度目のVectorとMatrix - mirichiの日記
_[Ruby][DXRuby] DXRuby ユーザのための 標準添付ライブラリの紹介（前編） - あおたくノート

DXRuby側の Matrix はゲーム用に特化したものらしい、とメモ。更に、Ruby標準添付ライブラリには、 _Vectorクラス もあるのですな。これも DXRuby側で独自のクラスを持っている、と…。

しかし、たしかにコレ、ちとハマりそうな気がする…。クラス名をビミョーに変える等は難しいのだろうか…。いや、難しいからこうなってるのだろうけど。

_DXRuby1.5.21dev - mirichiの日記
_CustomRenderTarget - mirichiの日記
_CustomRenderTargetその２ - mirichiの日記
_CustomRenderTargetその3 - mirichiの日記
_CustomRenderTargetその4 - mirichiの日記

DXRuby作者様の解説記事、助かりました。ありがたや。

jsonファイルを解析して頂点配列等を取得するのと、.obj + .mtlファイルを解析して頂点配列等を取得するのでは、どちらがいいのだろう…。

例えば、RubyのjsonライブラリがCで書かれてたりするなら、一旦jsonにしておいて、jsonを読み込んだほうが処理時間も速いのだろうけど。

もっとも、パース(=解析)にかかる処理時間を気にするなら…。jsonになった時点で、もはや中身を眺めて修正したり等はほとんど不可能な状態になるのだから、いっそのことバイナリで保存したり読み込んだりするほうがいいのかな、とも思えてきたり。でも、エディタで開いて一応は内容が見れるテキストファイルと、何が何だか分からない謎バイナリでは、前者のほうが気分的に楽かな…。

テキストで記述されていて、かつ、頂点カラーを記録できる3Dモデルフォーマットは無いのかなとググってるところ。

ここ数日使っている Wavefront形式は、テキストで記述されてるので解析しやすいものの、頂点カラーについては記録できないみたいで。いや、アプリによっては頂点情報に頂点カラーまで付加してしまうものもあるらしいのだけど…。

そもそも blender上で頂点カラーを指定するのって、どんな操作をすればいいんだろう。ソレ以前に、blenderは、頂点カラーを使える機能があるのだろうか。

仮に blender がそういう機能を持ってないとしても、Wings3Dあたりではどうだろう。Wings3Dは、ゲーム向けのローポリモデルを作成しやすい、という話を見かけたから、頂点カラーも指定できそうな。

今のところテクスチャを使ってるモデルしか描画できないので、テクスチャを使ってないモデル、及び、複数のマテリアル(材質設定)も描画できるようにしたいのだけど、さて、どうすればいいのやら。シェーダを数種類用意して対応するのが妥当なのだろうか。それとも違う方法があるのだろうか…。

ピクセルシェーダ内の計算も、これで合ってるのかどうか…。意味も分からずコピペしただけなので…。 _グーローシェーディング(Gouraud shading) とか _フォンシェーディング(Phong shading) とか勉強しないと、なのかな…。

検索してみたら、 _2007/11/05 に買った製品だったらしい。ダイニチ FW-322S とメモしてあった。

当時の店頭では9,980円で売られてたのか…。すると、今は製品価格が1.5倍に値上がりしてるんだな…。と思ったが、ググってみたら、9,980円前後で売ってるお店もあるな…。今回店頭で見かけた製品は、何かしらランクの高い製品だったのだろうか。

親父さん曰く、「1階の奥の部屋に置いてある古いファンヒーターはほとんど使ってないので、ひとまずソレを使え」とのことで。助かった。

自室まで運んで動作確認。フツーに動いてくれた。

CORONA GT-3240、と書いてあるな…。 _道燃整組 コロナ年度表一覧 によると、1991年の製品らしい。…えっ？ 1991年？ 大丈夫かコレ。

コロナ製品は、一部にリコール対象製品があるようで。「手を汚さずに開け閉めできますぜ」てのが売りだったタンクの蓋部分に問題があるらしい。

_コロナ石油ストーブ 油タンク確認不足で火災の恐れ - リコール情報のお知らせ - ヤフオク!
_CORONA Information web
_recallpapaer.pdf
_株式会社コロナが製造した石油ストーブのリコールが行われます(無料点検・部品交換)(METI/経済産業省)

幸い、型番リストの中に GT-3240 は入ってなかった。古過ぎて、タンクの蓋が昔ながらの金属製なので、リコールにはならなかった模様。

3Dモデルデータを記述するフォーマットは他にも色々あるようで。

_3Dファイルフォーマットの種類 - PukiWiki for PBCG Lab

試しにblender上から、DirectX(.x)形式でエクスポートしてみた。出力時のオプションの中に、「Export Vertex Colors」という項目があるので、そこにチェックを入れて出力すると頂点カラー配列も含めて出力してくれる。.xファイルはテキスト形式とバイナリ形式があるらしいけど、blender はテキスト形式で出力してくれる模様。助かった。

しかし…。.xファイルの中身を初めて眺めてみたけど、ちょっと難解だな…。いやまあ、形状データだけなら、どこに何の情報が書かれてるか分かりやすいほうだけど。

FBX形式(.fbx)でエクスポートしてみた。出力時のオプション項目としてテキスト出力とバイナリ出力が選べる。テキスト出力されたソレを眺めたら、ギャッ。これはまだ .x を相手にするほうが現実的かもしれず。

.plyファイルでエクスポートしてみた。コレもテキストファイルっぽい。…ああ、コレは分かりやすい。各頂点毎に、x,y,z、法線ベクトル, u,v, 頂点カラー R,G,B が列挙されて、最後に頂点インデックスが並んでる。ただ、マテリアル(材質設定)情報は含まれてないのだな…。どのテクスチャ画像を使うか、等の情報すら含まれてない。実物を計測してポリゴン群にする際に使うことが多いフォーマットらしいので、表面の材質や反射等は気にする必要無し、そんなの撮影・計測状況でいくらでも変わっちゃうし、ということかな…。

_COLLADA形式(.dae) でエクスポートしてみた。コレもテキストファイルになってる。元々プレステ3やPSP用に考えられたフォーマットらしいので、ゲーム向けのデータが網羅されてるように見えた。

.x3dファイルでエクスポートしてみた。これもテキストファイル。VRMLの後継ファイル、と紹介されてるけど、中身がxmlになってるのはそのせいだろうか。

例えばだけど。 _2015/09/09の日記 でアップロードした、ベルトスクロールアクションゲームのステージ開始時に、「STAGE 1」「FIGHT」てな大きいロゴがドーンと表示されたりするのだけど。大きく表示された際にロゴの輪郭がぼやけるのが嫌だったので、結構巨大な画像をそのまんま持ってたりして、そこがなんだかちょっとアレだなと思ってたわけで。

もし、こういう場面で、ポリゴン＋グラデーションを使えれば、巨大画像を持たなくても描画ができるのではないかと。そのためには、頂点カラーを指定してグラデーションを表示できたりするとありがたい。

ということで、モデルデータに対して頂点カラーを指定して、ソレをRubyスクリプト側に渡す方法はないかな、と思ってたりするのです。

いやまあ、ロゴ画像のデータをわざわざ3DCGツールで作るってのもどうなんだと思わないでもないけど、使えそうな道具は使ってしまえ、みたいなノリで。

昔、GitHub は、「メディアファイルはDropboxあたりにでも置けよ」「ウチはソースコードをアップする場所だぞ」てなことを言ってたのだけど。

当時の自分は、その主張を真に受けて、Dropbox にいくつかのファイルをアップしていたものだから、今頃になって面倒なことに…。スクリーンショット等の画像ファイルが見れなくなってる…。

_Repositories - mieki256 - GitHub

気が付いた範囲でリンク等を修正してみたけれど、どこかしら見逃してそうな…。

とりあえず、頂点を選択して、パレット上の色をクリックするだけで、その頂点に色を割り当てることができた。ただし、Matrialの設定で、Vertex Colors を「Set」もしくは「Multiply」にしておかないとダメ。



例えば Cube を新規作成した状態なら、デフォルトで Cube全体に、「default」という名前のマテリアルが割り当てられてる。アウトライナーウインドウで、その「default」を右クリックして「マテリアル編集」を選べば、Vertex Colors の指定を変えられるはず。

マテリアルの Vertex Colors は、テクスチャが貼ってない状態なら「Set」でOK。ただし、テクスチャが貼ってある状態なら、「Multiply」にしておかないと、テクスチャと頂点カラーの両方が反映されないらしい。

テクスチャの貼り方は、以下の記事が参考になりました。ありがたや。

_操作に慣れる9 Wings 3D: おじさんのCG日記
_操作に慣れる10 Wings 3D: おじさんのCG日記
_操作に慣れる11 Wings 3D: おじさんのCG日記

しかし、Wings 3D 2.1.5 では、UVマップを作る際に辺で分けていく操作がよく分からず。昔の版では、別に開くウインドウ上で辺選択モードも選べたらしいけど、面選択モードにしかならない…。まあ、右クリックメニュー → セグメント化する → 自動セグメント化、で、ある程度分けてくれるようではあるけれど。

む。辺選択と面選択の両方が使える時があるような。メインウインドウ側の、辺選択、面選択ボタンの状態で、何が選択できるのか違ってくるらしい。辺選択モードにして辺を選択したら、右クリックメニューを出して手動で分割する辺を指定することができた。

_Wings3D Misc Memo によると、アンビエントオクルージョンの結果を頂点カラーに反映させることもできるらしい。Tools → アンビエントオクルージョン、で適用される。

「アンビエントオクルージョンってなんや？」…以下の記事が参考になりそう。

_アンビエントオクルージョン・はじめの一歩 - アンビエントオクルージョンちゃん

試してみたら、たしかにそれっぽくなった。


ただ、テクスチャ画像への反映のさせ方が分からん…。

DirectX(.x)ファイルでエクスポートしてみたけど、中身を眺めて若干困惑。blenderからエクスポートされた .xファイルとは、色々違うな…。

例えば、「Mesh」のあたり。Wings 3D は、こんな感じ。

Frame Cube1 {
    Mesh {
        36;
        -0.5, -0.5, -0.5;,
        -0.5, -0.5, 0.5;,
        -0.5, 0.5, -0.5;,

blender は、こんな感じ。

    Mesh { // Cube mesh
      36;
      -0.500000;-0.500000; 0.500000;,
      -0.500000; 0.500000;-0.500000;,
      -0.500000;-0.500000;-0.500000;,

各数値の区切り文字からして違う…。

また、blenderからエクスポートした .xファイルには、

      MeshVertexColors { // Cube vertex colors
        36;
        0; 0.619608; 1.000000; 0.000000; 1.000000;;,
        1; 0.000000; 0.031373; 1.000000; 1.000000;;,
        2; 0.619608; 1.000000; 0.000000; 1.000000;;,

てな感じで、おそらく頂点カラー情報が含まれているけど。Wings 3D 2.1.5 or 1.5.4 からエクスポートした .xファイルには、頂点カラー情報が含まれていないように見えた。

blender からエクスポートする際、デフォルトでは「Export Vertex Colors」のチェックが外れているので、ひょっとすると標準的な .xファイルは頂点カラー情報を含まないもの、とされているのだろうか。でも、Wings 3D から .xファイルでエクスポートする際も、「頂点カラーの書き出し」というオプションがあるんだよな…。わざわざオプションが用意されていてチェックを入れてるのに出てこないということは単にバグなのか、それとも何かの仕様と絡んでいてコレで正解なのだろうか…。

考えてみれば、頂点カラーについてはテクスチャ画像側であらかじめその色にしておくことで、ある程度代用できそうな気もするし…。

実際、Wings 3Dは、例えばアンビエントオクルージョンの結果を頂点カラーに反映させつつも、ソレをテクスチャに焼き込む(?)ことで陰影があるように見せる、てなやり方を前提にしているっぽいし。

このあたり、わざわざ頂点カラーをモデルデータに持たせなくていいよ、テクスチャに焼いとけよ、てなノリがフツーなのだろうか…。どうなんだろう。でも、頂点カラーを指定できたほうが、同じテクスチャを使っていても見た目を色々と変化させられるよな…。リソース節約を考えたら対応してるほうが…。

昔のVRMLは .wrlフォーマットなるものを使っていたらしい。テキストファイル形式。Wings 3D にも .wrl のエクスポータが同梱されてるので、試しに .wrl でエクスポートしてみた。

.wrl なら、頂点カラー情報が含まれていた。が、しかし、今度はテクスチャのUV情報が含まれてない…。出力時のオプションに「UV情報を書きだす」というチェックボックスが用意されているのに、出力してみると含まれていない…。

一体どうなってるんだ。Wings 3D。

まさか Wings 3Dは、テクスチャのUV情報と頂点カラー情報についてエクスポート時に排他になるのでは。と予想して頂点カラーのみ指定したモデルを .x でエクスポートしてみたけど、やっぱり頂点カラーは含まれてなかった。

その後も諦めきれずにググってたけど…。

_Wings 3D .X Exporter - SEWiki

Note: Vertex colors are not supported and must be converted to materials before exporting, or else they won't show up.

Wings 3D .X Exporter - SEWiki より

「.x のエクスポータは頂点カラーをサポートしてないよん」と明言されてた。やっぱりそうか…。

_Wings 3D .X Export Plugin :: Spaceempires.net

As for vertex colors, I'm not sure if DirectX even supports those; it seems to support only assigning colors on a per-face basis, not per-vertex. But you should be able to convert your vertex colors to a UV-mapped texture inside of Wings with a few commands... I think it's "convert vertex colors to materials" then "UV mapping" then do your mapping then "create texture"... then once I get the textures to export you can just do that procedure when you're finished with a model.

Wings 3D .X Export Plugin :: Spaceempires.net より

2005年頃のやり取りだけど、「DirectXって頂点カラーをサポートしてねえだろ」「面単位でしか色をつけられねえよ」「似たようなことしたければテクスチャに焼けや」と言ってる、のかな。つまり「対応する気はねえ」「これが仕様だ」と…。

_.x形式 は、DirectX10 からサポート外になったらしいし…。 _DirectX - Wikipedia を眺めると、2002年にDirectX9、2006年にDirectX10が公開されたらしいから…。

もしかすると、Wings 3D の .xエクスポータは2005年頃に作られたものの、直後に .xフォーマットがサポート外になってしまって改良するモチベを失って、当時の仕様のまま放置、だったりするのかな。他の3DCGソフトとの連携用途や、DirectX の標準機能以外での使い道までは考えてなかったのかもしれない。

Wings 3D 側で、頂点カラーを含めて出力してくれる何かしらのフォーマットでエクスポートして、ソレをblenderでインポートして .x でエクスポート、とかやればなんとかなるだろうか…。

ていうか、Wings 3D のファイルを直接インポートできないのかな。と思ってググってたら。

_Wings3d import plugin for Blender 2.57
_kayosiii/blender_io_scene_wings: Wings3d import and export plugins for Blender

コレは！ と思ったものの、blender 2.78 ではエラーが出ちゃってインストールできず。残念。

まあ、頂点カラーやUV情報を無視すれば、 _.obj にしてインポートできるという話 も見かけたし…。

_Import Wings 3D files to Blender?

英語圏のフォーラムでも、「いくらなんでもどれかしらのフォーマットでいけるやろ」ということになってるっぽい。

COLLADA形式(.dae) で試したら、一応頂点カラーも含めて blender にインポートできたように見えたけど。Wings 3D関係のどこかのフォーラムで「.dae のエクスポータがちゃんと動いてねえ」という話も見かけたような…。

頂点カラーに絞って調べた範囲では、だけど。Wings 3Dは、エクスポータがどれもボロボロな印象。あくまで頂点座標群のみを作るツール、と思っておいたほうがいいのかもしれない。

テクスチャを貼ったり、頂点カラーを指定したり等のお化粧は blender に持っていってからやるべき、かもしれず。いや、Wings 3D でやってもいいけど、他のソフトに持っていった際に何かしらの情報が失われて作業が二度手間になる予感。

xismo はどうだろうと少し触ってみたけど、頂点カラー機能はついてないらしい。

今のところ、blender と Wings 3D しか頂点カラー機能を持ってるソフトが見つからず。しかも Wings 3D は頂点カラー情報をほとんどエクスポートできないという。

なるほど、「頂点カラーなんて使わねえだろ」とエクスポータの作者様が言っちゃうのも分かる。周りを見渡すとサポートしてないソフトばかりだもんな…。いや、調べてないけど、たぶん値段の高いソフトなら対応してるんだろう。要はプロ向けの機能だから、フリーソフトでサポートする意味が見出せない、みたいなところがあるのかもと邪推。

自分が高校生だった頃、Intel 8085の載ったワンボードマイコンを使って4bit程度のPCM録音再生実験をしながら、「PCMが一般に普及するのはまだまだ先だろうなあ」「メモリ高いもんなあ」「コスト的に折り合わないよな」と感じてたわけで。

ところが、CDという、デジタルデータをメモリ以外の何かに比較的安く記録できる媒体が出てきて、PCM再生なんて当たり前になってしまったわけで。大学生の頃にはCDを買ったりレンタルしてたわけだから、たった数年で未来がやってきたというか。そして今では、皆が当たり前のように、PCM録音再生ができる機器を持ち歩いてるわけで。 *1

デジタルTV放送だって、MPEG-2を使ってるから映像が汚いけど…。今はMPEG-4で圧縮展開が実用レベルになってる、というかブルーレイでもネット配信でも普及してるから、今なら使わない手はないわけで。MPEG-1すらビデオカードの支援機能を使わないとPC上では再生が厳しいね、なんて時代も昔はあったけど…。その頃にMPEG-4的な処理はどうかと口走っても「そんなの使い物になるわけねえだろ」「処理が重すぎるわ。絵に描いた餅だわ」「お前馬鹿じゃねえの」と言われただろうなと。

つまり、現状では使い物にならないけど、未来のハードウェア上では実用になる、実用になるハードウェアが作られる展開っていくらでもあるよなと。

なので、この手のソレって、「現状ではアレだけどこれからの発展に期待」ぐらいに思っておいたほうがいいのだろう、などと反省を。今は使えなくても、未来ではどうなってるか分からない。コンピュータ関係、デジタル関係は、特にそういう世界だし。

そういや大学生の頃、64bit CPU だか 128bit CPU だかが載ったPCが今後出現するかしないかで喧嘩してた場面を目撃した記憶も…。「出ない」側は、重い処理は専用チップを用意して担当するのが妥当だからCPU自体はそれほど発展する必要がない、故に ○○bit CPUは出てこない、と主張してて、それもそれで一理あると自分は思ってしまったっけ…。まさかCPUで扱えるビット数が増えた上に専用チップ相当まで全部ツッコんでくる展開になるとは…。

未来って、予測がつかない…。

_Blender Addon List: Addon: Uv Squares 1.4
_Radivarig/UvSquares: Blender addon for reshaping UV selection into grid.
_[Addon] UvSquares v1.4 (updated - any shape supported)

UV頂点を水平 or 垂直に整列したり、正方形に整形してくれるアドオン。今現在は 1.5.0 が最新版、なのかな。

UV画像エディターウインドウ上で、Tキーを押すと左側にツールウインドウが開くけど。Miscタブの中に UV Squares という項目があるので、そこでボタンを押せば使える。

• Alt + E に「To Grid By Shape」が割り当てられているので、横一列でUV頂点を選択して Alt + E を押せば水平に並ぶし、縦一列でUV頂点を選択して Alt + E を押せば垂直に並ぶ。
• Alt + V に「Rip faces」が割り当てられてるので、面になるようにUV頂点を選択しておいて Alt + V を押せば選択部分だけが別のUV頂点群になる。直後にGキー(移動のショートカットキー)を押して別の場所に移動させたりできる。
• 「Snap with Equal Distance」ボタン : 選択されてるUV頂点群が等間隔になるように整形。
• 「To Square Grid」ボタン : 選択されてるUV頂点群が正方形になるように整形。

自分が実験用モデルデータを作る際は、ポリゴンとグリッドテクスチャ画像をきっちり対応させることが多いので、このアドオンはとても便利。ありがたや。

_Blender Addon List: Addon: Quad Unwrap

歪んだ形で展開されたUVを、グリッド状に整形してくれるアドオン。

UV画像エディターウインドウ上でスペースキーを押して「Quad Unwrap」と打ち込むとコマンドが表示されるので、ソレを選ぶと実行できる。

UV Squares と、機能が被ってる…？

_Blender Addon List: Addon: UV/ Image Tools
_[Addon] UV/ Image Tools

UV頂点群を綺麗に配置し直す時に便利な機能をアレコレ追加するアドオン。最新版は 1.0.7、でいいのだろうか。blender上では「UV Tools」というアドオン名で表示されてるな…。

UV画像エディターウインドウ上でTキーを押して左側にツールウインドウを出して、ツールタブの中の UV Tools を使う。

例えば、何かUV頂点を一つ選択して、Slection → リンク、をクリックすれば、その頂点から繋がってる部分を選択してくれる。

また、配置を変える際に形状を変えたくないUV頂点群があったら、UV頂点を選択後、Editing → ピン止め をクリックして、「この頂点群は形を変えるんじゃねえぞ」的に指定することができる。ピン止めされた頂点には赤い点が表示される。ピン止めを外したい時は、Editing → UnPin。

辺を選択して、Editing → Stitch をクリックすると、「この辺とこっちのUV頂点群は綺麗に並べることができるんじゃないかなあ」的に予測が表示される。もう一度 Stitch をクリックすると、「あ、この予測通りでいいのね」と、配置を変えてくれる。途中でキャンセルしたい時は ESCキー。

Island → Mark Seams をクリックすれば、UV画像エディタ上で選択されてる辺を使って3Dビュー上のモデルにシーム(UV展開する時の切れ目相当)をつけることもできる。

他にも色々。

• Transform 内のボタン一つで、左右反転、上下反転、180度回転、左90度回転、右90度回転ができる。
• Align で、グリッド上に配置したり、左揃え、中央揃え、右揃え、上揃え、下揃え、等間隔配置、等々ができる。

コレも一部、UV Squares と機能が被ってる気もするけど。つまりそれだけ需要があるんだろうな…。

_Blender Addon List: Addon: Simple Box UVW Map Modifier
_[Addon] Simple Box UVW Map Modifier

モデルに対してざっくりとテクスチャを貼りつけていくことができるアドオン。最新版は 0.5、かな。

動画を見ないと機能が分からない気がする…。

_Sure UVW Map Addon for Blender (Box and Best Planar) - YouTube

仮でサクサクとテクスチャを貼っていきたい時は便利そう。

_Blender Addon List: Addon: Move UV

3Dビュー上からUV座標を変更することを可能にするアドオン。テクスチャの貼られ方を目視で確認しつつ作業できるので、UV座標の微調整時は快適に作業ができそう。

Alt + G にショートカットキーが割り当てられているので…。

1. ざっくりとUV指定をしておく。
2. 3Dビュー上で頂点を選択。
3. Alt + G を押す。
4. マウスを動かしてUV座標を調整。
5. 右クリックで決定。

という作業の流れになる。

ちなみに、このスクリプトファイルはそのままDLできないみたいなので…。ローカルに move_uv.py てなファイルを新規作成して、ソースをコピー＆ペーストして保存。そのファイルをインストールした。

> irb
irb(main):001:0> require 'rexml/document'
=> true

irb(main):002:0> doc = REXML::Document.new(File.read("vtxcoltest01.dae"))
=> <UNDEFINED> ... </>

irb(main):003:0> mesh = doc.elements["COLLADA/library_geometries/geometry/mesh"]
=> <mesh> ... </>

irb(main):004:0> puts mesh.elements["polylist"]
<polylist count='12' material='Material_001-material'>
          <input offset='0' semantic='VERTEX' source='#Cube-mesh-vertices'/>
          <input offset='1' semantic='NORMAL' source='#Cube-mesh-normals'/>
          <input offset='2' semantic='TEXCOORD' set='0' source='#Cube-mesh-map-0'/>
          <input offset='3' semantic='COLOR' set='0' source='#Cube-mesh-colors-Col'/>
          <vcount>3 3 3 3 3 3 3 3 3 3 3 3 </vcount>
          <p>1 0 0 0 2 0 1 1 0 0 2 2 3 1 3 3 6 1 4 4 2 1 5 5 7 2 6 6 4 2 7 7 6 2 8 8 5 3 9 9 0 3 10 10 4 3 11 11 6 4 12 12 0 4 13 13 2 4 14 14 3 5 15 15 5 5 16 16 7 5 17 17 1 0 18 18 3 0 19 19 2 0 20 20 3 1 21 21 7 1 22 22 6 1 23 23 7 2 24 24 5 2 25 25 4 2 26 26 5 3 27 27 1 3 28 28 0 3 29 29 6 4 30 30 4 4 31 31 0 4 32 32 3 5 33 33 1 5 34 34 5 5 35 35</p>
        </polylist>
=> nil

irb(main):008:0> puts mesh.elements["polylist"].attributes["count"]
12
=> nil

irb(main):009:0> plst = mesh.elements["polylist"]
=> <polylist material='Material_001-material' count='12'> ... </>

irb(main):010:0> plst.elements.each("input") {|d| puts d}
<input offset='0' semantic='VERTEX' source='#Cube-mesh-vertices'/>
<input offset='1' semantic='NORMAL' source='#Cube-mesh-normals'/>
<input offset='2' semantic='TEXCOORD' set='0' source='#Cube-mesh-map-0'/>
<input offset='3' semantic='COLOR' set='0' source='#Cube-mesh-colors-Col'/>
=> [<input semantic='VERTEX' source='#Cube-mesh-vertices' offset='0'/>, <input semantic='NORMAL' source='#Cube-mesh-normals' offset='1'/>, <input semantic='TEXCOORD' source='#Cube-mesh-map-0' offset='2' set='0'/>, <input semantic='COLOR' source='#Cube-mesh-colors-Col' offset='3' set='0'/>]

OpenGL的には、COLLADA形式の後継相当の、glTF(openGL Transmission Format) なるフォーマットもあるらしい。xmlを解析しなくても済むように、というか実機(?)上で比較的そのまま使えるように改良されたフォーマット、だそうで。

_今話題の3Dファイル形式「glTF」でWebGLの表現力を高めよう！ - Qiita
_glTF を触ってみた | shikihuiku
_COLLADAワーキンググループの次のプロジェクトとしてglTFプロジェクトがスタート - 強火で進め

blenderからglTFでエクスポートするアドオンも存在している模様。

_Kupoman/blendergltf: A glTF exporter for Blender

試しに、blender 2.78 にインストールして使ってみた。エクスポートすると、.gltf と .bin の2つのファイルが出力された。.gltf は .json(テキスト形式)の模様。バイナリファイル .bin の中にどんな情報が列挙されているかが .gltf 側で記述されているっぽい。

pタグは、頂点インデックス群だけど…。

例えば、polylist の中に input が4つあって、頂点座標(VERTEX)、法線ベクトル(NORMAL)、UV座標(TEXCOORD)、頂点カラー(COLOR) の順で並んでたら…。

p タグの中は、

頂点インデックス, 法線インデックス, UVインデックス, 頂点カラーインデックス,  // 頂点0
頂点インデックス, 法線インデックス, UVインデックス, 頂点カラーインデックス,  // 頂点1
頂点インデックス, 法線インデックス, UVインデックス, 頂点カラーインデックス,  // 頂点2
...

てな感じでインデックス値がずらずらと列挙されることになる。

例えば vcount が、「3 3」だったら「三角形が2つありますよ」ということだから、pタグの中は…。

頂点インデックス, 法線インデックス, UVインデックス, 頂点カラーインデックス,  // 頂点0
頂点インデックス, 法線インデックス, UVインデックス, 頂点カラーインデックス,  // 頂点1
頂点インデックス, 法線インデックス, UVインデックス, 頂点カラーインデックス,  // 頂点2

頂点インデックス, 法線インデックス, UVインデックス, 頂点カラーインデックス,  // 頂点3
頂点インデックス, 法線インデックス, UVインデックス, 頂点カラーインデックス,  // 頂点4
頂点インデックス, 法線インデックス, UVインデックス, 頂点カラーインデックス,  // 頂点5

こうなるんじゃないかなと…。4 x 3 x 2 = 計24個の値が並ぶ、みたいな。

  gl_FrontColor = gl_Color;

  gl_FragColor = gl_Color * tcolor
    * (gl_LightSource[0].diffuse * gl_FrontMaterial.diffuse * diffuse
       + gl_LightSource[0].ambient * gl_FrontMaterial.ambient)
    + gl_LightSource[0].specular * gl_FrontMaterial.specular * specular;

なんというか、OpenGL の勉強をしてると、少々もやもやしてくる。「OpenGLは○○の機能を持っているのか」「機能を持っているとしたら、どう書けば使えるのか」てなあたりをググって調べるだけで随分と時間がかかってるような。自分の脳内で処理の流れを考えるソレとは異質な作業というか。

プログラミングって、自分が使おうとしてる言語なりライブラリなりの機能や書き方を把握する段階と、どんな処理をさせればやりたことが実現できるのか悩む段階の2つがあるわけだけど。前者で時間が奪われるのがツライ。どうせ「誰かが作った○○の使い方」を学習しなきゃいけないなら、もっとリターンが大きい何か、例えば Unity 等の使い方でも勉強したほうがよほど実があるんじゃないか…。と思ったり思わなかったり。

テクスチャが貼ってあるモデルデータを .dae でエクスポートしたところ、マテリアル情報のあたりで、ちと問題が。

例えば、blender からエクスポートした .dae の場合、diffuse には RGBA を記述してくれるけど。

  <diffuse>
    <color sid="diffuse">0.8 0.72 0.64 1</color>
  </diffuse>

Wings 3D からエクスポートした .dae は、(テクスチャを使ってた場合)diffuse に以下のような記述が入るので RGBA を取得できない。

  <diffuse>
    <texture texcoord="CHANNEL1" texture="uvchecker512_png-sampler"/>
  </diffuse>

まあ、「テクスチャ画像がRGBAを持ってるんだからそれをdiffuseとして使えや」ってことだろうけど。

どうやら Wings 3D上のマテリアル設定で指定された diffuse 値は、エクスポートした .dae 内に含めてくれない模様。どこにもそれらしい情報が無い…。

ただ、テクスチャを貼らない場合は blender と同様に出力してくれる模様。

対処としては…。colorタグの有無を調べて、もし無ければ、diffuse を RGBA = 1.0, 1.0, 1.0, 1.0 にでもしておく、みたいな感じだろうか。

座標系の扱いも、ちと悩む。

• blender は、右が +X、上が +Z、前が -Y。.dae には「Z_UP」の記述が入る。
• Wings 3D は、右が +X、上が +Y、前が +Z。.dae には「Y_UP」の記述が入る。

   +Z              +Y
    |  +Y           |
    |  /            |
    | /             |
    |/              |
    +------ +X      +------ +X
                   /
                  /
                 /
               +Z
    blender         Wings 3D

まあ、これは blender が変わっていて、Wings 3D のほうが素直なのだけど。

blender がエクスポートした座標値やベクトルを DXRuby (DirectX) から使う場合、z と y を交換すればいいのかな…。Wings 3D の場合は、追加でz値の反転も必要になる、のかな。DirectX は、前が -Z らしいので。

更に、OpenGL から使う場合、DXRuby で扱う座標値やベクトルとは、zの向きを逆にしないと…。OpenGL は、前が +Z なので。

   +Y              +Y
    |  +Z           |
    |  /            |
    | /             |
    |/              |
    +------ +X      +------ +X
                   /
                  /
                 /
               +Z
    DirectX        OpenGL

blender は、daeエクスポート時のオプション項目に「三角形化」があるのだけど、Wings 3D のエクスポータには無い。故に、Wings 3D では、元々のモデルデータを「テッセレート」→「三角ポリゴン化」してからエクスポートしないといけない。

元のモデルデータを三角ポリゴンだらけに変換してしまうと、後から修正するのが面倒な状態に…。一々別名保存してバックアップを取ってから作業することになるのだろうか。

Wings 3D上の、ハードエッジ、ソフトエッジの指定が、エクスポートした .dae には反映されてないことに気づいた。滑らかに見えるように自動スムージングをかけると、全てのポリゴンがスムージング表示になってしまう。全部フラットにするか、全部スムーズにするか、二択なのか…。

なんとなくだけど、Wings 3D ってエクスポータが癌になってる気がしないでもない。かなり機能豊富なモデリングソフトなのに、エクスポータがバグってたり仕様が足りてなくて、他のソフトと連携しづらい点が痛いというか、実にもったいない。

いっそ Wings 3D ファイル形式がテキスト形式だったら、まだコンバータを作ってどうにか、等もあったのかもしれんけど、どうやらバイナリファイルっぽいし…。しかも Wings 3D は Erlang で書かれてるあたりが…。

なんだか世界が閉じてる印象を受けるソフトだなと。オープンソースなのに、変な話だけど。

xyzzy なら罫線モードという機能がある。ツール(T) → 罫線モード(R) を選べば、Ctrl + 矢印キーで線が描ける。Ctrl + Shift + 矢印キーで消去。

_xyzzy - emacs like editor in windows
_xyzzy 関連

ただ、この罫線モード、水平線、垂直線、四角を書くことにしか対応してない。

emacs なら、picture-mode という機能がある。手元の NTEmacs 24.5.1 でも動作した。

• M-x picture-mode あるいは M-x edit-picture でモードに入れる。
• C-c C-c でモード終了。

_GNU Emacs Manual(Japanese Translation): Picture Mode
_Emacs で図を描く - Higepon’s blog
_Meadow/Emacs memo: 表・図・画像などの表示・作成

例えば C-SPC で矩形範囲のマークを設定して、C-c C-r を叩けば四角が描かれる…のだけど。

    +-----------------+
    |                 |
+--------+     +--------------------+
|   |    |     |      |             |
|   |    |     |      |             |
|   |    |     |      |             |
|   +----|-----|------+             |
|        |     |                    |
+--------+     +--------------------+

このキー割り当てはどこで設定してあるのだか。手元の環境で M-x describe-bindings をしたらそういう割り当てになってたんだけど…。

C-c . や C-c ^ 等を叩くとカーソルの移動方向が固定されるので、後は描画したい文字を入力していけばいい。

+------------+------------+---------------+
| C-c `      | C-c ^      | C-c '         |
|  or        |  or        |  or           |
| C-c Home   | C-c Up     | C-c PageUp    |
+------------+------------+---------------+
|            |            |               |
|            |  `  ^  '   |               |
|            |   ` | '    |               |
| C-c <      |    `|'     | C-c >         |
|  or        | <---+--->  |  or           |
| C-c Left   |    /|\     | C-c Right     |
|            |   / | \    |               |
|            |  /  .  \   |               |
|            |            |               |
+------------+------------+---------------+
| C-c /      | C-c .      | C-c \         |
|  or        |  or        |  or           |
| C-c End    | C-c Down   | C-c PageDown  |
+------------+------------+---------------+

英語フォントなら _バックスラッシュ が「/」の左右反転で表示されるので、ちゃんと斜め線も表現できるけど。日本語フォントを表示してる環境では「\」になっちゃう点がなんだかアレではあるなと…。でもまあ、 _歴史的経緯 があるので仕方ない。

_日本語文字コード問題: 円記号とバックスラッシュを区別して入力したい - Windows編

なかなか面倒臭い。

設定によっては、picture-mode を使う際に勝手にタブ文字が入力されて表示がずれる時があるかもしれない。そんな時は、タブ文字を空白文字で置き換える機能を有効にする。

M-x set-variable RET
indent-tabs-mode RET
nil

M-x set-variable で変数の値を変更できる。変数 indent-tabs-mode に nil を設定してやると、タブ文字が空白文字で置き換わる状態になる。この設定は、設定したバッファのみで有効。

emacs の artist-mode を使えば、マウスを使って絵を描くこともできる。

• M-x artist-mode でモードになる。
• C-c C-c でモード終了。

手元の NTEmacs 24.5.1 では、以下のような割り当てになっていた。

• 左ボタンを押してマウスを動かすと描画。
• 右ボタンを押してマウスを動かすと消しゴム。
• Shift + 右ボタンで、線になる感じで描画。
• 中ボタンで、モード切替メニュー。四角を描いたり塗り潰したり等のモードをメニューから選べる。

                                                                         ...
                            .                                              ..
                           ..            .       ..                         ..
         ...      .        .             ..      . ..                        ..
      ....      ...        .            . ..    ..   .                        .
    ...  ....   .          ...          .  .  ...........                     .             ..
   ..  ..       .          .....        .  .... .       .......      ..       .              .
 ...  ..        .     ............      .   .. . ...........  ....   ...     .               .
 .    .         .    .. ..        ...   .    .....       .....   .... ...    .               .
.  ....         .   .   .  .......  ... .    ...           .....    ... ..   ......          .
. .. .           ....  .....     ..    ..             .....  .....    .  .. ..    ..        .
. . ..        . ....   . .        ..                ...   ...     .....    ..   .  ..      ..
..  .         .... ..  . .      .....               .  ...  .         .     .  .    ..     .
..  ..       ..  ... ... .     ...  .               .. ..   .                 ...     .    .
     .       .     .....       . . ..                ........                 . .     .    ..
      ..    ..      ....       .....                   .....                . ...   ...     ..
       ..   ...     .  ..       ..      .                    .              .     ...     .....
        ..  . ..    .   ..             ..                  ........        ........        .....
         .....  ..  .    .           ...                     ..  .         .                .  ..
            ..   .  ..   .           ....                                 ..                 ...
                 ..  ..  .              .                                ...  ......           ..
                  .   ....                                             ..   ...  . ...          ....
                  .      .                                           ...     ..  .   ..            ...
                  .    . ...         ...           ..              ...         ...   ....            ...
                  .    ..  ..          ............              ...            ..      .....          ...
                  .    . .  ....                               ....             ..        ..........     .
                  .    .  ..   ....                          ... ..            ..          .       .. .......
                  ..   .   ..      .....                ....... ..           ..           .                 ...
                   ..  .    ..         ....         ..... .......          ...            .                   ..
                    .....    ...          ..........   ........          ...              .
                       ..      ....               ..     ...            ..                .
                                  .....          ..      .                                .
                                                ..       .
                                                .

なんとか描けないでもない。

Vim に DrawIt というプラグインを追加すると、線や四角を描けるようになるらしい。

_Vimエディタで線を描画する - 名無しのvim使い
_scripts/26 - VimWiki
_vim + drawit + ditaa でテキストダイアグラムを画像に - Engineer in garage

手元の環境、Windows10 x64 + Kaoriya版 gvim 8.0.134 に導入して試したところ動作した。emacs の picture-mode と違って事前に空間を作っておく必要があるけれど、xyzzy の罫線モードっぽいノリで描けるのはイイ感じ。Home、End、PageUp、PageDown でいきなり斜め線が描けるのもグッド。

文字を使って絵が描ける専用ソフトを使う。

_JavE - Java Ascii Versatile Editor

あるいはWebサービスを利用する手も。

_ASCIIFlow Infinity
_Asciiflow - ASCII Flow Diagram Tool

せっかくだから、各エディタの機能を使って図を描くソレをキャプチャしてみたり。



こんなノリで描けるようですよ、と。

ただ、vimの操作がちょっと怪しいけど…。\dsi → Ctrl+V → 矩形選択 → \b や \e で四角や円が描けるはずなのだけど、カーソルが妙なところに飛んでいってしまう…。

Windows の場合、vimインストールフォルダに入ってる vimrc と gvimrc を、_vimrc と _gvimrc のファイル名でコピーして編集すればいいらしい。

一応試したところ .vimrc、.gvimrc というファイル名でも反映してくれたけど、他の vim が設定ファイルを読みにいってしまう可能性もあるなと気づいて。_vimrc、_gvimrc のままにしておこう…。

と思ったが、MSYS版 vim.exe も _vimrc を読みにいってしまう…。どうしたもんか。

~/.vimrc_first.vim と ~/.gvimrc_first.vim を作成して、そちらに設定を記述することにした。それぞれ存在していれば、_vimrc、_gvimrc が読みにいく。_vimrc は修正しなくても ~/.vimrc_first.vim を読みにいってくれるけど、_gvimrc は一部を修正しないと ~/.gvimrc_first.vim を読みにいかないので注意。

Kaoriya版 vim と MSYS版 vim のどちらで動いてるのかを判別する方法って無いのかな？ それができれば、一つの .vimrc で済みそうだけど。

_vim-jp >> Hack #115: Vimのバージョンや拡張機能をチェックする
_.vimrcに書くべきでないVimの設定項目 (Vim Advent Calendar 2012, 165日目) - 余白の書きなぐり

OSやvimのバージョンを判別することはできるらしいけど…。

neobundle というプラグインを使うと各プラグインのインストールが楽になるらしいので使ってみたり。

_Windowsでgvimを使う(neobundleのインストール) - .logbook
_Windows で GVim 環境の構築 - xykの日記

ここまではすんなり設定できて動いたけれど。たしか今は、後継の _dein.vim というプラグインがあったはず、と思い出して。ググってみたら、dein.vim は Windows上でも使えるらしい。

_Shougo/dein.vim: Dark powered Vim/Neovim plugin manager
_NeoBundle から dein.vim に乗り換えた - Qiita
_dein.vimのインストール自体にハマってしまったメモ - Qiita
_NeoBundle から dein.vim に乗り換えたら爆速だった話 - Qiita

_vimrc あるいは ~/.vimrc_first.vim に以下を書いたら動いてくれた。この例では、~/.cache/dein/ をdein関係の保存先に設定してる。

" ----------------------------------------
" dein Scripts

if &compatible
  set nocompatible
endif

" dein path
let s:dein_dir = expand('~/.cache/dein')
let s:dein_repo_dir = s:dein_dir . '/repos/github.com/Shougo/dein.vim'

" install dein.vim if not found
if &runtimepath !~# '/dein.vim'
  if !isdirectory(s:dein_repo_dir)
    execute '!git clone https://github.com/Shougo/dein.vim' s:dein_repo_dir
  endif
  set runtimepath+=~/.cache/dein/repos/github.com/Shougo/dein.vim
endif

if dein#load_state(s:dein_dir)
  call dein#begin(s:dein_dir)

  call dein#add(s:dein_repo_dir)
  call dein#add('Shougo/neocomplete.vim')
  call dein#add('Shougo/neocomplcache')
  call dein#add('Shougo/neosnippet.vim')
  call dein#add('Shougo/neosnippet-snippets')
  call dein#add('Shougo/unite.vim')
  call dein#add('itchyny/lightline.vim')
  call dein#add('Drawit')

  call dein#end()
  call dein#save_state()
endif

filetype plugin indent on
syntax enable

" If you want to install not installed plugins on startup.
if dein#check_install()
  call dein#install()
endif

この記述だと、最初の起動時に dein.vim が見つからない場合、git clone を使ってdein本体を自動でDLしてくれる。もちろん git がインストールされていて、DOS窓？ コマンドライン？ から使えるようになってることが前提。

プラグインの追加は、 call dein#add('hogehoge') を増やしていけばできるらしい。別ファイルで追加プラグインを指定する方法もあるらしいけど、そちらはよく分かってない。

デフォルトでは MSゴシックが使われるようなので、Rictyフォントに変更。_gvimrc を修正。

_プログラミング用フォント Ricty を gvim で使う
_Gvimでフォントの表示が欠けないようにする方法 - cd01 の blog

更に、vim 8.0 の Windows版は DirectWrite なる機能が使えるので、フォントを少し綺麗に表示することができるらしい。そのあたりも設定。

_Windows の Vim でフォントを綺麗に表示する方法 | RANDOM.SOFT
_Vimのrenderoptionsオプション - ウェブログ - Hail2u.net
_renderoptions の設定のしかた - KaoriYa
_VimのDirectWriteの設定方法 - KaoriYa

colorscheme なるものを変更すると見た目の色設定を変えられるらしい。_gvimrc で設定。ただ、WebからDLしてきた *.vim をどこに置けば反映されるのか分からず。

_vimエディタのプラグインファイルの置き場所を変更する - 名無しのvim使い

~/vimfiles/colors/ というフォルダを作成して、そこに入れてやれば良かったのか…。

以下を参考にして _gvimrc に設定。

_vim-jp >> Hack #120: gVim でウィンドウの位置とサイズを記憶する

デフォルトで UTF-8 にするために set encoding=utf-8 と _vimrc に書いたら、gvim のメニューが文字化け。以下を参考に修正。

_Windows GVimのメニューが文字化けした場合の解決方法
_【gvim】メニュー部分の文字化け - うみやま亭

ファイルを編集してると、 *.~un なるファイルが作られるようになってしまった。undo用のファイルらしい。以下を参考にして、特定の場所にまとめるように設定。

_Vimが変なファイルを作るようになった - KaoriYa
_WindowsでVimが勝手に作成する4つのファイルを作成されないようにするには。 - システムオペレータの週末

普段使ってるファイラー、あふからファイルを渡して起動すると、ファイル毎に別々の gvim が起動してしまう。多重起動しないようにしたい。

_GVIM をコマンドラインから起動する時、多重起動しない ＋行番号指定 - Qiita
_gvim の起動パラメーター - Numb.
_たびろぐテクニカル gVim導入
_Windows版のgvimをタブエディタ化する | WEBサービス創造記
_gVim をタブエディタ風にする！ - mk-mode BLOG

コマンドラインオプションで、--remote-silent や --remote-tab-silent を追加してやればいいらしい。ひとまず今回はタブ表示をしたかったので、--remote-tab-silent を指定。

タブの切り替えは、gt または gT と叩けばいいらしい。

ネット経由で拡張機能を追加インストールする仕組みは、今はあらゆるアプリ・言語・OSが導入してるので今更ではあるのだけど。例えば Perl の CPAN、Ruby の Rubygems、Python の pip、Debian や Ubuntu の apt、等々…。

しかし、それぞれ、今回の xyzzy のような状況になった時はどうなるのだろうと気になってしまったり。メインとなるサイトが落ちたり消えたりしても、その後もなんとか使えなくもない状態にするには、どういう形でそれら情報を提供したほうがいいのか、てなことをぼんやり考えてしまったりもして。

Wikiのようなシステムがどこかのサーバで動いてhtmlをブラウザその他に渡す、みたいなソレで提供するのは、今回のような状態になるから危ないのかもしれないなと。ミラーを作りやすい形で提供するほうが望ましい、とすれば、それこそ xyzzy の netinstaller の packages.l のように、テキストファイルを一つWeb上のどこかに置いておけばそれでどうにか、みたいな感じが良かったりするのだろうか。packages.l のURLをまとめた packages.l 的な何か、みたいな。

もっとも xyzzy の場合、他のアプリのソレと違って各拡張が個々のサイトで公開されてるので、例えば niftyのホームページサービスが終了したことで入手できなくなった拡張もあるし、その前は infoseek、isweb のサービス終了で消えてしまったページもあるし…。それを考えると、どこかで一元管理されてるほうが、という気もするけどその一元管理するサイトが落ちたら何も入手できなくなるという問題も。

このあたり、どういう仕組みがベターなのかなあ…。全てがキッチリと足並みをそろえてなくてもなんとかなる状態をキッチリ決める、みたいな妙な矛盾が…。

考えてみれば、今時は Atomエディタだの Visual Studio Code だのがあるし。xyzzy に限らず、emacs系エディタをあえて選択する必要は…。Ctrl + C、Ctrl + V でコピペできないあたりからして初心者にとっては厳しいだろうし。いやまあ、ソレを言ったら emacs系に限らず vim もアレだけど。起動直後は文字を入力できないエディタってなんだソレ、と思われそうな。

それはともかく。 _Emacsは衰退しました - Qiita を読むと、emacs も危ない雰囲気が。いや、 _謹賀新年！Emacsは衰退しません という話もあるけれど。

0.5秒が5秒ぐらいに遅くなるのは許せねえ云々、という話が出てるけど…。しかし自分の手元の環境では NTEmacs が起動するまで23秒かかってるから、今更…。ちなみに、Atomエディタが起動するまで、測ってみたら48秒かかった…。拡張を入れ過ぎなのだろうか…。そして Visual Studio Code は起動まで28秒だった。HDDなので仕方ない…。

xyzzyの起動は3秒。この軽さ故に使い続けてるわけですが。

当時、自分はこのアニメをちゃんと見てなかったのだけど。いや、一応ロボットが出てくるから毎週見てはいたけれど、ドラマ部分は全然…。

今になって思えば、現実世界では時代的に校内暴力云々等に怯えながら生活していたわけで、そのうえアニメの中でまで殴る蹴るのシーンなんか見たくもないよなと…。精神的な逃げ場がどこにも無くなってしまう。追い込まれてる子供達を更に追い詰めるんだから、このアニメの監督さん、鬼ですな。

ちなみに自分、このZガンダムで受けてしまった嫌な感じの印象を、ZZからVまでずっと引き摺ってしまって…。未だに逆シャアとか「ケッ」「どうせあのガンダムシリーズだろ」てな印象が…。いや、ロボット出てるから見ますけど…。

それもあって、雰囲気をガラリと変えてくれたGガンダムが好きなんですよね…。いやまあ、アレも殴ったり殴られたりのアニメというか殴る蹴るに関しては他のガンダム作品の追随を許さないレベルだったりするけれど、殴る蹴るの種類が違うというか。

考えてみたら、視聴者側が持ってるであろう攻撃性や暴力性の部分は、ロボットの戦闘シーンで充足されているような気もしてきたり。だとすれば、ドラマ部分まで攻撃性や暴力性は要らないよな…。唐辛子にタバスコかけてるようなもんだよな…。

が、しかし、だったらドラマ部分はほんわかさせよう、などと企むと、主人公が学園に通いながらアレコレしつつも、しかしロボットに乗ったらハードな展開が、的な、なんだかどこか歪んでる、いかにもアニメ的な設定の作品に…。いや、でも、そういうアニメのほうが売れてるみたいだし、それもまた正解の一つ、なのかなあ。

Zガンダムには、そういう気持ち悪さがないあたり、ある意味では、まだまだ健全さがあったのかもしれないなと。一貫してギスギス、最初から終わりまで殺伐。芯が通ってる、とは言えるのかも。

最近の emacs は、 M-x package-list-packages をするとネット経由で拡張がインストールできたりするのだけど。Uキーを押して、アップデートできそうな拡張に全部マークをつけて、xキーを押して実行・アップデートしてみたら、その後動作が怪しくなって困ったり。

症状としては、Rubyスクリプトを書く際にスペースキーを1回押すと空白が2つ入ってしまったり、ファイルを修正後に C-x C-s を叩いても何故か保存できずに「ファイル名は？」と尋ねられたり。

~/.emacs の中身を色々書き換えて犯人を探してみたら、悪さをしていたのはこのあたりだった…。

(require 'ruby-electric)
(add-hook 'ruby-mode-hook '(lambda () (ruby-electric-mode t)))

ググってみたら、ruby-electric は emacs 24.x 以降で動作が怪しいとのことで。

_Emacs24 で ruby-electric的なruby-modeを実現するには: invisible colors, inherent shapes and impassible emotion

ruby-electric は使わずに、ruby-end.el をインストールしつつ、括弧等の補完は emacs24.x 以降で使える新機能で対応、という手があるらしい。試してみたところ、余分なスペースも入らないし、ファイル保存もできるようになった。

ただ、「|v|」と打ちたい時に、「|」だけ打てば「||」に補完してくれないのはちょっとアレだけど。この文字は括弧じゃないから判別と補完が難しいのだろうな…。今までは ruby-electric が頑張っていたということだろうか。

にしても、上記ページは 2012年頃の記事だし…。今もダメなんだろうか。いやまあ、手元の環境では実際こうしてダメになったのだから、今でもダメなんだろうけど。

_qoobaa/ruby-electric: Improved ruby-electric mode を眺めたら、「このリポジトリはもうメンテナンスしてねえよ」「でもMELPAで扱ってるのは Ruby SVN のソレだよ」と書いてあった。

_[Home] Ruby Mode によると、 _[ruby] Index of /trunk/misc が、その Ruby SVN リポジトリらしい。ruby-electric の最後の更新は2年前、ということかな…。

そもそも ruby-mode.el もどれが最新なのか分からない。NTEmacsのインストールフォルダ内を眺めたら、標準で ruby-mode.el が入ってたけど、これは古いのか新しいのか。

ruby-mode 以外はどこから入手するのがいいのだろう。などと思いながら M-x package-list-packages で ruby-additional.el をインストールしてみたら、rdoc-mode.el、ruby-style.el、rubydb2x.el、rubydb3x.el も一緒に入ってた。また、inf-ruby.el も M-x package-list-packages でインストールできるらしい。

つまり、ruby-additional と inf-ruby をインストールすれば、ひとまずファイルは揃うはず、ということだろうか。しかし、それぞれの中身は、新しいのか古いのか…。中身を見ても、そもそもヘッダー部分からして全然違っていたりして、バージョンすら判別できず。途中で別の方がごっそり書き直したとかそういうアレかな…。

でもまあ、emacs に標準で ruby-mode が入ってるだけでも御の字、かもしれん…。

emacs上でタブバーを表示してくれる tabbar てのがあるのだけど、ファイル編集した際のタブ表示が反映されなくて悩んだり。

tabbar.el を眺めたら分かってきた。tabbar-selected-modified と tabbar-modified があるのね…。両方設定してやらないといかんのだな…。

とりあえず、~/.emacs 内では現状こんな感じに。

;; ----------------------------------------
;; tabbar - バッファの上部にタブを表示
;;
;; M-Left、M-Right   タブ間を移動
;; home、S-home      タブ間を移動
;; C-TAB、C-S-TAB    タブ間を移動

(require 'tabbar)
(tabbar-mode)

;; (require 'cl)
;; (load "~/.emacs.d/elisp/tabbar_init")

(tabbar-mwheel-mode nil)  ;; タブ上でマウスホイール無効
(setq tabbar-buffer-groups-function nil)  ;; グループ化無効
(setq tabbar-auto-scroll-flag t)  ;; タブを自動スクロール
(setq tabbar-use-images nil)  ;; 画像を使わない

;; 左に表示されるボタンを無効化
(dolist (btn '(tabbar-buffer-home-button
               tabbar-scroll-left-button
               tabbar-scroll-right-button))
  (set btn (cons (cons "" nil)
                 (cons "" nil))))


;; scratch 以外で先頭に「*」がついてるタブを表示しない
(setq tabbar-buffer-list-function
      (lambda ()
        (remove-if
         (lambda(buffer)
           (unless (string= (buffer-name buffer) "*scratch*")
             (find (aref (buffer-name buffer) 0) " *")))
         (buffer-list))))

;; 外観変更

;; タブセパレータの長さ
(setq tabbar-separator '(0.4))

(set-face-attribute
 'tabbar-default nil
 :family (face-attribute 'default :family)
 :foreground "#cccccc"
 :background "#666666"
 :height 1.0)

;; タブセパレータの見た目
(set-face-attribute
 'tabbar-separator nil
 :foreground "#222222"
 :background "#666666")

;; 非選択・未変更タブ
(set-face-attribute
 'tabbar-unselected nil
 :foreground "#333333"
 :background "#bbbbbb"
 :weight 'medium
 :box nil)

;; 非選択・変更タブ
(set-face-attribute
 'tabbar-modified nil
 :foreground "red"
 :background "#bbbbbb"
 :weight 'medium
 :box nil)

;; 選択・未変更タブ
(set-face-attribute
 'tabbar-selected nil
 :foreground "blue"
 :background "#eeeeee"
 :weight 'bold
 :box nil)

;; 選択・変更タブ
(set-face-attribute
 'tabbar-selected-modified nil
 :foreground "red"
 :background "#eeeeee"
 :weight 'bold
 :box nil)

(set-face-attribute
 'tabbar-button nil
 :box nil)

;; (set-face-attribute 'tabbar-default nil :background "brightblue" :foreground "white")
;; (set-face-attribute 'tabbar-selected nil :background "#ff5f00" :foreground "brightwhite" :box nil)
;; (set-face-attribute 'tabbar-modified nil :background "brightred" :foreground "brightwhite" :box nil)

;; 編集されたらタブのラベルに記号を追加
;; Add a buffer modification state indicator in the tab label, and place a
;; space around the label to make it looks less crowd.
(defadvice tabbar-buffer-tab-label (after fixup_tab_label_space_and_flag activate)
  (setq ad-return-value
        (if (and (buffer-modified-p (tabbar-tab-value tab))
                 (buffer-file-name (tabbar-tab-value tab)))
            (concat " * " (concat ad-return-value " "))
          (concat " " (concat ad-return-value " ")))))

;; 編集されるたびにタブのラベルを更新
;; Called each time the modification state of the buffer changed.
(defun ztl-modification-state-change ()
  (tabbar-set-template tabbar-current-tabset nil)
  (tabbar-display-update))

;; First-change-hook is called BEFORE the change is made.
(defun ztl-on-buffer-modification ()
  (set-buffer-modified-p t)
  (ztl-modification-state-change))
(add-hook 'after-save-hook 'ztl-modification-state-change)

;; This doesn't work for revert, I don't know.
;;(add-hook 'after-revert-hook 'ztl-modification-state-change)
(add-hook 'first-change-hook 'ztl-on-buffer-modification)

(dolist (func '(tabbar-mode tabbar-forward-tab tabbar-forward-group tabbar-backward-tab tabbar-backward-group))
  (autoload func "tabbar" "Tabs at the top of buffers and easy control-tab navigation"))

(defmacro defun-prefix-alt (name on-no-prefix on-prefix &optional do-always)
  `(defun ,name (arg)
     (interactive "P")
     ,do-always
     (if (equal nil arg)
         ,on-no-prefix
       ,on-prefix)))

(defun-prefix-alt shk-tabbar-next (tabbar-forward-tab) (tabbar-forward-group) (tabbar-mode 1))
(defun-prefix-alt shk-tabbar-prev (tabbar-backward-tab) (tabbar-backward-group) (tabbar-mode 1))

;; キー割り当て
(global-set-key [M-right] 'shk-tabbar-next)
(global-set-key [M-left] 'shk-tabbar-prev)
(global-set-key [(control tab)] 'shk-tabbar-next)
(global-set-key [(control shift tab)] 'shk-tabbar-prev)
(define-key global-map [home] 'shk-tabbar-next)
(define-key global-map [\S-home] 'shk-tabbar-prev)

見た目はこんな感じ。

昔手動で yasnippet をインストールしたのだけど、ネット経由で最新版が入れられるのだからそっちを入れようと思い立って。手動で入れてた関連ファイルを別の場所に移動して M-x package-list-packages でインストール。自分用のスニペットは ~/.emacs.d/snippets/ にコピー。

emacs の起動がとんでもなく速くなった。20秒以上かかっていたのが、数秒で立ち上がる。今まで訳も分からずインストールしていた古いアレコレが、無駄に時間を食っていたのか…。

_Emacs picture-modeの拡張 - 屯遁のパズルとプログラミングの日記 で、picture-mode を強化する elisp が披露されてた。試しに導入。

xyzzy の罫線モードと同様に、C-カーソルキーでいきなり縦横の線が引けるようになった。これはたしかに快適。

ただ、C-c C-カーソルキーでリージョンを移動できるはずが、それについては動作せず。ひとまず、C-M-カーソルキーに割り当てたら動いたけど…。

  (define-key picture-mode-map [C-M-right] 'picture-region-move-right)
  (define-key picture-mode-map [C-M-left]  'picture-region-move-left)
  (define-key picture-mode-map [C-M-up]    'picture-region-move-up)
  (define-key picture-mode-map [C-M-down]  'picture-region-move-down)

しかし、どうして動かなかったのかよく分からず。emacsのバージョンによって記述の仕方が変わるのだろうか。

む。分かった。tabbar が C-c C-right 等のショートカットキーを取ってしまっているのだな…。

tabbar側のキーの殺し方は、こんな感じだろうか。

(define-key tabbar-mode-map [(control ?c) C-right] nil)  ;; tabbar-forward
(define-key tabbar-mode-map [(control ?c) C-left]  nil)  ;; tabbar-backward
(define-key tabbar-mode-map [(control ?c) C-up]    nil)  ;; tabbar-backward-group
(define-key tabbar-mode-map [(control ?c) C-down]  nil)  ;; tabbar-forward-group

ちなみに自分の場合、C-tab、C-S-tab、Home、S-Home にタブの切り替えを割り当ててあるので殺しても困らない、とメモ。

_ダウンロード ページから、Fujiyama-Renderer-for-Win-0.3.3-x64.zip と、サンプルデータの all_ply.tar.gz をDLして解凍。更に加えて、 _High-Resolution Light Probe Image Gallery からIBLに使うのであろうHDR画像を入手。とりあえず以下をDLさせてもらったり。

glacier.hdr
grace-new.hdr
pisa.hdr
uffizi-large.hdr

以下のようなフォルダ構成にして各ファイルをコピー。

./Fujiyama
 ├─Fujiyama-Renderer
 │  ├─bin      プログラム群が入っている
 │  ├─include
 │  ├─lib
 │  ├─python
 │  └─scenes   サンプルシーンファイルが入っている
 │
 ├─hdr          HDR画像を入れておく
 │
 ├─mesh         plyから変換した.meshファイルを入れておく
 │
 ├─mip          HDR画像から変換した .mipファイルを入れておく
 │
 └─ply          サンプル ply ファイルを入れておく。

環境変数を設定。

• 環境変数 PATH に、〜\Fujiyama-Renderer\bin を追加。
• 環境変数 PYTHONPATH に、〜\Fujiyama-Renderer\python を追加。

要するに、DOS窓から 〜\Fujiyama-Renderer\bin\ 以下のプログラムにアクセスできるように、かつ、pythonから 〜\Fujiyama-Renderer\python\ 内のファイルを呼べるようにパスを通しておく。

自分の場合、以下のようなbatファイルを作って、使う時だけ環境変数を設定するようにしてみたり。

set FUJIYAMA_ROOT=D:\Prog\Fujiyama\Fujiyama-Renderer
set PATH=%PATH%;%FUJIYAMA_ROOT%\bin
set PYTHONPATH=%PYTHONPATH%;%FUJIYAMA_ROOT%\python
echo add %FUJIYAMA_ROOT% to PATH and PYTHONPATH

plyファイルは3Dファイルフォーマットの一種だけど、コレを .mesh ファイルに変換しないといけないらしい。bin\ にパスが通っていれば、DOS窓上で以下を打って変換できる。

ply2mesh teapot.ply ..\mesh\teapot.mesh
ply2mesh floor.ply ..\mesh\floor.mesh
ply2mesh dome.ply ..\mesh\dome.mesh
ply2mesh xyzrgb_dragon.ply ..\mesh\xyzrgb_dragon.mesh

xyzrgb_dragon.ply は結構巨大なファイルっぽいので変換に時間がかかる。

Fujiyama-Renderer\scene\ 以下にサンプルシーンファイル(.scn)が入っているのだけど、各シーンファイル内では ../../mesh/*.mesh を呼び出してるので、.meshファイルは meshフォルダに入れておく。

HDR画像も、.mipファイルに変換しておく。

hdr2mip glacier.hdr ..\mip\glacier.mip
hdr2mip grace-new.hdr ..\mip\grace-new.mip
hdr2mip pisa.hdr ..\mip\grace-new.mip
hdr2mip uffizi-large.hdr ..\mip\uffizi-large.mip

これも、mipフォルダに入れておく。ファイルによっては 100MB近いファイルに変換されるのでHDDの空き容量に注意。

レンダリングの途中結果をプレビューできる、fbview.exe を、オプション --listen 付きで起動しておく。

fbview --listen

scenesフォルダに入って、scene.exe サンプル.scn を実行。

scene teapot.scn
scene xyzrgb_dragon.scn

scene.exe が fbview.exe と通信(?)して、レンダリングの途中結果を少しずつ表示してくれる。

fbview.exe は、マウスの右ボタンドラッグで拡大縮小表示。中ボタン(ホイールボタン)ドラッグでスクロール。

レンダリング結果は、scenesフォルダの一つ上に、*.fb として保存される模様。fb2exr.exe を使うと、fbファイルからexrファイルに変換できる。

fb2exr teapot.fb teapot.exr
fb2exr xyzrgb_dragon.fb xyzrgb_dragon.exr

exrファイルは、たぶん _OpenEXR かな…。HDR画像ファイルフォーマットの一つ。

とりあえず、 _Luminance HDR 2.4.0 を使って png にしてみたり。




ということで、サンプルシーンを試してみただけではあるけど、ちゃんとレンダリングできました、とメモ。

最初、blender から .dae をエクスポートして描画しようとしたところ、全然違う場所に描画されて悩んだり。

オブジェクトを移動・回転・拡大縮小すると、一見そこに存在するように見えても、内部では全然違う別の場所、異なる座標で存在している、という状態になるのだな…。

そんな時は、オブジェクトを選択した状態で、下のほうのメニューから、オブジェクト → 適用 → 位置・回転・拡縮、を選んでやればいいらしい。

Wavefront形式(.obj)でエクスポートした際は、そのあたり適用した状態でエクスポートしてくれるようで、先日実験していた時はモデルデータの位置がおかしいことに気づかなかったのだけど。COLLADA形式(.dae)でエクスポートすると、内部で持ってる座標値等は極力弄らず、座標変換するためのMatrix情報を付加した状態でエクスポートするっぽい。故に、今回変な位置に描画されてしまったのだろう。たぶん。

なんだかよく分からない情報が並んでるな…。と思ったら、コレ、Properties に表示する項目の情報も列挙されているのだな。