インターネットスラングも変わるよ

　招待され、昨日から久しぶりに海外の趣味のコミュニティに参加した。10以上年ぶりとなる。とは言え、絶頂期の5%も能力が発揮できなくなった現在の私にできることは無いと言って良い。実態としては「狭い世界の中だが、頻繁に画像や動画のクレジットで見た名前の当人が来た」ってところで多少の賑わいとなることぐらいだろう。

　20年前のコミュニティは、インターネット上とは言え地域性が感じられることが多かった。メンバーが米国ベースと英連邦ベースではメッセージでの文章表現の距離感も違った。とにかく英語が使えないとダメだった（真面目な話、勉強した。趣味の話に限るなら多くの人が結構頑張れると思う）。私は「距離感が程よい」ところからカナダベースの今は無くなってしまったコミュニティに入り浸ったが、このコミュニティへ参加することになったきっかけはとある人からのメールによる招待だった。今回の招待を受けた際、上記の突然のメールでの招待を思い出した。

　10年以上ぶりにこの種のコミュニティに参加して、たった一日で多くの変化を感じた。

　まず、地域性が極めて薄くなったこと。私は日本からだが、チェコからの人もいる。これはコミュニティのバックボーンが、レンタルサーバー上のデータベースソフトからクラウドベースのDiscordのようなコミュニケーションサービスに移行したことから当然かとも思う。かつてはPC限定だった接続デバイスの制限も実質的に無くなった。ただし、通信量の制限はむしろ厳しい印象も受けた。この辺りは少し「縮み志向っぽい」が、「テキストベースながら豪華で多機能なポータル」と思えばなんということは無い。その背後には、クラウドベースの膨大なデータが以前よりも大量に存在する。１日如きでは見えないが、時間差の影響も以前とは違うだろう。

　二点目は、使われるスラングの変化。コミュニティが地域性を持つならば、チャットやメッセージで使われるスラングはその地域性をそのまま反映する。より具体的には、街中で特定の世代がしゃべっているスラングがそのまま使われる。やっかいなのは古典的には「極めてネガティブな意味を持つ表現」が、逆に「極めてポジティブな意味を持つ表現」として使われる場合だ。時間をかけてネットで調べればどちらか判断できる場合もあるが、一読では悩むこと必至だし、コミュニケーション上の誤解の原因ともなる。ならば今はどうか。ネット上でしか使われていない（らしい）スラングがチャットやメッセージ内で目に付く。ちょっと面倒なのがGoogle翻訳もDeepLも全く追いついていない点だ。Wiktionary辺りで明確に「ネットスラング」とか書かれていないと、誤読の原因となりかねない。例えば”holy based”には１時間ほど悩まされた。これ単独はとてつもなくポジティブな意味を持つが、とてつもないが故に文章全体の文脈からは皮肉っぽさを感じなくなくもないという…ね。

　三点目は、ローマ字表記で正確な日本語表記ができる人が一人や二人ではなかったこと。これは以前は無かった。例外は「Arigato」ぐらいのものだった。こっちが日本人であること、英語が得意ではないことは基本的にバレているから（隠してもいないし）、明らかに気を使ってくれていると言える。海外出身の英語教師でもないのに、日本語と英語のダジャレさえ使う英語ネイティブの存在はやや衝撃だ。「私の苗字は日本語ではキリスト教徒です」→「苗字はクリスチャン？」ってな感じのチャットをローマ字日本語と英語でやったということだ。 

　久々過ぎるエントリ。まぁ、それぐらいのことがこの土日に有ったということだ。

2022 - 2023

　プロジェクトは未だ終わってもいないし、辞めてもいない。2160pのオリジナルのイメージはこちら(グーグルドライブ)からどうぞ。

　今年の最期はアニメ「ぼっち・ざ・ろっく！」に持ってかれた感じ。音楽モノは基本ハズレが少ないというのが認識だが、本作については楽曲の質の高さ、他の要素との親和性・整合性のレベルの高さがまず桁違い。作り手の熱？にもあてられてか、第一話の虹夏がひとりの手を引いて公園から連れ出すシーン辺りでもうメロメロって言うね。

 

　最終回にも新曲ぶち込んでくるとはなぁ・・・と言うか、途中からきっとそうくるだろうなぁと期待させられたのも事実。が、ラストにもう一発あるとかね。それも予想と言うか、まさに「それ」を早くから期待していた人も多かったのは、送り手-受け手感のシンクロニシティっぽくて個人的には興味深かった。まぁ、分かる人は一話の段階で最終話のサブタイトルぐらいは予測できた筈、私はアジカンはほとんど聞いていないのでいきなりは予測できませんでしたねぇ。

　片や、Future Funkの文脈でこんなのばっかり聞いていた時期も・・・

かつて自分が公開した3Dメッシュデータをコンバートしてくれている人が未だ存在することの喜び／The joy of still having someone who has converted the 3D mesh data that I published

　エントリタイトルが全てを語る。「bingでエゴサする」という「３年に一回×２年に一回」レベルの稀な振る舞いをしてみたところ、https://www.scifi3d.net/というブログを見つけた。

　このエントリを書いている時点で、最新エントリは”Download The Ouroboros/Galactica Battlestar for DAZ Studio”（DAZ Studio用のウロボロス／ギャラクティカバトルスター（のメッシュファイル）のダウンロード）、日付は今年の5月だ。

　私が公開しているウロボロス／ギャラクティカバトルスターメッシュデータは旧型のLihghtwave3D形式のみで、当然ながら他の3Dソフトウェアでは読み込むことすらできない。かたやLightwave3Dを使っても、仕様変更が原因で新しいバージョンでは当時私が意図した通りの画は再現できない。メッシュデータの他のソフトウェア形式への変換（コンバート）は、理由は割愛するけれどもそれ自体難易度が高く、面倒臭い。正直、情熱とかモチベーションを喚起する何かが無いと完遂自体が無理だと信じている。

　先のサイトで目にしたレンダリングされた画像は、「当時の私の頭の中にあった完成像」そのものだった。素晴らしい出来だとまずはシンプルに感動した。変換した方の費やした時間、努力や労力、そして見事な変換を成し遂げてくれた胆力・情熱に感謝したい。そして、公開されてから１０年以上経っても他者に触ってもらえるデータを作り得た当時の自分の中の情熱も誇りたい。

製作中のYouTube動画"VF-1A Rig Test"向け没カット、ただし没カットと言うのは嘘

　昔々に作ったVF-1Aの3Dモデルのリグのテストを10年ぶりぐらいに実施・・・と言うのは嘘で、単に突然やりたくなったのでバトロイドモードで色んなポーズを取らせてみた。

　ここでリグと言うのは3Dモデルに組み込んだ骨組みみたいなものだ。各骨の動きを特定の部品とリンクしておくことで、骨の回転や平行移動などの操作によって3Dモデルの変形やポーズ付けが実現できる。ちなみに10年以上前に組んだリグの骨（日本語ではボン又はボーン）の数は100を超えていて、ファイター、ガウォーク及びバトロイドのモード相互の変形から各指の動きまでサポートしている。またスクリプト機能なども使い、多数の骨を然るべきタイミングで動かす必要があるモード間の変形過程を、単一のヌルオブジェクト（Null、位置や回転などの情報を持つだけの不可視の物体）の回転操作だけで実現できるようにまで作り込んでいる。

　10年前の自分のこの種のモノに対する熱量と言うかこだわり具合は、「異常」という意味で我ながら「おかしい」と思ってしまうレベルだ。

　で、バトロイドモードで取らせたポーズは20種は下らないのだが、元ネタが分かりにくいもの（例えば大友克洋氏のマンガ「童夢」のチョウさん、「そうだよ、ボクだよ」のカット。ふわっと浮き上がった状態を表す地上に落ちた影と左手の表情が拘りどころ）や、オリジナル作品中のポーズの再現といった今後使えそうなものを除いた３つをここで挙げておきたい。挙げておきたいから挙げておく、っつーだけの話。公開済みの別動画に組み込まれることで「没カット」のフェイクとしての役割は果たしていて既にお役御免の画達なのだが、単なる小ネタのつもりが割と気に入っちゃったんだよね。

