プロジェクトは未だ終わってもいないし、辞めてもいない。2160pのオリジナルのイメージはこちら(グーグルドライブ)からどうぞ。
片や、Future Funkの文脈でこんなのばっかり聞いていた時期も・・・
プロジェクトは未だ終わってもいないし、辞めてもいない。2160pのオリジナルのイメージはこちら(グーグルドライブ)からどうぞ。
片や、Future Funkの文脈でこんなのばっかり聞いていた時期も・・・
エントリタイトルが全てを語る。「bingでエゴサする」という「3年に一回×2年に一回」レベルの稀な振る舞いをしてみたところ、https://www.scifi3d.net/というブログを見つけた。
このエントリを書いている時点で、最新エントリは”Download The Ouroboros/Galactica Battlestar for DAZ Studio”(DAZ Studio用のウロボロス/ギャラクティカバトルスター(のメッシュファイル)のダウンロード)、日付は今年の5月だ。
私が公開しているウロボロス/ギャラクティカバトルスターメッシュデータは旧型のLihghtwave3D形式のみで、当然ながら他の3Dソフトウェアでは読み込むことすらできない。かたやLightwave3Dを使っても、仕様変更が原因で新しいバージョンでは当時私が意図した通りの画は再現できない。メッシュデータの他のソフトウェア形式への変換(コンバート)は、理由は割愛するけれどもそれ自体難易度が高く、面倒臭い。正直、情熱とかモチベーションを喚起する何かが無いと完遂自体が無理だと信じている。
先のサイトで目にしたレンダリングされた画像は、「当時の私の頭の中にあった完成像」そのものだった。素晴らしい出来だとまずはシンプルに感動した。変換した方の費やした時間、努力や労力、そして見事な変換を成し遂げてくれた胆力・情熱に感謝したい。そして、公開されてから10年以上経っても他者に触ってもらえるデータを作り得た当時の自分の中の情熱も誇りたい。
昔々に作ったVF-1Aの3Dモデルのリグのテストを10年ぶりぐらいに実施・・・と言うのは嘘で、単に突然やりたくなったのでバトロイドモードで色んなポーズを取らせてみた。
ここでリグと言うのは3Dモデルに組み込んだ骨組みみたいなものだ。各骨の動きを特定の部品とリンクしておくことで、骨の回転や平行移動などの操作によって3Dモデルの変形やポーズ付けが実現できる。ちなみに10年以上前に組んだリグの骨(日本語ではボン又はボーン)の数は100を超えていて、ファイター、ガウォーク及びバトロイドのモード相互の変形から各指の動きまでサポートしている。またスクリプト機能なども使い、多数の骨を然るべきタイミングで動かす必要があるモード間の変形過程を、単一のヌルオブジェクト(Null、位置や回転などの情報を持つだけの不可視の物体)の回転操作だけで実現できるようにまで作り込んでいる。
10年前の自分のこの種のモノに対する熱量と言うかこだわり具合は、「異常」という意味で我ながら「おかしい」と思ってしまうレベルだ。
で、バトロイドモードで取らせたポーズは20種は下らないのだが、元ネタが分かりにくいもの(例えば大友克洋氏のマンガ「童夢」のチョウさん、「そうだよ、ボクだよ」のカット。ふわっと浮き上がった状態を表す地上に落ちた影と左手の表情が拘りどころ)や、オリジナル作品中のポーズの再現といった今後使えそうなものを除いた3つをここで挙げておきたい。挙げておきたいから挙げておく、っつーだけの話。公開済みの別動画に組み込まれることで「没カット」のフェイクとしての役割は果たしていて既にお役御免の画達なのだが、単なる小ネタのつもりが割と気に入っちゃったんだよね。
まず、自動運転機能を持つ大型人型兵器の最期を飾るビームライフル射撃直前のポーズ(のつもり)。頭部と左肩の骨のスケールを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倍強というと微妙な感じもする人もいるだろう。だが一般的なサラリーマンの1ヵ月あたりの出勤日が約22日であることを考えると、1日の出勤だけで給料一ヵ月分貰えるような「比率」ではある。3週間かかっていたレンダリングが1日で終わる。丸1日かかっていたレンダリングが1時間ちょっとで終わる。特に前者の場合は、私なら以前は絶対やろうとしない条件だ。とは言え、"Enough is not enough"なのが人間だ。そんな人こそレンダーファーム・・・なのかな?
レンダーファームとはレンダリングのためのCPUパワーのレンタルサービスや、そのためのハードウェア・ソフトウェア環境を指す。歴史をすっ飛ばして現状だけ見れば、クラウドコンピューティングサービスの一種と見做せるんじゃないかと思う。要は自分のPCの代わりに、レンタルした並列計算環境にレンダリング計算をしてもらうサービスだ。時間をプロダクションコストに含めなければならないプロフェッショナルの世界では、昔から必須のサービスだ。また、フリーランスの3DCGIアーティストが自己宣伝用デモリールを作る際に、仕上がりをプロフェッショナル級にするために使われることもあるようだ。
で、いくつかのレンダーファームサービスの価格を調べてみた。結論から言うと、良くも悪くもサービス提供元による価格差はほとんど無かった。もう少しばかり定量的に書くと、円-ユーロ、円-ドルの為替レートの変化でどこのサービスが一番安いかが変動するレベルの差だ。と言う訳で、米国ベースのとあるサービスの簡単見積りページで価格を見積もってみた。条件は、私のメインPCでレンダリング実績のある以下の通りとした。
ここでは、CPUを特定し、そのCPUでのレンダリング時間を与えている。サービス提供元のノード又はCPUの計算能力と特定したCPUの計算能力との換算が妥当ならば、かなり正確な見積りになるのではないかと思う。ノード並列数には特に意味は無いが、レンダリング枚数を超える意味が無いことと、レンダリング枚数の約数であることは意識した。優先度というのはざっくり実行順で、お金を積んで「高」とか「最高」にすれば、「普通」の他ユーザーの計算を止めてでも先に計算してもらえるようになる。
見積り結果は以下の通り。
実効計算時間はノードの性能から妥当な感じ、使うとしても全く文句は無い。データのアップロード、ダウンロードを含めたターン・アラウンド・タイムは15分ぐらいだろうか。生成され、ダウンロードするデータの量は多いが、これらデータの一時保存などのコストは見積りに含まれていなかった。まぁ大抵はそのためのネットワークストレージサービスを別途契約しておいて、レンダリング結果はレンダーファーム側が適宜書き込む形にすべきなのだろうけれども。
対して価格だが、これが微妙。趣味かつ作成動画からの収益無し、という条件下ではやはり高値感がある。せめて半分、ただ¥300+消費税なら使うかもしれない。ちなみにCPUの最大TDP60WでメインPCを10時間全力駆動した場合の電気代の「増分」は約¥16-で、計算する前の予想よりは安かった。結局のところ、レンダリング時間である10時間が「睡眠時間+アルファ」又は「出勤で部屋のPCに触れられない時間以下」なので、金を払ってでも取り返したい時間になかなかならないのが高値感の原因だろう。
レンダリング時間が更に100倍になる辺り・・・価格¥13万-以上・・・からがレンダーファーム利用の本領発揮ラインだろう、というのが今回の感覚的な結論かな?200並列ならば「40日後の結果を今日の午後に得られる」となるが、こうだとさすがに価格の見え方も変わってくる。場合によっては「40日後に得られる予定だった結果を見ることで、40日後に得る筈だった新アイディアを今日の午後に得られる」なんてこともあるかもしれない。後者の場合、本来無かった筈の40日も別途購入したようにも考えられなくもなくない?
長時間駆動を前提とした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年と言うべきかはなかなかに難しい。あ、あとソフトウェアであるレンダラーもマルチコア前提で変わっているんだよなぁ。
なお、動画作成は前回も今回もAdobe After Effects CS5を使った。ここだけは10年以上を経ても変わっていない。音声は2010年版のYouTube動画から抜いたものをDAW上で軽く手を入れて用いた。モコモコした感じが若干抜けて、音がややクリアになっているのではないかと思う。ちなみにYouTubeにアップロードする前の2010年版動画は、ハードディスククラッシュで他の多くのデータとともに未来永劫失われている。
で、2010年版。
と、2021年版。