mieki256's diary

以下のような流れで作業した。

1. Modo Pro 12 を使って、ロボットの静止画像を動かしたり、背景をスクロールさせたりして、連番画像(24FPS)を出力。
2. AviUtl を使って、連番画像から、Ut Video Codec使用のavi(30FPS)を出力。
3. MMD に、背景aviとして動画を読み込み。Effekseer で出力した .efk をD&D。1コマずつコマ送りして位置合わせ。
4. MMD から、未圧縮avi(30FPS)をエクスポート。背景aviと重ねた状態で出力。
5. AviUtl でaviを読み込んで、連番画像として出力してから、24FPSで連番画像を読み込んで、24FPSのaviやmp4として出力。

元動画の作成には、Moho Pro 12 を使った。以下の2枚の静止画像(1280x720)を使って、24FPSの動画として作成。



こうなった。(640x360に縮小)



ロボットの画像は、以下のやり方で作成。

_mieki256's diary - DOGA-L1で作成したモデルデータをblenderにインポート

背景のスクロールは、以下のやり方で。

_mieki256's diary - Moho Pro 12 でテクスチャを使ってタイリング塗り

メカっぽい背景画像は、GIMP の Python-Fuスクリプトで作成。

_mieki256/sci-fi-texture-generator
_Sci-Fi-texture-generator with GIMP Python-fu demo - YouTube

注意点。Moho Pro 12 の未圧縮avi出力は、何かおかしい…。

当初、24FPSの未圧縮aviとして出力したら、どうも動きがガクガクしていて。AviUtlで読み込んでみたら、ところどころで同じフレームが混ざっていた。連番画像として出力すると、そんなことは起きないのだけど…。

どうしてそうなるのかは分からないけど、とにかく Moho Pro 12 で未圧縮aviを出力すると、正常に出力されないっぽい。連番画像として出力したほうが、間違いはなさそう。

MMD 9.31 x64 上で、背景aviとして 24FPSのaviを読み込んでみたのだけど、勝手に30FPSに変換されて、以下のような奇妙な並びに…。

1, 2, 3, 4, 4, 5, 6, 7, 8, 8, ...

4フレーム分が、5フレーム分になっている…。

どうやら MMD の背景aviは、30FPS固定のようだなと…。仕方ないので、AviUtl で 30FPS の avi を出力し直して、MMD の背景aviとして読み込んで作業した。

MMDを使って、背景aviとおおよそ合うようにカメラの角度や画角を設定してから、Effekseer のエフェクトをD&Dして、目視で位置合わせをしたのだけど。

しかし、この作業がとても面倒臭い…。MMDの操作に不慣れという点もあるけれど…。x,y,zを変化させて位置合わせをするのが…頭が混乱する…。

考えてみたら、この程度のエフェクトや動画なら…。

1. 位置を固定して、エフェクトだけを連番画像として出力して、
2. Moho Pro 12 に読み込んで、
3. グループレイヤーにロボット画像とエフェクト連番画像を突っ込んで、
4. グループレイヤーに動きをつける。

というやり方でも十分だったよなと…。MMDを経由する必要は無かったのではないか…。いや、エフェクトをレンダリングする処理で必要になるのかな…。

MMDから、30FPSの未圧縮aviとして出力したけれど。AviUtl で読み込んでみたら、最初のフレームが何故か2フレーム分表示される状態になっていて。どうしてこうなるのか…。

何にせよ、MMDから出力した動画は、動画の最初のフレームがダブったり、動画の最後のフレームが欠落している可能性がある、と思いながら作業しないといけないようだなと。

実際は24FPSの動画を30FPSとして扱って作業をしたので、最後に24FPSに戻さないといけないのだけど、上手いやり方が思いつかず。

仕方ないので、AviUtl を使って…。

1. 30FPSのaviを開く。
2. 連番画像として保存。
3. 開いてた動画を閉じる。
4. 先ほど保存した連番画像を、24FPSを指定しつつ開く。
5. aviを出力。24FPSで保存されるはず。

こういうやり方で、24FPSの動画にした。

もっと上手いやり方がありそうな気がする。絶対あるよな…。

# 見出しレベル1

## 見出しレベル2

以前も書いた気がするけれど…。Markdownの一番の売りは、テキストファイルのまま眺めても文書の視認性が良いという点で。

その一端を示すのが、見出しの仕様。

# 見出しレベル1

## 見出しレベル2

という書き方の他に、

見出しレベル1
===================

見出しレベル2
-------------------

という書き方も許容されている。

コレ、どっちが読みやすいか。プログラマーの視点では前者だろうけど、一般人の視点では明らかに後者だよなと。広告メール等でも、よく見かける書き方だし。

プログラマーが「# 見出し」を好む理由は、よく分かる。

• 打ち込むのが楽。
• 何かしら自動化しようとした際の判別処理も楽。
• 見出しレベルが1〜6まで変化する際も、「#」「##」〜「######」と同じ記号を増やすだけで対応できるから覚えるのも楽。

自分もプログラマーだから、「できれば『# 見出し』を使いたい」「むしろ『# 見出し』以外は存在しないことにしたい」というその気持ちは分かってしまう。