　まず、自動運転機能を持つ大型人型兵器の最期を飾るビームライフル射撃直前のポーズ（のつもり）。頭部と左肩の骨のスケールを0%としただけなので、大きさゼロの頭部と左肩～左手は見えないだけでちゃんと存在しているよ。元ネタがまずあって、それが分かる人だけニヤリとしてくれれば良い、というのが本画の成立に関わる文脈だからね。それを無視してポリコレ化するのは止めてね。

　次いで、何かと三倍な赤い大型人型兵器と劇中で後に「白い悪魔」と呼ばれることになる別の大型人型兵器との激突シーン（のつもり）。

　最後はミケランジェロ作システィーナ礼拝堂天井画の一部（のつもり）。大の旅行嫌いだし新型感染症が無くたって健康的に今は無理なのだが、こいつばかりは実物を目にしたいんだよね。天井画の来日はさすがに無ぇからねぇ・・・

ライティングの肝は影

　PCを用いた3DCGI歴は何気に長い。最初のパッケージアプリを使い始めたのはCPUがIntel i286（16bit CPUだ）のころで、i386ネイティブレンダラー（要は32bit専用レイトレーシングレンダラー、使えるメモリが大きくなり、かつ高速）なんてものが後から別売りされたりするようなタイミングだった。モデリングは用意されたプリミティブ（球体などの基本的な三次元形状）を配置、変形、回転させるだけで、表面属性はプリミティブ単位でしか指定できなかった。大学で開発、無料配布されたMODEなんかがそうだ。

　加えてPC本体の表示可能色が4096色中16色（NEC系のデジタル16色）だったので、24bitカラー（当時言うところのトゥルーカラー）だったレンダリング結果をちゃんと見るには追加のハードウェアが必要だった。私の場合は、300×200ドットの24bit表示が可能なフレームバッファを拡張バスに追加していた、当時にして10万円也。

　プリミティブベースではモデリングの自由度の限界に直ぐ至るが、連続的かつ代数的に物体表面特定位置の傾斜が得られるため、代数的に厳密なレイトレーシング計算が可能だ。要は基本原理従った例外のほぼ無いアルゴリズムで、相対的に低い計算負荷と高精度を両立したレイトレーシングが可能となる。代表的な例外は物体の角部だろう。そのような位置では物体表面の勾配及び勾配の一次微分が定義できないから、特別扱いは必至だ。同じ理屈で光源設定の自由度も高く、厳密な点、線、面、スポットが利用可能だった。初期のポリゴンレンダラーの線、面光源が点光源の集合体であることがあったこととは対照的だ。

　やっと本題なのだが、その時点で3DCGIのライティングの肝は影のコントロールだとあっさり悟った。ここでの「肝」の意味は、ほぼ「リアリティの付与或いはリアリティの強化」と同義だ。「光あるところに影あり」とは良く言ったものだが、光源の種類の判別は光が当たっている部分よりその光の影のエッジ部を見た方が良く分かる。光が強く当たっている部分はそれっぽくても、影が「本来あるべき光源にふさわしくないもの」になっているとリアリティは一瞬で失われる。特にあるべき影が無い場合は、3DCGIで画を作ることに疑問すら感じる。早くて安く画ができるといった経済的な理由はもちろん分かった上での話である。

　影に関する考え方は当然モデリングにも反映される。レンダリング時に影を落とす必要のない構造物はモデリングせず、バンプマッピングなどで処理することになる。構造物をモデリングするか否かの判断基準は影が全てで、大小などは全く考慮しない。 

　さて、

つい先ほど、たまたまYouTubeで"OBSOLETE"を摘まみ観した。影は基本的に計算されていないし、銃器のフラッシュも点光源で処理している。厳密な点光源はこの世に存在しない点は軽んずべきではない。結果、光と影のリアリティが皆無に近い画作りになっている。個人的には魅力を感じない類のもので、むしろ手描き画で見せろと声を挙げそうになてしまう。3DCGIで、レイトレーシングは点光源を使った最小限のもの・・・安くて早いのだろうが、出来上がったものに何かが宿るということはなさそうだ。

　影が肝と信じる以上、逆の手に出る場合もある。特定の目的の下、他の表現に役割を果させることで影を最小限にする場合がそうだ。アニメ「超時空要塞マクロス」に登場するメカVF-1Aの3DCG動画をかれこれ10年程前にYouTubeに上げているが、これがそうだ。この動画はモデルのショーリール、つまりモデルの形状的な出来具合をアピールするためのものなので、画はモデル全体及び部品の形状や位置関係が分かり易いものであるべきだ。

　ここではラインレンダーを使ってモデルの輪郭や鋭角部を黒線で表示することで、影に頼らずモデル形状が把握できる画作りを目指した。ライティングは上からの白の平行光と白の環境光だけだ。前者は夏の真昼の太陽光をイメージしてもらえればよく、輪郭がはっきりした濃淡分布の無い影を生む。後者は特殊な光で、物体表面をむら無く均一に照らす。従って光の向きはどこでも物体表面に垂直であり、影は落ちない。並行光だけだと機体下面や内部構造物は完全に真っ黒な影に入って見えなくなってしまうが、環境光を使うことで影の内部でも輪郭線などが常に確認できる画となる。

　手描きアニメっぽい画となるラインレンダーを使っているためセルシェーダー（セル塗りシミュレーターの一種）も使っていると勘違いしている視聴者が国内外ともに少なくないが、画作りの意図からは不要なので当然使っていない。セルアニメ風の画作りなら別の考え方に基づいた手法の方が効率が良い（＝安い早い）が、そんなことを3DCGIで何故やるのか？できるからやる、に未だ価値があったのはかれこれ25年ぐらい前の話だ。アマチュア補正も＋10年が限界だ。

　なお"OBSOLETE"の画は、基本的に環境光だけ使った場合のそれに極めて近い。環境光はね、早くて安いのよ。

ファイターモードからガウォークモードへの変形時もヒンジは開く

　アニメ「超時空要塞マクロス」に登場するVF-1A バルキリーは私の大好きメカであり、海外にもファンは多い。デザイナーの河森正治氏は、英TVシリーズの「サンダーバーズ ARE GO」でS号のデザインを依頼されている。

　しかしながら、後のVFシリーズとは異なり、その変形自体にはマジックが多い。チートではなくてここでは"ANIME magic"と敢えて呼ぶが、表現が適切かどうかはともかく、河森氏が「マジックに頼りつつも何かでっかい扉を開けてしまった」のは間違いないと個人的には見る。とは言え、続くVFシリーズの大部分のように「マジックに頼らないガチな変形」に通じるデザインの方向性は、VF-1においてもあちこちに見ることができる。10年以上前に作った3Dモデルとそれを用いたアニメーションシーンファイルの内容を再確認しつつ、モデル製作当時のことも思い出しながら、あらためて思う。本エントリで触れている話は、基本的に1980年ごろと2020年ごろのことである点に留意願いたい。

　エントリタイトルの通り、ファイターモードからガウォークモードへの変形時もヒンジが開く様が、TV用の作画設定資料の1枚に明確に描かれている。ここで言うヒンジとは時に「トラベルヒンジ」と呼ばれる蝶番構造を指しており、バトロイドへの変形時に脚部付け根（空気吸入口付近）位置を無理やり機首側面まで移動させる、少なくとも強度的にオーバーテクノロジー無しでは成り立たない代物である。

　単純に考えると、ファイターモードからガウォークモードへの変形過程でヒンジが開く必然性は無い。が、ここでヒンジが開くところに「ガチ」を見出して、あまつさえ他人に伝えたくてしょうがないあたりがまぁ私の所謂オタクなところなんだろう。実際のところ、強度ほぼゼロにしか見えないが機械構造としてのヒンジはちゃんと3Dモデル化してしまってあったり、ヒンジを設けるために周囲構造物の厚みをオリジナルデザインより厚くしてしまったりという辺りは、我ながら「異常な愛情」を感じてしまう。そうまでしてヒンジを3Dモデル組み込んでしまうのは、おそらく私がVF-1におけるヒンジの重要性を世界で最も信じている（？）故であろう。（「三次元化するにも3DCGIが限界であるからこそ3DCGIで再現する価値がある」と言う考え方だ。この裏返しのように、他のVFシリーズへの興味は文字通り皆無だ。）

　んで要は、VF-1Aの3Dモデル製作過程で、件の変形過程でヒンジが開く必然性に私は（も？）直面してしまった訳だ。2011年ごろ、今から10年も前の話である。

 　ささっとまとめよう、百聞は一見に如かず。ヒンジを開いて脚を前に振り上げる方向に動かしてやらないと、腕部を機体下面から機体外側面に回転移動させる際にガンポッドの先端が脚にぶつかってしまう。なお、私のモデルの場合、ヒンジが開かなくても回転移動時に肩部と脚はギリギリぶつからない、ぶつからない移動タイミングがある。つまり、ガンポッドが無ければヒンジの出番は無い。

　ヒンジ機構自体は良くも悪くもマジックなのだが、そのヒンジ機構が「地味」に「ガチ」に良い仕事をしている辺りがなんとも趣深い。更にそれが作画設定資料に普通に描かれているのは結構衝撃的な事でないかい？

レンダーファーム、使用料おいくら？

　最近、13～10年前にYouTubeに上げた3DCGI動画のリメイクに手を染めた。ざっくり10年でのCPUパワーの増加は10倍強で、20倍には届かないというのが実感だ。ただ、3DCGIで最も時間のかかるレンダリングは並列計算向きで、アプリ側もマルチコア/スレッドCPUの特性を最大限利用するように発展してきている。加えて、メモリやストレージの性能向上もレンダリング時間短縮に明らかに寄与しているよう見える。結果、CPUによるレンダリング速度は、20倍をやや超える程度までは向上したように思う。

　20倍強というと微妙な感じもする人もいるだろう。だが一般的なサラリーマンの１ヵ月あたりの出勤日が約22日であることを考えると、1日の出勤だけで給料一ヵ月分貰えるような「比率」ではある。３週間かかっていたレンダリングが1日で終わる。丸1日かかっていたレンダリングが１時間ちょっとで終わる。特に前者の場合は、私なら以前は絶対やろうとしない条件だ。とは言え、"Enough  is not enough"なのが人間だ。そんな人こそレンダーファーム・・・なのかな？

　レンダーファームとはレンダリングのためのCPUパワーのレンタルサービスや、そのためのハードウェア・ソフトウェア環境を指す。歴史をすっ飛ばして現状だけ見れば、クラウドコンピューティングサービスの一種と見做せるんじゃないかと思う。要は自分のPCの代わりに、レンタルした並列計算環境にレンダリング計算をしてもらうサービスだ。時間をプロダクションコストに含めなければならないプロフェッショナルの世界では、昔から必須のサービスだ。また、フリーランスの3DCGIアーティストが自己宣伝用デモリールを作る際に、仕上がりをプロフェッショナル級にするために使われることもあるようだ。

　で、いくつかのレンダーファームサービスの価格を調べてみた。結論から言うと、良くも悪くもサービス提供元による価格差はほとんど無かった。もう少しばかり定量的に書くと、円-ユーロ、円-ドルの為替レートの変化でどこのサービスが一番安いかが変動するレベルの差だ。と言う訳で、米国ベースのとあるサービスの簡単見積りページで価格を見積もってみた。条件は、私のメインPCでレンダリング実績のある以下の通りとした。

• 600枚の静止画をレンダリング
• Intel i7-10700で静止画1枚／分、総レンダリング時間は10時間
• 200ノード並列
• 優先度は普通
  

ここでは、CPUを特定し、そのCPUでのレンダリング時間を与えている。サービス提供元のノード又はCPUの計算能力と特定したCPUの計算能力との換算が妥当ならば、かなり正確な見積りになるのではないかと思う。ノード並列数には特に意味は無いが、レンダリング枚数を超える意味が無いことと、レンダリング枚数の約数であることは意識した。優先度というのはざっくり実行順で、お金を積んで「高」とか「最高」にすれば、「普通」の他ユーザーの計算を止めてでも先に計算してもらえるようになる。

　見積り結果は以下の通り。

• 実効計算時間は約80秒
• 価格は約￥1,300-

実効計算時間はノードの性能から妥当な感じ、使うとしても全く文句は無い。データのアップロード、ダウンロードを含めたターン・アラウンド・タイムは15分ぐらいだろうか。生成され、ダウンロードするデータの量は多いが、これらデータの一時保存などのコストは見積りに含まれていなかった。まぁ大抵はそのためのネットワークストレージサービスを別途契約しておいて、レンダリング結果はレンダーファーム側が適宜書き込む形にすべきなのだろうけれども。

　 対して価格だが、これが微妙。趣味かつ作成動画からの収益無し、という条件下ではやはり高値感がある。せめて半分、ただ￥300＋消費税なら使うかもしれない。ちなみにCPUの最大TDP60WでメインPCを10時間全力駆動した場合の電気代の「増分」は約￥16-で、計算する前の予想よりは安かった。結局のところ、レンダリング時間である10時間が「睡眠時間＋アルファ」又は「出勤で部屋のPCに触れられない時間以下」なので、金を払ってでも取り返したい時間になかなかならないのが高値感の原因だろう。

　レンダリング時間が更に100倍になる辺り・・・価格￥13万-以上・・・からがレンダーファーム利用の本領発揮ラインだろう、というのが今回の感覚的な結論かな？200並列ならば「40日後の結果を今日の午後に得られる」となるが、こうだとさすがに価格の見え方も変わってくる。場合によっては「40日後に得られる予定だった結果を見ることで、40日後に得る筈だった新アイディアを今日の午後に得られる」なんてこともあるかもしれない。後者の場合、本来無かった筈の40日も別途購入したようにも考えられなくもなくない？

TDP60Wの力、2010年と2021年のCPU対決

　長時間駆動を前提としたCPUダウンクロックが良い感じとなった勢いそのままに、2010年に一度レンダリングしたシーンを再レンダリングした。今度のネタは米国TVシリーズのBSG（Battlestar Galactica）だ。

　同一のLightWave3D用シーンファイル（一世代前）を用い、睡眠時間中も含めた約10時間で600イメージをレンダリングするという、記憶通りであれば2010年の際と全く同じ条件を課しての実行となった。暗算に抵抗無い人なら直ぐに分かるように、平均1分で1イメージをレンダリングするということだ。

　2010年の際のCPUはIntel Core 2 Duo E6850で、ウェブ上のいくつかのベンチマークデータを参考にすると、総計算パワーは現行メインPCのCPUであるIntel i7-10700の約1/10～1/12だった。改めて調べて分かったのはE6850のTDPが60Wだと言うことで、この値は長時間駆動用にダウンクロックした現行CPUの最大TDPと同じだ。

　70Wまで低減した過程は先行するエントリで触れたが、その後、主に気温の上昇（28～29℃）が原因で、それでもCPUパッケージ最高温度を85℃以下に保つために60Wまで更にTDPを下げることとした。日当たりの良い締め切ったワンルームでは、日中の室内温度が急激に上昇している昨今では致し方ない。コアの最大クロックは3.6GHzから3.4GHz付近まで下がり、コア1/2個分の計算パワーを更に捨てたことになる。つまり全力かつ連続駆動時の計算パワーは、6.5コア、13スレッド相当となる。