しかし、「行頭に『#』があったらそれは見出し行だ」なんてのは、Markdownの仕様を知ってる人しか分からないルールなわけで。

コレが、もう一つの書き方ならどうか。Markdownの仕様を知らない人でも、「アレ？ 見た目で区切りがあるぞ…。ははあ、なるほど。これは見出しなわけね」と容易に推測できるよなと。

ルールを知らない人でも文書を眺めれば、なんとなくぼんやりとルールが分かる。それが Markdown の一番の売り。Markdownの価値は、そこにある。

なのに、「# 見出し」を強要してたら、あかんよなと…。ソレ、Markdown って何なのか、そこからして分かってないよな…。

自動化をしやすくしたいなら、あるいは機能を増やしたいなら、Markdown より便利な記法が他にあるわけで。はてな記法だのwiki記法だの、やれることは多いし、処理もしやすいけど、見た目がゴチャゴチャした記法を使ってればええやんか。

_軽量マークアップ言語 - Wikipedia

Markdownの特徴について、分かってるのかなあ…。

プログラマーの悪癖として、「何か処理をしたくなると自分達だけが分かる特殊記号を使い始める」とか「打ち込みやすさを優先してしまう」というのがあって。代表的な悪例としては、Perl や正規表現があるのだけど…。

Markdownの見出し文を「# 見出し」で決めつけちゃうのは、その悪癖だよなと。この流れは危ない。このままだと、便利さや処理のしやすさばかり追求して、見た瞬間ゲロ吐きそうなルールを平気で入れ始めちゃう…。そういうのは Perl だの LISP だのでウンザリなんだよ…。

Markdown を扱う時は、テキストのまま眺めてもそれは読みやすいのか、そこを絶えず意識してほしいよなと。

と言っても、巷のアレコレを眺めてると、もう遅い気も…。Markdownに独自仕様が盛り込まれる際、相変わらず謎記号が氾濫するんだよなあ…。Markdownを知った時、「なるほど！ 既存の記法とは視点が違う…」と感銘を受けた自分には、ちょっと理解しがたい流れで…。

考えてみれば…。PC-9801やX68Kを使ってた頃は、ツールの説明書がテキストファイルで書かれてるのが当たり前だったけど、当時、いかにして読みやすい形で書くか、てなあたりも工夫してたよなと。

どこかの時点で、そういう文化がリセットされてしまったのだろうな…。

もっとも当時の、

■■■■■■■■■■■■■■■■■■■■■■■
■         hoge fuga piyo 説明書            ■
■                                          ■
■                              19xx.09.17  ■
■■■■■■■■■■■■■■■■■■■■■■■

☆☆☆☆ 概要 ☆☆☆☆

みたいなのも「おいやめろ」って感じだけど。これはこれで、どことなく「なんでもExcel」文化に近いノリを感じる…。

なんでもそうだけど、バランスが大事だよな…。

_Prettier - Code formatter を入れてみたけど、Markdownが妙な整形をされてしまうので無効化したり。設定ファイルに以下を追加して、Markdownファイルを保存した際に、勝手にフォーマットされないようにした。

"[markdown]": {
    "editor.formatOnSave": false
  },

フォーマットのルールを細かく指定できればいいのだけど、ググっても設定方法が分からず。利用は諦めるか…。

以下の記事で、Remark という拡張機能があることを知った。

_VSCodeでMarkdownの自動フォーマット＆整形ルールを自由に設定
_Remark - Visual Studio Marketplace

こちらは、Markdown の自動整形フォーマットルールを細かく指定できるらしい。

試しに入れてみたけど、やはり見出しが「#」に書き換えられてしまった。何なの、お前等。

しかし、以下の設定をすることで、見出しの整形を、「=====」「-----」を使った形に変えてくれるらしい。素晴らしい。ちゃんと分かってる。

  "remark.format": {
    "rules": {
      "setext": true,
    }
  }

ただ、日本語文字列の長さを、漢字1文字＝1文字として認識するようで…。「=====」「-----」の文字個数が、日本語を使った見出し文字列の、見た目の半分の個数になってしまう。処理としては正しいのだけど、見た目ではよろしくない。

でもまあ、このあたり、使ってるフォントによっても見た目の長さが変わるし…。英語圏を前提にした拡張機能だから、こういうのは、どうしようもないのかもしれないなと。

ついでに、以下のように設定してみた。

  "remark.format": {
    "rules": {
      "gfm": true,
      "setext": true,
      "bullet": "*",
      "listItemIndent": 1,
      "fences": true
    }
  }

• gfm で、GFM(GitHub Flavored Markdown)を指定。
• setext で、見出しレベル1〜2の書き方を、「====」「----」を使った形にする。
• bullet で、リストの行頭として使う文字を指定。
• listItemIndent で、「* リスト内容」の空白インデント文字数を指定。デフォルトでは2個の空白文字が入る。

このあたり、前述の記事で紹介されてた、以下のページが参考になった。

_remark/packages/remark-stringify at master - remarkjs/remark

ただ、テーブルがグチャグチャになってしまう…。これも、日本語文字列が含まれてる際に、漢字1文字＝1文字として扱うせいだな…。

日本語文字列が含まれている Markdown を自動整形すること自体が間違い、かもしれない。利用は諦めよう…。