　TDPはあくまで熱設計用のパワーだが、実用上は計算に要するパワーに近い値とされる。ならば、1イメージのレンダリングに要するパワーは2010年と今回とでほぼ同じとなる。しかしここ10年のCPUの発展の歴史では、省電力化が大きな位置を占める。では、レンダリングの設定がどれだけ変わったか、これすなわちこの約10年の省電力化＋周辺機器の性能向上の恩恵は如何ほどだったか？結果から言うと結構凄かったのだが、さすが10年と言うべきか、されど10年と言うべきかはなかなかに難しい。あ、あとソフトウェアであるレンダラーもマルチコア前提で変わっているんだよなぁ。

• レンダリング画面は16:9だが、高さ（9の側）は360ドットから1440ドットへと4倍まで増やせた。つまりイメージサイズは16（＝4×4）倍になった。この点は結構ビックリだが、3DCGIのレンダリング作業は典型的なマルチコア向き作業だ。
• メモリサイズは2010年時は16GB、今回が32GBだ。レンダラーが表示したメモリ使用量は約20GBなので、2010年時は完全なオンメモリでレンダリング計算ができていなかった可能性、すなわちHDを用いた仮想メモリ機能を用いていた可能性が高い。
  
• 船体表面のライトの数を増やすと、レンダリング時間がてきめんに伸びる。2010年時はライトをあきらめた（配置したがOFFとした）が、今回は最小限のライト（約30個）をONにした。
• アンチエイリアス、ノイズフィルタの設定は「感覚的に」同等とした。これはレンダラー間でアンチエイリアスやノイズフィルタ手法が基本的な考え方からして違うためで、比較の基準となる客観的な数字が無いためだ。結局のところ、出来上がりのイメージを見て「趣味のプロダクションとしては、まぁ許容レベル」 と自分として言えるかどうかで判断するしかなかった。当然、こんなんじゃ金は取れないっつーか、解像度がまず足りていないのは言わずもがな。
  なお、先行して似たことをやったVF-1Aの場合には、ノイズフィルタの適用量が「趣味のプロダクション」だとしても不足していると判断した。故に「テスト」止まりな訳だが、そもそものレンダリング設定がテスト用のそれでしかないのだから当然と言える。

　なお、動画作成は前回も今回もAdobe After Effects CS5を使った。ここだけは10年以上を経ても変わっていない。音声は2010年版のYouTube動画から抜いたものをDAW上で軽く手を入れて用いた。モコモコした感じが若干抜けて、音がややクリアになっているのではないかと思う。ちなみにYouTubeにアップロードする前の2010年版動画は、ハードディスククラッシュで他の多くのデータとともに未来永劫失われている。

　で、2010年版。

　と、2021年版。

tan.j's battlestar meshes are now downloadable :)

Hi! My Battlestar Meshes in the old Lightwave3D format is now available for free download from Google Drive. The download URL is here.

You can download:

• Pseudo-Galactica type vessels; Ouroboros and Pacifica,
• Minerva class vessels; Pleiades, Hyades and Hesperides,
• Arvak class vessels; Sleipnir and Skinfaxi.

These meshes are the same that only Foundation3d members could download from the Resources section of Foundation3d.com. These are built by Lightwave3d ver.8-10, and their model and scene file formats are supported up to Lightwave3d 2015.

• There is no other format mesh data.
• There is no support related to my downloadable mesh data.
• Please do not make any money by using downloaded mesh data or its derivatives.

Happy rendering!

　日本人で興味ある人はもう居ないと思うけど、バトルスターギャラクティカに関わる私の3DモデルをGoogle Driveを使って公開しました。ファイルフォーマットはLightwave3D 8～2015のものでかつShader使いまくりなので、基本的にShaderの取り扱いが別物になったLightwave3D 2018以降でまともに開けるのかどうかも分かりません。

ダウンロードできるのは以下の7つ。

• Galactica型もどきバトルスター：Ouroboros、Pacifica
• Minerva級バトルスター（私のオリジナルデザイン）：Pleiades、Hyades、Hesperides
• Arvak級バトルスター（私のオリジナルデザイン）：Sleipnir、Skinfaxi

で、

• 他のフォーマットのファイルはありません。
• 私によるサポートはありません。
• お金儲けには使わないでください。ただし、その種の行為を見つけても以前の様には干渉しません。

と言うことで宜しくです。

　ハッピーレンダリング！

続・某YouTube動画の再生数急増

　先行するエントリで述べた私がYouTubeへアップロードした特定の動画の再生数急増の件だが、思ったより早く収束しそうな雰囲気が出てきた。ついては後述するように切りのいい感じの数字が出ているので、もう中間評価ということにしてしまおう。

　さて、直近28日間（4週間）の件の動画の１日当たりの再生数は下図の通りだ。急増と言うより激増と言った方が良さそうだ。緑字の「↑>999%」という表示が状況の異常さを良く伝えてくれる。

で、７年半前のアップロードから今日 までの１日当たりの再生数は下図の通りだ。私が笑ってしまったのも分かってもらえると思う。右端以外はほとんど０にしか見えない。

　右端を除く時間域の地を這うようなグラフ線上に、何カ所か小さなギザギザした再生数の増加が見られるが、これらの原因は大部分把握できている。多少なりとも影響力のある人が自身のFacebookまたはTwitterが取り上げてくれたからだ。これらは動画のリファレンス元（＝動画のページにどこから来たか）とGoogle検索結果などから、ものの10分ほどで原因となった具体的なユーザやTweetの特定は可能なのだ。

　一方、今回の激増ケースでは動画へのアクセス元の99%以上がYouTube内からであり、明らかにRecommend数の増加が原因である。

　さて、上記した「切りのいい感じの数字」について触れよう。件の動画の今日の１分当たりの再生数は約40回となるが、この数字は年初の１日当たりの再生数に相当する。つまり再生ペースが1440（24[時間]×60[分]）倍程度まで大きくなったということだ。いやぁ、やっぱり異常な事態だ。

　ところで、28日分の再生数グラフを見ると、激増前に５日程度を周期とする微かな再生数の増加が見えるだろうか。実は年越し後、最大約100%の再生数増大（つまり、再生数２倍）が複数回発生していたのだ。このような安定／不安定境界とも言えそうな状況下で何か外乱が入って一気にYouTubeのRecommendシステムが不安定化した・・・というのが先のエントリでも述べた私の見立てだ。ここで不安定化とは所謂「逸走」、一方向に吹っ飛んでいくような、雪だるま式とでもいうような挙動を指す。ちなみに私は、工学分野で現れる非線形システムの安定性問題が、大学生時代から就職後も大好物なんですよ。

某YouTube動画の再生数急増

　7年以上前にYouTubeにアップロードしたとある動画の再生ペースが1ヵ月前の40倍以上までに急増、併せてチャンネルのSubscribe数も急増し、思わず笑う。こんなこと10年無かったわ。誰か幸せになるんなら良いんだけど、7年以上も経つと価値観や世の中の見え方が変わってしまって私自身がほぼ別人なんだよなぁ。

　チャンネルベースの再生数は下図の通りだが、増分はほぼ上の動画の再生数の増分に等しい。なお再生数絶対値は大したことはなく、収益化対象となるためにはさらに100倍近い再生数の増加が必要なレベルだ。

　問題と言うか申し訳ないのは、同系統の動画を作る予定も上げる予定も現時点では無いことだ。つまりせっかくSubscribeしてもらっても、暫くは期待されているような新規動画が私から上がる可能性はほぼ無い。ということもあって、どうせ２、３週間もすれば再生ペースは元に戻るだろうとドライに考えている。故に喜ぶでもなく笑うしかないのだ。

　ただ思うことは２点ほどある。

　一点目は極めて個人的な内面の話。「喜ぶでもなく」というのが、自分でも一瞬驚いたほどピュアな本心であることだ。件の動画は自分の中では既に完了させた個人プロジェクトのアウトプットであるため、再生数やLike数の増加は私の自己承認欲求や報酬系を全く刺激しないのだ。心から有難いけど別段嬉しくはない。あ、コメントは嬉しみあるかな。

　「じゃぁどういう状態が嬉しいの？」と問われれば、この動画きっかけで3DCGモデリングや動画作成に挑む人が現れることや、「この動画はもう何もかもが古くなってしまった！」と唸らされてしまうような動画が氾濫するような状態の出来だ。故に、7年前に１日12時間労働が日常化していた一人のサラリーマンがストレス解消にちびちび作った動画に、未だにそこそこのペースでLikeが付き続ける現在の状況は、当事者としては実はツマらない。

　なんといっても私のオリジナル要素は無く、志の低い単なる作業の結果披露動画でしかないからだ。価値があるとすれば「誰もまだやっていなかった方向性（作画設定にある詳細構造や全体バランスを可能な限り省略、変更することなく変形過程を再現できるモデリング）で、そこそこの質のレベルまでやっちまった」こと、「初志貫徹！口先だけじゃぁなかったんスよ」の一点に尽きる。理想は「やっちまった以上は、忘れられることなく、早く『クラシック』とか『マイルストーン』とか『リファレンス』と呼ばれるようになる」ことだ。だから、ちびちび再生され続ける状況はちょっと嬉しい、忘れられるのは切ない。そしてオリジナル（要は元ネタ）の放つ魅力は未だ凄い。

　「じゃぁ似た方向性で今後やってみたいことある？」と問われれば、「ファースト・ガンダム」かなぁ・・・「イデオン」でも同じ話にはなるんだけど。

　最近私のチャンネルをSubscribe頂いたLucyさんのチャンネル（Lucy の 3DCG World『不良番町 手八丁口八丁』）内の動画を観ながら、「次はザクだよ！旧ザクもだよ！」と思った訳ですよ。方向性はずばり「安彦ザク」。昨今の3Dとして成立しているザクではなく、最初のTVシリーズ画面内の「作画力で成立させているザク」の3DCGIによる再現ですよ！

　金属製のくせに曲がるわ捻じれるわ部品消えちゃうわ股関節の可動範囲がやたら広いわ、その癖画としては決まっている必要があるという超高難度、そして誰もそれはやっていない（エヴァ新劇場版では、ちょっとそういうところにも踏み込んでいるのかも知れないけど）。誤魔化さないのではなく、積極的かつ美しく誤魔化すためのモデリング、リギング、ライティング、カメラワークの追求！背景と前景の画角は当然僅かに違いますよ。モデルを伸ばすんじゃない、画角を変えて伸びるように見せるんです！これぞ手描きの妙の再現！

　とても今はやれんけど、志は案外高い。考えるだけでわくわくするのは世界で私一人だけですか？

　あと松本零士さんの「戦場マンガシリーズ」の航空機の3DCGI再現も！肝は水彩調の塗りでのアニメーションで、迷彩とかになると本当に面倒くさくなるんだけど、様々なマスクの切り方やレンダリングの順番、合成手順など実現性は一応確認しているんですよ。YouTubeが未だ無かった00年代前半の話なので、実はもうかなり忘れてますけど。

　二点目は個人的な微妙に知的かもなな興味だ。知っている人は知っているように、YouTubeでは３、４年前に「日本の80年代シティポップ（歌詞が英語、おっしゃれー（棒）」が主に海外でバズった。Future Funk（笑）にも一部繋がった動きだった。

　この現象に対する解釈、説明は米国人を中心に幾つか為されたが、個人的には「YouTubeのRecommendエンジンが起こした小さくて奇妙な振舞いをきっかけとして、視聴者とRecommendエンジンとの相互作用がバタフライ効果を起こした結果」としか見做していない。つまりコンテンツ自体よりもそのコンテンツがRecommendされた視聴者の反応の方が支配因子であるシステムの挙動の問題であって、コンテンツやその周辺状況の文化的・社会的分析や解釈にはほとんど意味が無いという立場だ。単に米国人にとってエキゾチックに聞こえただけだった程度の話ではないだろうか。

　現に、意味ある派生的な価値創出は無く（様々なバージョンの竹内まりやさんのイラストがちょびっとミーム化したくらいかな？）、結局はネット内で消費されただけに見える。昨年になってこの現象に触れた日本語コンテンツも出てきてたけど、周回遅れが常習の私より反応遅いって何年遅れですか、っつーか反応があればそれだけで儲けレベルのステマが大半っぽいなぁ。まぁ、若い人たちが聞く機会がほとんどなかった楽曲との出会いの機会が新たに創出されたのなら、それもそれで良しですか。iTunesなどの有名どころからは大抵の楽曲は入手できなかったんですよ、少なくともバズったころは。

　おっと、閑話休題。

　そして今回の件の動画の突然の露出も、そのようなRecommendエンジンのカオス的挙動下のものではないかと考えている。このため、アクセス解析データのダウンロードを始めた。落ち着いた（落ちた）ところでデータを分析してみようと思っている。いやぁ「日本の80年代シティポップ」周りのデータ、YouTubeが公開してくれないかなぁ・・・何本も論文が書けるんじゃないかなぁ。

　ちなみにFuture Funk（笑）とは言え、300曲も聞けば聞くに堪えるものの2、３曲は見つかりますよ。

Lightwave3Dモデリング、リハビリ着手！

　うつ症状向けに調剤されている薬は現在は１種、しかも昼間用１カプセル、サインバルタ（30mmg）だ。医者との相談しつつ使用０もにらんで減薬を進めてきた結果なのだが、この三連休で使用０を試し、現在２日目だ。案の定、所謂離脱症状にのたうっている。もう薬無くてもやれそう、という感覚は半年ほど前からあるのだが、この離脱症状ってのが曲者で色々と躊躇してしまう。まぁ、今回は様子見で、やめられそうと判断したら夏休が本番ということになるだろう。

　で、離脱症状について少々。

　まず所謂「ションビリ」、耳元で「シャンシャン鳴り続く」、指先が「ビリビリし続ける」という症状だ。実際には、聞こえる音は「微かなシャー」、ビリは指先よりも額から顎にかけて感じている。あと、車酔いしたような、ずっしりした頭痛とフラフラした感じがある。いやぁ、これじゃ車は運転できないねぇ。あと、面白い症状としてたまに感じる激しい歯痛、ポイントは痛む歯が抜かれていたり金属に変わっていたりと既に存在しないところだ。ファントムペインっぽいんだよね。それでもいざ起ればのたうち回るのは必至で、やっかいではある。

　ん、で、趣味の分野でも連休を生かしてリハビリ中。今回の主眼は３DCGモデリングだ。対象となるアプリはLightwave3D。

　Lightwave3Dの特徴は、モデリングに使うモデラーとレンダリングやアニメーション作成に使うレイアウトが別プログラムという点だ。両プログラムを立ち上げた状態でのモデラー上におけるモデル編集結果のレイアウト上のモデルへの反映は 、ハブと呼ばれるプログラムがバックグラウンドで行う。ハブは一種の通信プログラムで、ネットワーク通信プロトコルを使ってモデラーとレイアウトの２つのプログラム間のデータ授受を制御している。

　なぜこんなことを書くかと言うと、先のWindowsの大型アップデート以降にハブが上手く機能しなくなっていたのだ。昨日はその対策に追われたと言って良い。結論から言うと、OneDriveが悪さをしていたようだ。OneDriveはマイクロソフトの一種のクラウドデータ共有サービスで、当然ネットワーク通信を行う。極々まれなのだが、ハブの機能を使おうとすると（セットアップもしていない）OneDriveがログイン情報を要求してくることがあった。そこでOneDriveをアンインストールしたところ、現在は部は快調に動作している。

　と言う訳で、いよいよLightwave3Dでのモデリングに再挑戦の準備は整ったようだ。となると、次はモデリング対象をどうするかであるが・・・

　ここは何の迷いもなく、Angel Interceptor（古い方）に決定。理由はそんなサジェスチョンを電波で、いやパケットで以前に受けた・・・気がするからだ。コスモゼロに挑んだあとにがっくり調子を崩したことも踏まえ、調子を崩した前後に考えていたことから始めてみようということです。

　え、何？Angel Interceptorを知らない？白くて突き刺さりそうな機体、イギリスですよ、形からして十分変態。

　"White as Snow"をヘビロテしながら準備中。案の定と言うか、当然と言うか、撮影モデルも大きさによって微妙に形状が違うと言うか、三次元曲面処理が部分的に違うんだよなぁ・・・

三面図はWikipediaから入手できたしね。あ・・・（これは違う）。

　

TriumphのCGI TVCM

　Triumphと言えばまずブラジャー、商品開発については常に攻めの姿勢にある会社、というのが個人的印象。そんなTriumph、海外でのCGIを用いたTVCMは以前より評価が高いのです。実は私も大好きで、音楽も含め古き良きハリウッドミュージカル映画を彷彿とさせる作りだったりとかがたまりませんねぇ。

　

それは違う

　いろんな意味で「それは違う感」と言うか「何を今更感」が強い。この監督はやっぱり映像に関しては上手くない。本作においても「新しさ」みたいなものは皆無で、「既に手垢のついた手法の焼き直し」との印象が強い。情報密度も低く、かといって新しい視点も加えないでは、「なぜ3DCGなのか」という問いへの答えは作品に宿らない。

　要は、「3DCGはもはや手法の一つであり、それが積極的に選択された理由が当然求められる」時代の作品とは言えないということだ。「ふ～ん」で終わる値の張ったガラクタである。若い人達にとっての反面教師ぐらいの価値しかない、お金を出す側の人達は過去から学ぶという真摯さが無いようなので。スティーブン²も少なくともここまでは不甲斐ないばかりだ。

　スタンダードな手法ではなく映像作品の歴史から見れば既に飽きられた邪道とも言える手法を使いながら、何のひねりも無いというのはある意味究極の映像センス欠如と見える。ただでさえ素材は新しくないのだから、それ以外のところで何か光るものを見せてくれないとつまらない。

　このBGMを選んでおいて（既存のイメージ群に正面から戦いを挑むという意味でハードルを上げておいて）"Another"足らんとすれば、大量のパワーとイマジネーションを作品へ投入する必要がある筈だ。が、そんな点に気づいていないのかのような熱の無い映像には、観ている側が無力感に囚われかねない。これは高コストな同人誌的活動の域を出ない、つまりプロの作品じゃない。

　作家性が無いのは分かる、色彩も含めて映像的に創造性を志向していないのも分かる。最後のカットの色彩感覚やレイアウトの平凡さ加減は特筆に価する。上に噛み付く製作スタッフとか居なかったのかとも心配になる、もしそうなら今後も何も期待できない。

　evangelion: Another Impact

Krayレンダラーを試す！

　ＧＷ明けぐらいから３ＤＣＧモデリングにも再び取り組もうと思い、操作方法を思い出すべくLightwave3D 2015をいじっている。現状は既存のデータを読み込んでいじる程度だが、再開に備えて新たに２つのソフトウェアも入手した。ひとつはFusion 7、もうひとつはKray 2.5だ。

　Fusion 7は合成（コンポジット）ソフトウェアで、映画製作やＴＶ製作の現場で使われているソフトウェアの下位バージョン・フリー版だ。 この種の技術の進歩は日進月歩、現在の下位バージョンと言えば３～４年前の上位バージョンと出来ることはほとんど変わらない。趣味で使う分には十分過ぎる機能を備えていると言える。特に「素材作りの環境は既に持っているけど合成がね・・・」という人には導入コストが決して低いとは言えないAdobe Aftereffectsよりもお勧めする。なおフリーで利用できる合成ソフトウェアとしてはプロ向ツールNukeの非商用使用制限バージョンもある。以前に紹介したDAWソフトウェアProtools | Firstもそうだが、プロ向けツールのフリー版の登場はオープンソースソフトウェア開発コミュニティにとっては多少なりとも打撃となりそうだ。

　さて、出来ることがプロとほぼ同じソフトウェアを使うことの利点は、プロが発しているネット上のノウハウがそのまま使えること、メンバーにプロが多いネットコミュニティでの情報収集や交換がスムースになることなどが挙げられる。しかしFusion 7の導入は、これまでの「Lightwave3Dに始まりLightwave3Dで終わる」という私のワークフローをいったんガラガラポンすることにもなる。でも、だからこそ面白そうなのだ。FusionにしてもNukeにしても「レイヤー」の概念はもはや排除されており、その操作のフレームワークや思想は３ＤＣＧのそれらにむしろ近いと言える。

　KrayはLightwave3Dに対応したレンダラーで、試用版をいじり倒した結果購入を決めたものだ。Lightwave3Dのレンダラーは高速かつ仕上がりは綺麗だが、できないことや仕上がりに対して必要な手間というコストが割に合わないことも当然ある。ずばり、Krayの肝となる機能である「フォトンマッピング」が実現できることがそのひとつだ。

　３ＤＣＧおけるレンダリングとは、モデルの表面がカメラからどう見えるかをシミュレートするものだ。直感的なレンダリング方法としてまずレイトレーシングがある。これはモデル表面からカメラに到達する光の「軌跡」を計算する方法だ。至極当たり前の方法であり、理想的にはこの方法で問題無いと思うかもしれない。しかし、実際のところ有限の時間内で自然界の光の挙動をシミュレートするにはレイトレーシングは正攻法過ぎるのだ。例えばレイトレーシング計算では、光の反射回数を制限しないと計算が何時までたっても終わらない可能性がある。真っ暗な空間に点光源が複数しかないような特殊な条件でしか、（光の波動性が無視できるスケールに対して）レイトレーシングが厳密な結果を与えることは無い。実際、線光源や面光源は多数の点光源で近似するのが一般的だ。指向性の無い（等方的な）面光源はレイトレーシング向きではないが、これこそ私たちの暮らす世界では最も一般的な光源のひとつなのだ。

　空は青く見える、と言うことは空は青い光を放つ光源と言える。３ＤＣＧソフトウェア内の世界の中心に置かれたモデルから見れば、空は方向によって色や光の強さが変化する半球状の面光源だ。

　フォトンマッピング計算では光は「有限な」多数子の粒子で近似し、最初っから厳密には取り扱わない。光の強度のモデル表面への影響は、その表面に「ぶつかって『蓄積された』粒子の数に比例する」ものとして統計的に取り扱われる。フォトンマッピングのレンダリング結果は「カメラから見てモデル表面が（蓄積された光の粒子によって）どう輝くか」に相当する。ただし、統計的にエラーの少ない結果を得るためにはできるだけ多数の光の粒子を飛ばしてやらなければならない。だから「統計的に取り扱う」のは厳密にはレンダリング結果を得る段階のみの話であり、計算自体は「投機的」である。つまりフォトンマッピングは基本的に効率の良いレンダリング方法とは言えない。しかし、計算する膨大な粒子数というコストさえかけることができれば、いわゆるフォトリアリスティックなレンダリング結果を得られる。

　 リアリティに何が効くかと言うと、「照り返し」と「影のエッジのブレ」だ。両者ともに単に光の反射計算だけでは再現できないから、レイトレーシングでの再現には何らかのトリックが必要だ。でもフォトンマッピングが使えるKrayなら、計算する粒子数にさえ気をつけておけば静止画で変なレンダリング結果が得られることはまずない。下図はKrayのレンダリング結果だ。光源は太陽と空、白い面からの照り返しや影のエッジのブレもあっさり再現されていてちょっと感動してしまいましたよ。

次は合成、ライティング？

　昨夜TVで放送していた映画「聯合艦隊司令長官 山本五十六」は、映画としての出来はともかく、日本映画での３DCGの習熟度を計る上でひとつのマイルストーンだったと思う。

　日本の特撮映画において水、ひいては海は鬼門だった。水は表面張力という曲者のせいで代表的な物理的スケールがあり、そのスケール単独での縮小が不可能故にミニチュア特撮の敵と言える。ここで物理的スケールとは液滴や液塊、気泡の大きさや波の大きさと速度との関係などである。私達は水の挙動を経験的に知っているため、例えば球形で存在できる水の塊の大きさなどを基準に、画面の中の物体の大きさを無意識に測っている。ミニチュアがミニチュアに急に見えるようになる瞬間は、往々にして水がらみであることが多い。裏返せば、水側のスケールをコントロールしてやれば画面内の物体の大きさを錯覚させられると言うことであり、３DCGによる水表現によるトリックの肝中の肝と言える。 「聯合艦隊司令長官 山本五十六」は、この部分に関しては成功作と言え、感心もしたものだ。

　一方、煙とライティング（すなわち影）はかなり不味く、特にライティングはプロの不在を思わせる。水と同様に煙も物理的スケールを持っているが、物理シミュレーションで作成されているだろうから水同様にスケールの問題はほぼ発生していない。しかし、煙が自分自身に落とす影や透過度の表現はゲーム画面レベルの低次元のものだ。画作りのワークフロー上は合成（コンポジット）作業過程の不手際と言えるだろうか、本質はライティングのディレクション不在にあると思う。

　終盤の山本五十六搭乗機の撃墜CGシーンは完全にライティングで失敗している。影の不在は援護の零戦をミニチュア然と見せるばかりだし、そもそもライブアクションシーンのライティングともマッチしていない。山本五十六搭乗機の撃墜は、ブーゲンビル島上空、４月１８日の午前８時ごろである。ライブアクションシーンのライティングは日の出直後乃至は日の入り近くと思われるオレンジがかった低い太陽のものである。

　ところが、CGカットのライティングは方向が不明確で照度が均一、白色光である。このような状況は、現実には晴天時に存在しない。朝とは言え太陽光は強く、機体の反射光や照り返し光が飽和して画面上で白く抜けるような状態が現れもおかしくないのが現実だ。強い太陽光に照らされた機体があの明るさならば、空中から見えるジャングルは黒く見えなければならない。だが、画面上のジャングルは青々としていた。

　山本五十六搭乗機の撃墜シーンは本映画のクライマックスのはずだが、ライティングに関わる２つの問題のせいでそれがスポイルされている。一つ目はCGカットとライブアクションカットのライティングが一致していないこと、二つ目が上述のCGカットのライティングの不自然さである。欧米のCGインダストリーではライティングはクレジットされる専門職であり、プロフェッショナルな仕事が求められると言える。 映画「聯合艦隊司令長官 山本五十六」はライティングの出来にムラが大きすぎ、一貫性が無いのは返す返すも残念だ。

　さて、 ブーゲンビル島上空、４月１８日午前８時の晴天時の状態をシミュレートすると下の図の如くなる。太陽光が強いので、手前主翼端付近はほとんど輪郭が見えないぐらい一部が明るくとんでしまっている。また、光はややオレンジがかっている。ライブアクションカットのライティングは、やや照度不足と言う気はするけど、かなり正確と言えよう。ならばCGカットのライティングは出鱈目と言う事になる、残念ながら。

THUNDERBiRDS ARE GO!

　今月に入って本格的に動く画が公開され始めましたよ、"THUNDERBiRDS ARE GO"。

　レディ・ペネローペが微妙とか、ブレインのルックスにケレン味が無くなったとか思うところは色々ありますが、さて。ファイアフラッシュ号っぽい機体も見え、まずはリメイク路線と言うことでしょうか。

　ミニチュア（かと思う）と人形っぽい造形のCGキャラクターの組み合わせと言うのは 、とてもサンダーバードっぽい気がしますね。

３DCGを使った女性用下着の海外TVコマーシャル

　女性用下着メーカー「トリンプ」のMagic Wireブラの海外TVコマーシャルだそうです。

 「ＦＦ系ＣＧキャライラネ」な私としては定型的だけど好きなキャラ造形。単なる２Ｄ画の焼き直しでは無くて、実は表情が付けやすい（特に目と眉）という意味で結構こなれた造形なのです。

　作りは、ざっくりとディズニー映画と言うよりもハリウッド・ミュージカル映画、それもファンタジー寄りの作品の風合いです。ディズニー映画では「メアリー・ポピンズ」が近いのではないかと思います。あ、「メアリー・ポピンズ」とか「サウンド・オブ・ミュージック」とか３DCGの特性を最大限生かしてリメイクしてくれないかなぁ。

新規PC、届かず。

　「太平洋にハリケーン、船舶運航スケジュール乱れる」の報があって案の定、先週の今頃は太平洋上に出ていた筈のPCは届かず、当初20日だった配達予定日も未定になってしまった。PC更新は環境（ほぼインストールアプリケーションと同意）の掃除の良い機会で、準備万端整えてこの土日を迎えた訳だが完全に肩透かしを食らってしまった。ちなみに現行のDELL製PCもアセンブルは米国だったが、国際輸送が航空便だったのでびっくりしたことを今でも覚えている。

　しょうが無いので？、OctaneレンダーのLightwave3D用デモプラグインを入手してLightwave3D 11.6で今日は半日遊んでみた。OctaneレンダーはnVIDIA製グラフィックチップを使ったレンダラーで、購入検討段階にある。現行PCのグラフィックカードはnVIDIA Geforce GT630というロートルではあるのだが、96個の並列利用可能なCUDAコアを持つ。

　結論から言うと、「バージョンアップを待って再検討」。現在のOctaneはバージョン2.5+αで、Lightwave3Dに関しては統合自体には問題は無い。ただし、Lightwave3Dでこれまで作って来たモデルやシーンがそのまま使えるかと言うと、そうは問屋が下ろさない。実際に使ってみて、

• モデルの質感（マテリアル）設定は、Octane用に書き換えなければならない
• ４点以上の頂点を持つポリゴンが望むようにレンダリングされることは保証されない
• レンダリング時に必要なPC本体メモリの使用量はネイティブレンダラーより小さい

といった点が良く分かった。 速度はCUDAコア×96如きでは知れているが、それでも「インタラクティブビューにはやや非力かな」といったところだ。ちなみに、新規PCのグラフィックカードのCUDAコア数は1024だ。

　で、Octaneレンダーの次バージョン（octane 3）はこの夏にリリースが予定されている。ニュースリリースによれば、次バージョンには以下の機能が盛り込まれる。

• OpenCLサポート
  これは、GPUがnVIDIA製で無くても良いと言う事だ。AMD、IntelのGPUも使える可能性がある
• FBXフォーマットサポート
  Lightwave3D上でモデルの質感（マテリアル）設定は、Octane用に書き換える必要がなくなるかもしれない

という事で 「バージョンアップを待って再検討」となった訳だ。

PCをアップデートするよ！

　これでも8年前まではPCは自作していた。コンバット・フライトシミュレータとかやっていたから、今で言うところのゲーミングPCでも上のレベルの性能を追求した。CPUのオーバークロックは当たり前、CPUを買うにも製造番号（同じCPUでも製造工場によってオーバークロック耐性が違っていたりしたから）までチェックしていた。

　が、歳をとってゲームをしなくなり、また自作することによるコストメリットも薄れて来たあたりで「DELLで良いや」って感じになってしまった。今使っているPCはDELLのデスクトップで、7年間以上トラブルらしいトラブルもないまま現在に至っている。欠点と言えばハードディスクのデータ転送速度が元々低かったことで、メモリ増設である程度はカバーできたもののボトルネックであることには変わりない。ちなみになぜDELLかと言うと、「DELLは１０年後もPCビジネスをやっている」という根拠無き直観に基づくもので、少なくとも８年は直観通りだったということだ。

　さて、車もそうだったのだが、それなりに高価な買い物は私の場合はほぼ間違いなく「半ば衝動買い」である。「半ば」という意味は、「欲しいっ！」という衝動には一切応じないが、「買うなら今だ！」と言う自分の直観（ゴーストの囁き？）には素直と言う事だ。まず「欲しいっ！」があって、それをいったん忘れて、然るべき時期が来れば虫の知らせのように「買うなら今だ！」という精神状態が突如やって来る。大抵は３～４年忘れている。

　今回のPC購入の決断も、と言うか決断すらしたのかも怪しい。会社で仕事中にふと「さぁ、PCを更新しよう」と思い、退勤後に自宅でDELLのサイトにアクセス、15分ほどで購入手続きを終えてしまった。今頃は太平洋上を日本に向かっている筈である。購入モデルの選定では、SSDドライブを使うかどうかと搭載メモリサイズの２点だけはちょっと悩んだが、それも本当にちょっとだけ。何故ちょっとかと言うと、事前に何も調べていないんだからそもそも判断基準が無い訳で、悩むこと自体が無理なのである。

　こんな調子なのだが、後で色々調べてみたらなかなか自分のニーズにマッチした構成になっているのがある意味恐ろしい。と言うか、私の人生は万事そういう感じなのである。ちなみに購入モデルは何かのキャンペーン対象品で（在庫処分扱いとは別。おそらくホビーユースには値段が高く、プロユースには性能が不足、かつDELL内のゲーミングPCブランドAlienwareとも構成が被るので売りにくい商品なのではないかと邪推）、CPU価格以上の値引きというオマケ付きだ。

　新規PCへの要求は、まず（ホビーユースの範疇で）長整数及び倍精度浮動小数点演算速度が高いCPUを搭載し、周辺機器がその足を引っ張らないことである。この要求は主に２つのニーズに対応している。

　一つめのニーズは、DAWであるCubase使用時の私へのストレスを下げること。

　使った事の無い人には分からないと思うけど、DAW起動中は常にCPUに一定以上の負荷がかかっている。音楽製作ツールであるDAWはリアルタイム音響生成・合成処理が基本で、アプリ操作者の操作に即座に反応する必要がある。リアルタイム処理という点ではソフトウェアシンセサイザーも同じで、それなりにつくり込んだデータをCubaseにロードしただけでCPU使用率60%は当たり前となる。CPU負荷を下げるため、これ以上は編集しない演奏データはフリーズ（演奏結果を音声データとしてディスクに書き出し、以降はリアルタイムの音声合成処理はせずに書き出した音声データを再生する）するのだが、ここでハードディスクのデータ転送速度が低いことが現行PCではボトルネックになっている。CPU使用率或いはディスクアクセス負荷の何れかが再生中に一瞬でも100%となると、ほぼ半々の確率でCubaseはクラッシュするし、場合によってはハードディスク上のデータまで破壊する。

　Cubase設計者も馬鹿ではないので、ハードディスクからの音声データ読み出しは巧みにスケジューリングされている。しかし、例えばPiapro Studio（ボーカロイド・エディターの一種）といったプラグインがどのタイミングでディスクからデータを読み出すかまではCubaseは知ることができない。故に、Piapro Studio上でボーカロイドデータにブレス音（息継ぎ音。ボイスバンクと呼ばれるボーカロイドの音声ライブラリには含まれず、独立した音声データファイルとして提供される）を追加した途端、クラッシュが頻発するといった状態になり得る。また、フリーズデータが大きくなれば、いずれリアルタイム処理に必要なデータ転送速度がハードディスクの最大データ転送速度を越えてしまうのも必然だ。

　上記のブレス音の件は原因究明まで時間がかかったが、色々と得るものもあった。代表的な知見は、「Piapro Studioではトラックにブレスが含まれている場合、トラックがミュート状態でもハードディスク上のブレス音データ読み出し処理をする」だ。Piapro Studioを使っていて、急にホストDAWのクラッシュが増えたり、再生時のノイズが増えたりした場合、Piapro Studio上でのブレスの使用を疑う価値がある。少なくともCubaseの場合は、ブレス音は音声ファイル自体をオーディオトラック上に置くか、Groove Agentなどのサンプラーのパッドに割り当てて使うか（大抵の場合、音声データはメモリ上にロードされる）の何れかにした方がクラッシュの防止という観点からは良い様だ。

　もう一つは、3DCGアプリであるLightwave3Dのレンダリング時間の短縮だ。レンダリングというのは、モデルを配置、照明やカメラを設定した後の「画を計算して得るプロセス」である。これはCPUの演算速度がダイレクトにモノを言う。

　現行PCのCPUはIntel Core2 Quad 2.66GHz（4スレッド=4並行処理）、現在太平洋上の新規PCのCPUはIntel Core i7 3.6GHz（4コア、8スレッド）だ。ネット上を調べると、同じデータを様々なPCやMacでレンダリングした際のレンダリング時間を互いに報告しあっている海外スレッドがあった。報告者の何人かはメールやメッセージをやり取りしたことのある人間で、カナダのVFX業界のフリーランサー達だ。さすがに飯のタネだけあって、彼らの使っているPC、と言うかWS（ワークステーション）の仕様は凄くて、8コアCPU×2=16コアはもはやお約束だ。しかも十中八九DELLだ。

　さて、フリーランサー達のWSでレンダリング時間40分のデータ、現行PCと購入PCで予測されるレンダリング時間はどうだったろうか？公平を期すためにOSはWindows 7 64-bit、メモリは16GB（新規PCのメモリ搭載量は32GB）のPCに絞って報告されているデータを集計してみた。結果は、現行PC相当の仕様のマシンで9時間～11時間30分、新規PC相当の仕様のマシンで2時間～2時間40分となった。ざっくり、1/3以下のレンダリング時間短縮が見込めるということだ。この差は実は大きい。

　もしあなたがサラリーマンなら、1日8時間程度は会社に居るだろう。現行PCで24時間かかるレンダリングを実施する場合、現行PCでは翌日にならないと結果が分からないが、新規PCなら出社時にレンダリングを開始すれば退社時に結果が確認できる。結果も見てミスを発見しても、細かなミスならば退社までにデータを手直しして再レンダリングしてしまえば、翌日の出社時には望む結果が得られているだろう。レンダリング時間の短縮はユーザーのワークフローの自由度向上に効くが、やはり1/2以下ぐらいまでは短縮されないと「劇的な効果」は得られない。

　Lightwave3Dではレンダリングに割り当てるスレッド数を制限できる。だからスレッド数は全スレッド数の半分しか割り当てないと言う様な使い方ができる。これまではレンダリングには全スレッドを割り当てていたのでレンダリング中はメールチェックぐらいしかできなかったが、新規PCではレンダリング時間を従来以下としつつ、レンダリングしながらも現行PCのフルパワー状態以上のCPUパワーが享受できると見る事ができよう。やっぱり両者の差は大きい。

　加えて、新規PCのCPUは十分な能力のグラフィックチップを内蔵している。

　3DCGのレンダリング処理は並列化処理に向いているので、やはり並列化処理に特化したグラフィックチップ（GPU）によるレンダリング演算はプロユースでは既に一般化しつつある。Lightwave3Dデータに対応したGPUレンダラーも既に存在し、レンダリング時間がCPUのみの場合の1/30以下という結果も得られている。つまり、Lightwave3Dが本格的にGPUレンダリングをサポートするようになれば、画面表示はCPUのグラフィックチップに任せ、「レンダリング演算専用のグラフィックカード（或いは一昔前のTeslaのような並列演算専用カード）」を挿す、なんて贅沢も可能となるんじゃないかなぁ…と思う。

　ちなみに新規PCのデリバリー予定は１週間後だ。来週の土日は新規PCの環境整備で潰れそうっすなぁ。