お品書き…

- 2026.9.6 Sprite Motion Gallery を新設しました -----------------
- 2026.8.19 案件追加 AE・C4d L トラブル対策案 -----------------
- 2026.5.4クソゲー後日談2 -----------------
- 2021.5.15 楽しい効果音づくり -----------------
- 2018.11.3 デジタルは5Vにあらず・入力編
2026.6.25
プレミア秘境の歩き方専用ページ掲載 -----------------
CINEMA 4D Liteやってます
2026.8.23 new
【オーディオスペクトラムと同期させる】
2026.8.14 new
【音楽と同期させる】
2026.7.24
【4次元的思考で波を作る】
2026.7.3
【雨の波紋を 3D化する】
-----------------
はじめての PIC

―― produced by D-space Keyoss

2026年 9月28日(月)31℃(午後 6時 4分)
懐かしの実験器具
連発して猛威を振るう台風や豪雨。このたびの大雨や台風により被災された皆様に、心よりお見舞い申し上げます。
荒れ模様の天気が続きますが、一日も早い復興と平穏な日々が戻りますようお祈りいたします。
こんな荒天のなかですが、今週も『デジタル降魔録』をお届けします。
パースガイドツールをきっかけとして、春から夏にかけて実験的な映像ばかりが続きましたが、裏では教材用のパーツもコツコツと作っていたのですよ。
keyossにやってくる内容は理数系の依頼ばかりです。そのなかでも理系のものが大半を占めており、あとは幾何学系や力学的なものとなっています。
幾何学や力学的なものはほとんど作図か 3D物体の絡み合い(どんな状態?)ですが、理系のものには説明に使われる道具類から作らないといけませんので、かなりの時間を費やすることになり、時間に余裕のあるときに、コツコツやるしかありません。
たとえばこれなんかは、各種の説明で使用可能な【教材用の 3Dイラスト】です。これらの機材・器具は写真ではなくすべて手作り画像ですので、お間違いのないようにお願いします。
もちろん実物のサイズと比率をそろえるのは当たり前のことですが、難しいのは形を作るよりも透明な物体のありかたですね。理科の器具にはガラス製品が多いので、ほとんどが透明です。でもしっかりとそこに存在しないと器具ではなくなってしまい、かといって不透明なものにすると、すりガラスのようになってしまい、やはり器具から離れてしまいます。コツは光の反射と一部に偏った不透明さですね。
……と、制作ノウハウはこのへんにしておいて、せっかく理系の話題に切り替わりましたので、今週は理科の教科書を開いた気分になって、もう忘れていたけどそうだったよなぁ、となる話題を三つほど拾ってみました。
まず一つ目。
当時は何とも感じていなかったのに、今になって思わず首をかしげてしまうもの。
このサイトを訪れていただく方の多くは、電気系が好きだと思うのですが、この二つの違いが分かりますか?
機能は全く同じ電圧計です。差し込みプラグ(バナナプラグ うわ、懐かしい)を差し替えることで 3V、15V、300Vまでの電圧が測れるようになっていますが、使い方がまるで正反対で、コモン端子の扱いが "-" と "+" で真逆になっています。
実務(現場)で使う場合は、黒端子を GNDにつなぎ、測定電圧に合わせたプラス端子に差し込んだプローブで測ります(右側の電圧計がそれです)。
ちなみに GNDを安易に "-" だと宣言しないのは、"-12V" とか、"-5V" とかマイナス電源が混在する回路もあるからです。
ですから "電池のマイナス" とか、"バッテリーのマイナス" だとかを聞くだけで、お尻のあたりがモゾモゾしてしまう人は、ワタシと同じ電気系のエンジニアとお見受けします。(マイナスっていっても GNDから見たらただの 0Vだし……)
という理由があるのに、学校で使われる電圧計(左側)はなぜか 赤端子を "+" に固定接続しておき、黒端子をあちこちの測定場所にあてるという謎の仕様になっています。
なぜ逆なのか、 "-" は基準電圧(GND)となるので、余計な抵抗分が入るのはご法度なのに。いま考えるとなぜこうなっているのかよく解りません。
電流は "+" から流れるというイメージを直観的に見せるためだとしたら、これは電子の流れる方向と電流の流れる方向が逆なのに、「あほか、いまさら『実は逆でした』って公表してみぃ。教科書も学会も世の中ひっくり返るワ!」
と、みんなでしら~と黙っているようなことなのでしょうか?(これ本当ですので、ぜひ調べてみてください)
あんまり毒を吐いていると、こわいプロデューサーさんから電話がかかってくるといけませんので、さっさと次の話題に……。
懐かしい画像が続きますが、これは豆球を乾電池 1個で点灯させたときと、直列で 2個接続したときに、それぞれの回路を流れる電流を測ったときの画像です。
電池を直列に 2個つなぐと電圧が 2倍になりますので、右の回路には 3Vの電圧が豆球の両端に掛っています。
ここで懐かしい言葉を……。
オームの法則です。
オームと聞いて、腐海の森の番人(王蟲)を思い出した人。それはそれで正しいです。あの話のマンガ版ではまだ続きがあって……。
おっと、口が滑りそうになりました。危うくジブリさんに怒られるところです。気になる方はぜひ原作のマンガを読んでみてください。
ここでの オームは、ゲオルク・オームさんというオッサン、あ、いえ、師匠が発見した法則のことをいっています。
この師匠が 1826年に、「電圧と電流と抵抗値には、マジで比例関係がおまっせ!」と言い出したのですが、
「あほ、そんなことワテがとっくに知っとったワ」と草葉の陰から訴えるのは、ヘンリー・キャヴェンディッシュおじさん。(こんな大阪弁だったかどうかは責任を負えません)
「そやけど、おまはん。発表せずに天国行きはんたんやろ。そのあとでワシが見つけたんやから、オームの法則でエエやんけ」
「くっそぉ~、悔しカルカルやなぁ。お前かって今じゃ天国やんけ」
「あったりまえや。21世紀まで生きとったら、それこそ……オージョーしまっせ」
「なにが往生や、オマエ仏教とちゃうやろ。神さんからバチ当てられんデ!」
てなことを書き続けるので "このサイトは長くて読むのがしんどい" といわれるんですよね。ということで……。
はい、これがオームの法則です。
「どこがーっ!」
長くなりますので、話を戻します。
オームの法則によると I(電流)=E(電圧)÷R(抵抗) となって、抵抗値が同じなら、電圧が倍になれば電流も倍になるというものですが、画像の電流計を見てください。
1.5Vのときが 0.167A(167mA)です。なのに、2倍の 3Vにしているのに 0.255A(255mA)となって、2倍にはなっていません。
「そんなあほな! わての考えが間違っとった、言いまんのか!」と師匠が激怒するかもしれませんが、これは紛れもない事実です。
かといって、ワタシが画像を作成するときに間違えたわけでもありません。これが現実で起きる、机上の計算が狂った瞬間なのですね。エンジニアの皆さんはこんなことは日常茶飯事。むしろ法則どおりにはいかないことが多い、という現実に向き合っておられるはずですので、こんな話を読んでもニヤニヤするだけでしょうね。
すっかり忘れていた方、あるいは現在勉強中の方にお伝えします。現実とはこんなものです。というか、現実の中には隠れた変数(誤差)があるものなのです。
フィラメント式の電球は電気を流すと熱を放出して発光する仕組みであることを思い出してください。
温度が上がるとフィラメントの構成原子が激しく振動し、電子の流れをジャマし始めます。つまり温度が上がると抵抗値も上がり、電流が流れにくくなるのです。
その結果、オーム師匠のおっしゃる通りの結果にならなかったというワケで、発熱の影響を抑えるように作られた金属皮膜抵抗などを使った直流回路では、ほとんどオームの法則どおりになります。
念を押しますが、ここも "ほとんど、ほぼ、だいたい" ですから、ひとまず覚えておいてください。
とにかくこの熱というのがとても厄介なもので、パソコンの進化が頭打ちになりかけているのも、だいたいこいつのせいです。
では最後の問題です。
あれ? いつの間にかクイズになっていますが……ま、いいっか。
この画像は、先ほどのオームの法則が正しいかを検証する回路です。各抵抗に流れる電流を測りつつ、8Ω の両端が何Vになるかも同時に測れるようにしていますが、なぜか各測定器の数値が無茶苦茶です。さて、回路のどこが間違っているでしょうか。
答えは宿題。来週までに職員室に提出してください。
忘れたら立たしますよ……( ̄◇ ̄) アホ…
2026年 9月20日(日)31℃(午後 4時40分)
夏の清算
関西は雨が降ったり曇ったりを繰り返して、まるでストライプ模様の空が横に流れてくるような天気が続いていましたが、ようやく青空が広がり、気温も幾分下がった様子で、こりゃぁ、いい気候になったんじゃないの? と外出してみれば、なんのなんの、秋空なんてはるか遠くの地の果てで迷子にでもなっているのか、それとも "夏男" の野郎が幅を利かせて、"秋子" ちゃんのジャマをしているのか、なんならワタシが出ていって文句の一つでも言ってあげようかしら。
「こら、夏男! そこをどいたれや、秋子ちゃんが困っとるやないか!」
てな感じの陽気が続いていますが、それでもなんとなく秋の気配が漂い始めてきましたので、ここらで小難しいデジタルの話は一旦忘れて、今年の夏の清算をしてみようと思います。
まず、水銀体温計の結果を発表しなければいけませんね。
なんだそりゃ、と思われた方にご説明します。
仕事柄、運動不足を解消するために日々ウォーキングに精を出しているのです。何しろ朝から晩までキーボードを叩く日々ですから、これが刀工なら、
「いつまで叩いてるねん。もうブリキみたいにペラペラやんけ!」と親方に叱られるぐらい叩いてます。
そこから無理やり引き離すためにウオーキングをするようになりました。
という経緯から、夏場のワタシはリュックに "水銀体温計" を忍ばせているのです(詳しいことは こちら)。
「意味不明……何のために?」
ですよね。そう思われて当然。
その理由は、その日の最高気温を廃棄寸前の昭和の道具で測るためです(水銀体温計は一度上がるとそれを維持します)。これもSDGSですかね?
たぶん違うでしょうね。
ということで、今年の夏の最高気温(私的な行動範囲10キロ圏内)の第一位は……。
7月18日の 39.5度でした。
おそらくこの先季節が進んでもこの気温を超えることは無いと思われますので、この日が私的環境での第一位です。
第二位は僅差で、
8月19日の 39.3度です。
この日は真夏の 10キロ遠征を決行したときです。出発間際は曇天で、これなら暑くないし、なんなら雨でも降ってくれたほうが涼しくていいや。なんて思って出かけたら、途中からピーカンの青空にどんでん返し。曇天だけにドンテンかえし……ウマイ! ペラペラのせんべい座布団一枚ください。
公園を見つけるたびにタオルを水でビシャビシャに濡らしつつ、そのタオルを頭に載せて、しずくがポタポタ垂れても気にせず歩きました。すれ違う人もその姿を見て驚く様子はなく、それよりも少し羨むような、あるいは憐憫のまなざしを感じたのは、やはり異常気象のせいでしょうね。
ちなみにこの "水冷式頭部冷却装置(おおげさ)" は快適で、あの炎天下の中 10キロ歩けました。その代わり Tシャツもジーパンも濡れ濡れですが、これももしかするとよかったのかもです。ただし見た目はやばいおっさんです。
驚くべきことに自宅に戻ったときには全部乾いていましたから、これも異常気象のなせる業です。
そして、その夜にリュックから出して見た体温計が指していたのが、先ほどの写真です。体感的には 40度は超えていたと思っていたのですが、第二位でした。
しかし、いろいろなホームページはあるでしょうが、水銀体温計の写真をまじまじと見せつけるサイトってどうなんでしょうね。しかも使い方がおかしいし。
続いて 7月13日 に神社で拾ってきた種、その後です。
な~んにも変化なし。強いていえば、すこし薄皮に白い筋が出てきたぐらいでそのほかは何も変わったところはありません。
それぞれの写真で比較してみました。
左が拾ってきた二日後に植えたもので、右が現在の状態。いくぶん大きくなったような気がするのは……期待感の現れでしょうか。なにしろ出所が神様的な場所ですから、そう簡単には発芽しないのでしょう。
干からびて心配だった田んぼ、その後。
はい、このとおり、しっかりとお米が実っていました。これでひとまず安心しました。
日陰を抜けて通る風は秋らしくなってきたシルバーウィークど真ん中ですが、まだまだ 30度超えの気温が続きそうです。いいかげん "夏男" にそこをどいてもらわないと、マジで "秋子" ちゃんの出番が無くなりますよね。
すぐそばでは、"冬代" ねえさんが待っていますから、いい加減にしないと、
冬代ねえさんが怒るとこうなります。
ああぁ。また凍えながら歩く日々がやってくるのでした……。
うう、寒ぶ…… ( ̄ω ̄!) 気が早いって……。
2026年 9月13日(日)29.5℃(午前 7時15分)
続いて After Effectsで APNGを作る方法
APNG、アニメーテッドPNGですね。GIFアニメーションに変わって進化した、高画質で透明処理もできるアニメーション用の画像フォーマットです。
APNGの利点はなんたって、Webサイトで使用している画像ファイルと簡単に置き換えられる点ではないでしょうか。ふつうにファイルの拡張子までそのまんま『PNG』ですから、 imgタグを使って記載するだけで、入れ替えができるというスーパーフォーマットです。LINEのスタンプもAPNGなんですよ。ほんと素晴らしいですね。
と、ワタシがこれだけ絶賛するときには必ずオチがあります。
APNG自体には何の制約もないのに、mp4などの大規模な動画フォーマットと比べると、規模が小さくなりがちです。
中でも LINEスタンプの利用環境では "ファイルサイズ1MB以下"、"最大20フレームまで" といった厳しい制約があることも多く、普段見慣れた数千フレームのアニメーションと比べると、逆に戸惑ってしまいそうな極小フレーム数です。そのせいか、フレームとは言わずに "コマ" という呼び方が浸透していますね。
他にもLINEスタンプの制約には、画像サイズが 幅320 × 高さ270px 以内というのもあります。でもそんな小さな規模でもやり方によっては、思わず目を留めてしまうこともあるのが、スタンプのすごいところです。
ところが、Webサイトを対象にすれば、この制約は全部無くなります。AEを使ってアニメーションを作り、APNG Assemblerを経由して作れば、4Kサイズの APNGアニメーションだって作れます。直径 2メートルの巨大ハンバーグみたいなものができあがりますね。
ということで、さっそく……。
そして 4Kサイズの APNG作成を強硬した結果。
想像ですが、おそらく……。
AEで 60fpsの 4K(3840×2160px)の連番PNGを作ると、
とんでもなく大量のファイルが吐き出され、ストレージ悲鳴!
ムリやり APNG Assemblerに突っ込んで起動したとたん、
CPUとメモリが限界寸前で使用率100%になり、PC爆音!
奇跡的に完成したとしたら、
ファイルは 1GB超えの APNGなので、開いた瞬間にブラウザ即落ち!
と、まあ、大惨事になるでしょう……。
やってみる? ( ̄ω ̄!) アホです……。
正しい方法で APNGを作ってみたい方は、 "Sprite Motion Lab【APNGを作ろう】" をご覧ください。
2026年 9月 8日(火)29℃(午後 4時12分)
今度は スプライトシートを After Effectsで 作る方法
After Effectsで作成したアニメーションを、一般的な動画ファイル(MP4等)が使えない環境(ゲームエンジンや Web素材、アプリ内など)で動かす際、連番PNGだと大量のファイル管理や読み込み処理が大変になります。
そこで役立つのが「スプライトシート」です。全フレームをたった 1枚の画像データにまとめられるため、ファイルの管理や配布が格段にラクになります。Unityなどのゲームエンジンでの利用はもちろん、高画質なアニメーションPNG(APNG)への変換など、マルチに使い回せる素材として非常に便利です。
そんなスプライトシートを After Effectsで作る方法です。そもそも After Effectsにとってアニメーションなんか朝飯前の作業ですから、この方法と併用することで、これまでなかったようなスプライトシートが手軽に作れるようになります。
詳しい説明はSprite Motion Lab【AEでスプライトシートを作ろう】をご覧ください。試作素材の無料配布も行っています。
朝飯前のくせに、
なかなか終わらないのはなぜ? ( ̄ω ̄!) アンタが悪い…
2026年 8月31日(月)35℃(午後 2時20分)
スプライトシートを After Effectsで 使う方法
スプライト(Sprite)について詳しく知りたい方はこのままお読みください。
それより先にどんなものか見てみたいという方は Sprite Motion Gallery へどうぞ。
むかし、むかし、その昔……。
パックマンが全盛だったころのお話です。
4MHzほどのクロックで動いていた CPU 1個に、システムの全パワーが注ぎ込まれていた当時のゲームたちには、ゲームキャラを動かすのはとんでもなく負荷の掛かるものでした。
なにしろ、効果音を鳴らしつつ、操作レバーを検知してキャラを操り、お金が投入されたらクレジットに加算をして表示も更新します(お金の通貨は数十ミリ秒~百数十ミリ秒など、コインセレクターによっていろいろ)。その間に敵キャラも動かしてゲームも進行させる、すべてがリアルタイムに動かなければ、アミューズメントマシンとして成り立たないシステムです。
お金を投入したのに検知漏れが起きたら大問題ですし、キャラの動きと音がずれてもゲームは台無し。人間が操作するパネルの動きにも数ミリ秒でも遅れてはいけない。地獄のような仕様です。
当時のゲーム機のキャラはパラパラマンガみたいに、2~3枚のドット絵パターンを交互に切り替えて動かしていますが、これをさらに大量に、かつ高速に動かすのはハード的に限界でした。インベーダーゲームなどは CPUが 8080Aですから、もうフル回転で処理は天井にぶち当たっています。
そこでなんとかキャラクターをもっと高速に動かす方法がないかと、当時の技術者たちが考え出したのが、画面全体を描き直すのをやめて、キャラの画像番号(キャラクターコード)や配色を決めるカラーコード(色そのものビットデータではなく、あらかじめFuse ROMに書き込まれていた配色を切り替えるテーブル番号です)、それと肝心の画面上の位置(X,Y座標)、これらを専用の場所に書き込めば、ハードウェアが勝手に画面に合成してくれる方法です。
(まだアトリビュートエリアがありますが、それらの話を始めると長くなりますので、このあたりか、このあたり を探してみてください)
そりゃあもう、画期的でした。CPUの仕事が激減したのです。
それまではキャラが 1ドット動くたびに、CPUが 1ドット(正確には 1バイトで 8ドット)ずつ再描画させていました。それが、位置テーブルの数値を一つ変えるだけ済みますから、一気に軽くなったのは言うまでもありません。(キャラクターコードやカラーコードは何かのイベントが起きたときに変えますので、そう頻繁にアクセスしません)
何の話を始めたんだ、と思われたかもしれませんが、別に暑さでついに『脳みそぱーん』となったのではありませんので、安心してください。
その画期的な仕組みをその後、スプライトシステム、略してスプライト(sprite)と呼びます。
やぁーと、本題が見えてきました。ほんと長くてすみません。
さてここからが本番です。そのスプライトですが、ハード的な仕組みは全く異なっていますが、似たような考え方で今の時代にもしっかりと生き残っています。しかも、現代のゲーム開発プラットフォーム(Unityなど)では当たり前の用語として使われています。
処理を担当するハードウェアが GPUに置き換わっただけで、2Dキャラを背景とは別の独立したオブジェクトとして位置(座標)とキャラクターコードで管理して高速に動かす、というゲーム開発の根幹はそのまま受け継がれています。
ただし、After Effects(以降 AE)や Cinema 4D(以降 C4D)のように、高度なエフェクトを盛り込み、巨大な動画ファイルとして書き出すのとは、アプローチが根本的に異なります。
パラパラマンガ風のアニメーションと聞くと、LINEのアニメーションスタンプ(APNGやGIF)のように『1コマずつ分離した画像を順番に差し替えて再生する方式』を思い浮かべるかもしれませんが、今回扱うのはそれとは別物で、スプライトシートと呼ばれる『全コマを 1枚の大きな画像に敷き詰め、表示する枠の位置(座標)をズラすことで、見せたいコマだけを切り取って表示する方式』です。
一見するとややこしそうに思えますが、この『1枚にまとめる』工夫が、パソコンやスマホのメモリや読み込み負荷を劇的に節約するための、歴史ある最強のテクニックです。
つまり、大きな 1枚の静止画の中にコマ(絵)が規則正しく並んでいるだけなので、ファイルはたったの1つ。しかもフォーマットは、PNGでもJPGでも、もちろん、WebP(読み込み素材として、書き出しは不可)でも なんでもござれ、それなのに少しの工夫で動画と変わらないスムーズな表現ができるのが、このスプライトシート最大の強みです。
では最初は、ゲームの世界では当たり前のこのスプライトシートを AEで制御し、アニメーションさせる方法を解説していきます。
そのあとで、逆に AEでスプライトシートを作る方法を伝授します。これで、Unity用のスプライトシートが手軽に作ることができるようになります。ぜひ利用してみてください。
まず、スプライトシートを動くようにした状態のものをご覧ください。
たぶん言葉をなくしたことでしょう……。
「はぁ? なんで?」
「いつもの動画と何も変わらないけど、これの何が画期的なの?」
そんな声が地球の裏側からも聞こえてきそうな、ほとんど怒りにも近い声が……。
まあ、落ち着いてください。そうです、完成品は普通の動画です。画期的なのはこれを動かす工程の素材を見てからにしてください。
これがこの動画を動かすための素材です。
「なんだこりゃ?」
そうです。ただの『PNG』ファイルです。縦横 4096pxの正方形の中に、縦横 682pxの大きさの絵が 36枚順番に並んだものです。これが動画になるんです。
しかも『PNG』ファイルですから劣化がほとんどない可逆圧縮のファイルで、クオリティは最高ですし、背景もきれいに透過できますから、通常の動画ファイルのように輪郭がボヤけることもなければ、36枚の画像を別々に読み込んでパソコンに無理な負荷をかけることもありません。たったこれ一枚で、高品質な 2Dアニメが軽々と動く。これこそが、スプライトシート最大の利点なのです。
と言いたいところでもありますが……。(どっちやねん!)
まずい点も多々あります。
「素材を一つにまとめるのでサイズが巨大になりやすい。そのわりにコマ数がしょぼい」
う~。痛いところをついてきてます。だからこそ、動画書き出しのように無駄に高解像度にせず、『必要最小限の解像度で最適化する』ための計算や工夫が必要なんですよ。
「キャラのポーズによっては大量の『透明な余白』が生まれてメモリの無駄!」
でも、このグリッド配置(碁盤目のような配置)は、AEでタイムリマップやエクスプレッション制御をする際の仕組みを最もシンプルにしてくれるんです。(あとでエクスプレッションコードをお見せしますね)
「Spineや Live2Dのボーンや IK(インバース・キネマティクス)から見たら、コマ割り画像なんて時代遅れ!」
その割に、立体的な回転や複雑なエフェクト(爆発・炎・液体など)の表現のときに裏でスプライトシートを頼りにしていませんか? 骨組みだけじゃ表現できない領域があるからこそ、今でも使われているんですよ。
「おいおい、スプライトシートの中の一つの絵を修正したいときに全部作り直すのって、めんどクサ! それに位置が 1ピクセルでもズレるとアニメ全体がガタガタになるんじゃね?」
だから手作業ではなく AEみたいな映像ソフトのプログラム的なアプローチで自動生成、自動制御して作ってんじゃね……あ、作っています。
AE遣いの方で興味のある方は、スプライトシートを AEで動かす方法を説明した Sprite Motion Lab【AEで動かそう】編へお寄りください。
もしこのスプライトシートを Unityで使用するときは、それなりの機能がすでに備わっていますのでさらに簡単。次のようになります。
さすがスプライトシステムを受け継いできたことはありますね。とても簡単にセッティングができました。
次回はこの逆、AEでスプライトシートを書き出す(作る)方法です。Unity や Unreal Engine など、ゲーム開発プラットフォーム(ゲームエンジン)でそのまま使えるスプライトシートが手軽に作れるようになります。そして C4D Liteと併用すれば、立体的にグルグル動く 3Dのアニメーションの表現を含んだスプライトシートまでもが、自由自在に作れますよ。
実際のスプライトがどのような動きをするのか見てみたい方は、【Sprite Motion Gallery】をご覧ください。
2026年 8月28日(金)33℃(午後 5時40分)
試行錯誤の過程にて……
After Effects(以降 AE)の【オーディオスペクトラム】を Cinema 4D Lite(以降 C4d L)で 3D化する試みですが、前回の検証に続き、さらに 2つのパターンを作成してみました。
びっくり箱からハトが飛び出てくるタイミングに利用したパターン(音が鳴ります。音量にご注意)
円形シェイプの直径を変化させたデフォーマのロフトに利用したパターン(音が鳴ります。音量にご注意)
表現のインパクトや "新しさ" をどう生み出すか試行錯誤を重ねる中で、3D化ならではの難しさや表現の壁にも直面して、もがいているような結果となっています。
思うに……。
形の決まっている現実的なものよりも抽象的な物体のほうが、音楽という目に見ないものだからこそ、似合うのかもしれません。
もしかして、とーっても難しいものに手を出してしまったかも……。
今回もその制作過程と、表現の検証結果について【オーディオスペクトラムと同期させる】にて、補足させていただいています。
頭の中がとっ散らかってきたのでした……。 ε=( ̄。 ̄;) フゥ……
2026年 8月19日(水)32℃(午前 10時14分)
これが究極 珍穴子! (海にいるのは 狆穴子)
3D映像を音楽に同期させる、第三弾。
これが究極。After Effects(以降 AE)の【オーディオスペクトラム】を Cinema 4D Lite(以降 C4d L)で 3D化する。
下記が『オーディオスペクトラム』の例です。
(音が鳴ります。音量にご注意)
上下する白いバーが AEの描画したオーディオスペクトラムで、続いて出てくるオレンジのバーは、エクスプレッションでオーディオスペクトラムの動きを数値化して動かしているヘルパーオブジェクト です。
これは不可能だろうと思っていましたが、ずいぶん昔のこと、リップシンクで動かすクチのタイミングを【オーディオスペクトラム】で検知している人の方法をネットで勉強させていただいたことを思い出し、メモっていたエクスプレッションを紐解きつつ、3D化に成功しました。
題して、『これが新種の珍アナゴ♪』。( "チン" は 1回に限ります)
にしても毎回恥ずかしいタイトルばかりですみません。
簡単に仕組みを説明しますと……。
もともと【オーディオスペクトラム】はそれ自身が描画エフェクトですから、外部に対して何かを制御するようなことはできません。ですから何らかの細工をしてやる必要があります。
そこで、【オーディオスペクトラム】が吐き出したピコピコ上下しているイコライザバーの、"ある範囲内のピクセル" を監視しつつ、イコライザーが監視エリアを通過したときに起きる光の強さをフレーム毎に数値化して、その数値の違いから高さを計算して、キーフレームに記録するという方法です。
キーフレームができたらあとは『青ウニ』のときと同じ、C4d Lエクスポーターを利用して『.c4d』ファイルに書き出し、C4d Lでそれ読み込んで、3Dアニメーションの何らかのパラメータを Xpressoで制御すれば、スペクトラムバーの動きが C4d Lで再現できるという流れです。
そしてそのイコライザーバーの代わりをするのが、砂の中に潜っていたチンアナゴです。音楽に合わせて砂から出たり入ったりしたら面白いだろうという作戦でしたが、大きな誤算がありました。意外にもイコライザーバーの動きは激しくて、それに似合う物はそうそうないということに気づかされました。その失敗作がこれ、音楽に合わせて踊るチンアナゴです。
画面右下の青い数値は AEから送られてきた 位置座標で、上は C4d L内で変換された数値です。左から 4匹目のアナゴのモニターをしています。
確かにアナゴの動きは、オーディオースペクトラムのイコライザーバーの動きと同じなのですが、そのまま同期させると、アナゴが激しく上下してなんだかよく解らないものになってしまい、AEのスムーザー処理を通して動きを緩くしたら、今度は音楽と合わなくなって、単純にバタバタ動いているだけのアナゴになってしまいました。こうなると、もうイコライザーの価値はなくなってしまいます。
その後、何度もスムーザーの適用量を変えてみたのですが、最終的にイコライザーバーの動きに近づけるのなら、スムーザーは通さないほうが良い結果になります。でもそうなると今度はアナゴの動きが不自然になります。
そこでエクスプレッションで動きをスムーズにできないかと考えたのですが、滑らかに変化する音楽の流れをプログラムで制御するのは至難の業と悟り、仕方がないので最後は力業です。一日掛かって、16匹のアナゴの動きを全部手作業で滑らかになるように修正したら、結局ただの上下する珍アナゴになってしまいました。
ここは、激しく動いても違和感の出ない、例えばびっくり箱のピエロみたいなものにするべきだったと、今になってやっと道を誤ったことに気づいたのでした。(クソゲーメーカー のやりそうなことでした……)
AEの【オーディオスペクトラム】の動きを C4d Lで再現する方法について詳しいことは、【オーディオスペクトラムと同期させる】をご覧ください。
【教訓】
アナゴの動きとイコライザーバーの動きは相性が悪い。
また一つ勉強になったのでした……。 ε=( ̄。 ̄;) ヘタコキ マシタ……
2026年 8月10日(火)32.5℃(午後 5時 1分)
今度は 青ウニ参上! (仮面の忍者かっ!)
さぁどんどんいきますよ。
前回は After Effects(以降 AE)で作って CINEMA 4D Lite(以降C4d L)へ送って、3D化と装飾を施したら、再び AEに戻してオーディオの合成と加工を経て映像にするという、ラウンドトリップ・ワークフローを紹介しました。ただ少々不満があります。それは C4d Lの【変位】チャンネルを利用した 3D化ですから、高低差はできている、っちゃぁ、できている……。でもいまいちなんちゅうか……。
と、なんだか腑に落ちない気分だったのが正直なところです。それは【変位】チャンネルの 3D化が『白黒のカラー情報で高低差を付ける』という間接的な手法であり、いまひとつ手ごたえが得られない感覚が常にあったからです。ただ曲面を持ったとても複雑なものであっても、確実に 3D化できる有効な方法だと思いますが、派手さがないというか……そこらあたりがしっくりこなかったのです。
そこで新たな方法を見つけました。
題して『青ウニ参上!』(赤影参上! みたいに言うな!)
相も変わらず意味不明の物体ですみません。なにしろデザインは二の次、動かすことに先走る習性を持つワタシの病気みたいなものです。(恥ずいヨ)
右下に出ている数字は Xpressoで正しく制御されているかをモニターしている AEから送られてきた Y座標を表す数値です。『0』から『1000』までの数値が来ています。つまり、AEでのコンポジションサイズが『1000×1000』pxだということです。
前回の【変位】をコントロールしてヒダのような、波のような物体よりも直接的でダイナミックな動きが作れますので、こっちのほうが見ていて楽しいですね。(だからといって、何でウニ? しかも青いし……)
ちなみにこのウニは、【地形】オブジェクトを球体にして、ビシビシしたトゲが出るようにしています。そのとげの高さを AEから送られてきたリズムデータに合わせて動かしています。
C4d Lを音楽と同期させる方法に興味のある方は、内容を加筆修正しましたので、こちらをご覧ください。
【C4d L:実践編5 AEとの逆連携(C4d Lを音楽と同期させる)】→【エクスポーターを経由して(青ウニ参上】
2026年 8月 4日(火)32.5℃(午前10時15分)
天使降臨!!
最近、凝ったことを考えることが多くなってきて……。
例えば、体温計をウォーキング時の最高気温計に利用するとか、そんなアホみたいないことではなく(アホで悪かったね!)。もうちょっと役に立つことです。それは After Effects(以降 AE)と CINEMA 4D Lite(以降C4d L)の拡張連携とでも言いましょうか。
最近の例だと、パースガイドツールとか、運び屋ヌルなどがきっかけになり、AEの波紋エフェクト『CC Drizzle』を C4d Lを通すことで、2D表現だった『波紋』の映像を 3D化できた、などがそれです。
具体的に説明しますと、通常のワークフローでは 『C4d L』→『AE』で映像が完成します。そうではなく『AE』→『C4d L』→『AE』と、一度『C4d L』で加工して、元の『AE』に戻すという
ラウンドトリップ・ワークフローとして、C4d Lを利用する方法を模索しています。
え? 略語と矢印ばかでり意味不明ですか? すみません。
ではこういう説明はどうですか?
AEで作った二次元の推しアニメキャラを 3Dにフィードバックすると美少女フィギュアになって戻ってくる、つまり天使降臨! メタモルフォーゼの世界へようこそ。という双方向の視点で新しいものを作ろうということです(よけいわからんよーになったワ!)。
今回も新たな可能性を秘めた使い方です。題して『カールノイズでビートオン 3Dを作ろう!』です。まるで昭和に戻ったような、ダっサいタイトルですが、仕方がありません。ワタシは昭和史の王子ですから(怪獣王子かっ!)。
Z世代の方には全く何のことか分からないでしょうけど、説明もせずにどんどん先に進めます。
まずは、 "カールノイズ" です。
これは AEのバージョン 2026年6月(Ver.26.3)から搭載された、流動体の動きを作ることができるエフェクトです。よく似たものに『フラクタルノイズ』がありますが、あちらは『雲』『煙』のようなものに適しています。
次がカールノイズの例です。
見た瞬間に、白黒映像で『Q』の文字がグニャ~って丸まった絵を想像した人は、立派な『昭和史の王子』確定です。(当時家は白黒テレビでした)
にしても……。
あのテレビドラマを知っている時代の人からしたら、このカールノイズが新しいんだか、古いんだかよく分かりませんが、これが AEの 2026年最新バージョンに搭載されたエフェクトです(おおぉ! ほな新しいんやろ)。
白黒映像って……。
と思われたでしょう。これが都合いいんです。余計な色情報がない白黒(グレースケール)は、彩度ゼロの純粋な輝度情報(明暗)だけなのです。だからこそ、AEの色付けエフェクトが素直に乗ってどんな色彩にも自在に加工が可能であり、かつ C4d L的に、もってこいのシロモノなのです。
どうやるのか順を追って説明しますと、【オーディオをキーフレームに変換】で吐き出された振幅キーフレームのデータで、カールノイズの【コントラスト】プロパティをコントロールすれば、音楽に合わせて明るさが変化します。それを C4d Lに持ち込んで 3D化すると、出たり引っ込んだり、モコモコ動くものができます。そのあと、もう一度その物体を AEに取り込み、元の音楽と合成すれば、3D化された動くグニャ~の完成となります(美少女フィギュアはどこ行ったんだよ?)。
美少女フィギュアは放っといて、さきほどの白黒画像を、C4d Lの【変位】チャンネルのテクスチャとして使用すると、次のような映像ができ上ります。
音が鳴ります。音量にご注意ください
さっそく試してみようと思われた方は、下記のページで詳しく説明していますのでご覧になってください。
【 AEとの逆連携(C4d Lを音楽と同期させる:カールノイズ編)】
2026年 7月24日(金)36℃(午後 2時52分)
気温、体温、PC爆音!
どうまとめるべきか悩んでいた『4次元的思考で波を作る 』の解説がようやく完了しました。
波という一見して単純そうな物理現象を 3Dで作り上げる過程に興味のある方は是非お読みください。今回は【数式】デフォーマについて、仕組みから応用までいろいろな実験で深掘りしています。
最終的には、プログラムでもないのに数式の中に if文と同等の機能を入れて条件分岐も可能にしています。
数式デフォーマを簡単に例えるなら、数学を使ったドラマ作りです。お読みになって、あなたが作る新しいドラマのきっかけになることを願っています。
CINEMA 4D Liteやってます →【4次元的思考で波を作る 】
それにしても暑いです。
ワタシは日々押し寄せる熱波という波に飲まれて、もう消えそうです。
これは、持ち歩いている水銀体温計の写真です。
なぜ、水銀体温計を持ち歩いているのかは、前回(7月18日)をごらんいただくとして、これは本日のウォーキング時の気温測定器(ただの水銀体温計)の結果です。
前回が 39.5度というとんでもない結果だったのと、連日テレビで 40度、40度と連呼しているせいか、な~んだ。36.8度しかなかったという、ちょっと拍子抜けの結果でした。
でも考えたら、自分の体温と同じということが分かり、結局暑いだか、寒いんだか、首を傾げつつ帰ってきました。
溶けたアイスみたいになっています……。 ( ̄ω ̄!) 脳ガ溶ケトル…
2026年 7月18日(土)35.5℃(午後 3時55分)
世紀の大実験……猛暑で盛夏
獄暑の中、本日もウォーキングに出かけてきました。不要不急な外出は控えましょうと叫ばれ始めてきた猛暑の中ですが、ワタシにはこの灼熱の気温よりも熱くたぎる『野望』があるのです。
日々、パソコンの前で実験をするワタシですが、ウォーキングだってタダでは歩きませんよ。変な種を拾ってきたりとか、カラスの上前を跳ねたりとか忙しい日々(7月13日)なんです。
そうそう、報告するのを忘れていましたが、拾ってきた不思議な種を植えてから一週間が経ちました。でもまだ何の変化もありません。真っ白な頭が土の中から出たままです。
ちなみに、ソテツの種だろうと仮定していますので、全体を地面に入れずに少し頭を出しておくのがやり方だそうです。(ネットに出ていました)それに従っていますが、やっぱりこれは種ではなくて、何かの卵だったりして……。ブースカが生まれてきたらどうしましょうか(昭和っ!)
と、くだらないことを書いてここの空白を埋めつつ、外は灼熱地獄そのものでした、とまずは感想を述べておきます。
水銀体温計は役に立つのか?
この炎天下であってもそれをなぎ倒すほどの『野望』的な実験とは。
『水銀体温計を持って歩いていたら、
その日の最高気温が記録できるんじゃね?』実験です。
昭和時代の遺物、水銀体温計は一度上がったら下がらない、つまり『その日の最高温度』だけをロックして記録できる温度計です。それをリュックの後ろポケットに入れて持ち歩いたら、その日の最高気温を測ることができるだろうという考えのもと、やっています。
そしてまだ続きます。水銀体温計は 42度ちょっとで上限ですので、
『42度を超える日はあるのか。それから昭和の漫画でよく見た、水銀パーン! って本当に起きるのか』大検証です。
あ……。静かなるため息ありがとうございます。
田んぼの水も干からびる、しらけ状態という絶賛をいただきました。
あまりの暑さで、3キロも行かないうちに退散して帰ってきましたが、本日の最高気温はぬあんと 39.5度でした。
ま、正確だとは言えませんが、体感温度的にもそれぐらいでしたが、『どんタコス』のおじさんが被るような麦わら帽子のおかげで平気でした。
※言うまでもありませんが、水銀は有害な物質です。本当に「水銀パ~ン!」となったら大惨事ですので、絶対にマネしないでください。
ワタシはプラスチックのケースの中に入れて、さらにリュックを伝わって体温が伝わらないように、それを眼鏡ケースに入れたうえに、リュックの最も身体から遠い場所にあるサブポケットに縦にして保管しています。
(というか、今や手に入らない歴史の遺物をこんなことに使ってもいいのでしょうか……)
危険ですのでマネしないでください……。 ( ̄ω ̄!) アホの上塗り
2026年 7月13日(月)30.5℃(午前 6時45分)
不思議な種を拾いました……
運動不足解消に日課となったウォーキングで、久しぶりに 10キロの遠征をしてきました。その途中、水分補給と休憩に立ち寄った神社の境内で、不思議な種を拾ったのです。
まるでこれをどうぞ、といわんばかりに腰掛けようとした石の上にぽつんと置かれていた白い種。一瞬、鳥の卵かと思わせるその姿はきれいな楕円形。
長径 3.5cm 短径2.3cmのすべすべした殻で、頭が少し尖っているのが特徴です。AI検索で『銀杏(ぎんなん)』と出ましたが、『銀杏』は冬になって晩酌のアテによく食べていますので、間違うことはありません。まずこんなに大きくないですよね。ウズラの卵より少し大きいぐらいです。
他にも梅の実だとか、桃の種だとかありましたが、ここまでツルツルした表面ではないので却下です。それは陶器のようにきれいで凹凸がなく、そして銀杏のように固い。もちろん秋の日に(2025年11月6日)拾ってくる『オニグルミ』でもありません。
最終的に最も近いのが、『ソテツ』の種でした。
しかし、その神社にはソテツは無かったと思います。どこにでもある杜に埋もれた神社です。おそらく、どこか遠く離れたところに生えていたソテツの実をカラスが見つけて、神社の石の上で外側の肉厚な果肉だけを器用に突っついて食べたのでしょう。そして中から出てきたこの "つるつるの白い大きな塊" を、まるでそこに供えたかのように残して去っていったもの。
「これって神様へのお供え物だったのか?」
と感じて、もらって帰るのを躊躇したのですが、あまりにも手に吸い付く感触がこれまで経験のないものでしたので、植えてみようと思いもらってきました。
実際握ってみて実感しました。手の平にすっぽり収まるこの大きさからいくと、小さな鳥では咥えることができません。カラスぐらいの大きさでないと無理でしょう。
カラスといえば……。
今年の春。在来種のイヌノフグリを躍起になって探していた時期があります。2026年 3月11日の記事です。今でも探したいのですが、開花時期が過ぎた純粋なイヌノフグリの姿は、もはや他の雑草と見分けがつかなくなりますので、現在は中断していますが、その時のことです。
草原を歩いていると、きらりと陽の光を反射した銀白色の物体を草の中に発見しました。
何だろう? と思って拾い上げると、アルミの1円硬貨が2枚。
なんでこんな草原に?
誰か落としたのかな? と首をひねりつつ……。
交番に届けようかとも思ったのですが、たぶんお巡りさんも迷惑がるだろうと思い、現在ワタシが預かっています。『オレが落としたやつだ』と心当たりのある方は、申し出てください。着払い便でお届けします。たぶん大赤字になると思いますが……。
これもたぶんカラスの仕業でしょうね。
カラス、特に都会や人里近くに住むハシブトガラスなどは非常に知能が高く、好奇心が旺盛です。彼らは視力がとても発達しており、光を反射して輝くもの『アルミホイル、コイン、ガラスの破片、スプーン、時計のネジなど』に強い興味を示して、巣に持ち帰ったり、お気に入りの場所に隠したり(貯食行動と呼ぶそうです)する習性があります。
つまりこの 2件ともカラスの宝物をワタシが取り上げたのでしょうか?
大迷惑なおっさんみたいですね。
カラスの上前を跳ねるおっさん……。( ̄‥ ̄!) アホヤ…
そして……。
これは神様からの預かりものですから、しっかり管理いたします。
2026年 7月11日(土)32.5℃(午後 3時45分)
原因を突き止めました……
エンコードに 7時間半を超えたのは何かおかしい。その原因を究明すると前回宣言しましたが、今日はそれを突き止めた話です。
腑に落ちないことがあると徹底的に調べたくなる性分です。十数年前までは、自分で作ったアプリのバグを直すだけでなく、なぜそのようなことが起きたのか、その原因は何かまで調べつくさないと、再び似たようなバグが発生する可能性がありますので徹底的に調べていました。そのせいか今のブラックボックス化した開発環境やゲームエンジンには、どうにも馴染めないものを感じてしまいます。
早い話がバグ撲滅を趣味としていたようなもので、ある特定の条件が重なったときだけに発生するクリティカルなバグを調べるのが、三度の食事より好きだったのです。そのときは、ICEとロジアナ、ついでにアナログ波形まで観測できるデジタルオシロなんかも並べて、数ナノ秒の世界に何日も費やした記憶がよみがえります。
ということで……これが問題の映像です。
見た目からは何も判断できませんが、この映像をエンコーダーが吐き出すまでに 7時間半という膨大な時間が掛かった理由が腑に落ちなかったのです。
ちなみにこちらの環境は OS:Win11、64bit CPU:i9-14900KF、24Core RAM:128GB グラフィック:RTX-4070S キャッシュ:Gen4 SSDです。通常なら 1時間前後のはずです。
その原因はずばり、テクスチャに『H.264(60fps)』のファイルを使ったことでした。
宇宙の画像の映り込みを二重にしたのが原因かもとか、円盤の周囲でモコモコ動くオブジェクトに使用した【変位】チャンネルに、白黒画像しか扱わないのに『ProRes 422 LT 16bpc』なんてバカげたデータを使ったのが原因かもとか、いろいろ憶測は飛びましたが、まさかの『H.264』コーデック動画を円盤の中心に貼り付けたテクスチャにあったとは思いもよりませんでした。
検証方法は単純です。宇宙の画像や【変位】を順に消して 20フレームだけエンコードするという実験をしてどちらが原因かを探ってみたところ、どちらもほとんど変わらず、3分40秒と 3分33秒で、1フレーム当たり『約 11秒』でしたが、円盤の中心で音楽に合わせて放射状に動く部分を削除すると、ぬあんとたったの『10秒で』エンコードが終わりました。1フレーム当たり『0.5秒』です。
「これが原因かぁ」と安堵し、『H.264』をやめて、60fpsの『ProRes 422 LT 16bpc』に変えてエンコードしたところ、7時間半掛かったエンコードが 55分で終わり、あまりの爆速ぶりに、しばらく呆然となったのです。
本来なら、これでメデタシめでたしと終わるところですが、ワタシの追求はまだ続きます。
テクスチャに動画(H.264)を使うのは考えものだという教訓を得たのですが、だいたい、なぜテクスチャに『H.264』を使ったのかという話と、なぜ『H.264』ならエンコードが遅くなるのか、そしてもう一つ。C4d Lをお使いの人が首を捻る案件、廉価版の C4dでもテクスチャに動画を使うことはできますが、QuickTimeの ProRes系はテクスチャとして読み込めないと思っている方もいるのではないでしょうか。ワタシも何度か挑戦しましたが、一度も読み込めませんでした。その反面『H.264』はどんなものでもすんなり読み込んでくれます。
では順番に説明します。
テクスチャに『H.264』を使う理由
これは簡単です。AEで作った動画を C4d Lに持ち込むためです。普通とは逆の使い方ですね。でも覚えておくと使い道はいろいろありますよ。今回は動き回る円盤の中央で音楽に合わせて放射状に光が躍っています。
なぜ『H.264』ならエンコードが遅くなるのか
これは色々調べたところ、mp4が包み込んでいる(mp4は単に入れ物ですから)『H.264』データの構造が、『前後のフレームの差分でデータを保持しているため、3Dレンダラーがテクスチャとして使用している特定の 一つのフレームを参照しようとするたびに、チェックポイントと呼ばれるフレーム(イントラフレーム)までさかのぼって、目的のフレームの絵を作り上げる』というものだそうです。
差分データと呼ばれるものは、完全な 1枚の絵が記録されたイントラフレームの画像から見てどれだけ動いた、あるいは変化があったかの『差』を記録したものです。
ようするに、レンダリングするたびに記録された 1枚の絵からそのフレームまでの差分データを順に計算して、目的のフレームでの絵を完成させる、ということを繰り返していたのです。それに比べて、『ProRes 422 LT』は1フレームごとに完全な絵を記録していますので、差分をトレースするような計算は必要ないため、爆速で終わったということになります。
そしてこの仕組みが、もう一つの "さらなる謎" を説明してくれました。
エンコードの後半、映像の動きがゆっくりになるシーンに差し掛かると、なぜか処理が極端に遅くなっていたのです。この理由も解らず、首をかしげていたのですが、これで納得です。動きが少ないシーンでは、H.264はデータを節約するためにイントラフレームの間隔を長く引き延ばします。そのせいで、レンダラーははるか向こうのチェックポイントまで戻り、長大な差分データの中で必死にトレースをこなして、やっとこさ 1枚の絵をこしらえ……やれやれ、と 1フレーム完了させていたわけですね。
ちなみに 映像 1秒で 30枚のフレームが必要なのですから……。
「いやはや、ごくろんさん」と労っておきましょう。
C4d Lで、QuickTimeのProRes系のデータがテクスチャとして読み込めるのか
これはネットで調べましたが、読み込めるとも読み込めないとも書かれていませんでしたので、実際に取り込んで試してみました。
まず、もっとも使いそうな『ProRes 422 HQ』と『ProRes 4444』で試してみたところ、次の画像をご覧ください。
やはりProRes422HQやProRes4444では、正常に読み込まれていません。
これと同じものを見ていますから、ワタシは ProRes系は読み込めないと思い込んでいました。ところが、左のProRes422HQの縞模様の画像を見て。ピンっと来ました。
「これって、データの折り返し点が狂って、斜めにズレてしまっているんじゃないか?」とね。
データを画像として展開するときに、1行の正確な横幅(ドット数)をシステムが誤認すると、このようにデータが斜めに回り込んで縞模様(パターンのズレ)になります。昔、画像スキャナーの読み込みプログラムを作っているときに、これと同じバグを経験したことがありました。だからなんとなくピンと来たのです。
ここに張り付ける動画は正円形を対象にするので、正方形サイズで作っていました。そこで、一般的な『16:9』サイズに変更してみると……。
はい、このとおり、どちらもちゃんと読み込まれました。
左のProRes422HQは 4Kサイズという大きなものですので、縮小されて映っていますが、縦横比は合っています。
やはり推測は正しかったようで、画像の大きさが『16:9』サイズなら、ProRes系でも正しく読み込まれ、正方形サイズだと最初の写真のように、バグだと思われる挙動が現れます。
私がこれまで一度も読み込めないと感じたのはおそらく画像サイズのバグに遭遇していたからだと推測されます。
この検証で謎は全て解消です。テクスチャに動画を使用するときは、『H.264』をやめて『16:9』の ProRes系でエンコードすることにしました。
そのおかげで、7時間半から 55分という 8倍もの爆速エンコードに喜びまくったのですが、それも束の間、その後、手を加えて映像が複雑になったため、ProRes系でも 2時間40分という結果です。しかし安心してください。さらに速いものを発見しました。それは『連番PNG』でした。それを使うとこの中で最速の 1時間という結果に落ち着き、今は満足しております。
もしその最終映像を『H.264』でエンコードしたら10時間を超えるかもしれませんが、怖くてやっていません。(そりゃそうや)
C4d Lのテクスチャに使える動画の種類や、『連番 PNG』を動画データとして読み込む方法、またどれが速いか、なぜ速いのか、なども含めて詳しく知りたい方は、下記ページで加筆修正していますので、ご覧になってください。
【テクスチャに使える動画の種類】
でも結局は自分の知識不足でしたから……。 ( ̄ω ̄;) ハジヤ…
2026年 7月 9日(木)32℃(午後 4時45分)
思い起こせば 16年前……
今回はハードウエアとソフトウエアをごちゃ混ぜでいきますよ。嫌いな人は飛ばしてください。
かなり前のことになりますが、フルカラー LEDを 64個繋いで、ミッドレンジ PICで音楽に合わせて光の舞い(イルミネーション風)をコントロールしようと、躍起になっていた時代があったことをふと思い出しました。
PICという言葉が出てきた時点で、引いてしまう方もおられるかもしれませんが、ワンチップ CPUのことで、 Microchip 社が開発・販売している組み込み制御用のコンピュータ部品の一つです。
そしてフルカラー LEDと呼ばれる電子部品は、1個の LEDの中に RGB(赤・緑・青)の 3色が封じ込められていて、それぞれ単独で光らせることができるようになった物です。それらを外部から入力された音源に合わせて PICで点滅させるのですが、単純にオンとオフを繰り返すようではクリスマスツリーの飾りにしかならず、見ていて感動を生みません。そこで明るさに強弱を加えて、RGBの光を高速に変化させながら順番に流していやると、虹色の光が走るように見えてきます。
そのため、LED 1個に対して 32段階の輝度情報(5bit)を持たせて制御するように回路を組みました。すると LED 1個に対して 3色分(3バイト)、それが 64個、 3×64で 192バイトのメモリを使います。ミッドレンジ PICではギリ入ったと記憶しています。それを 8個の 8bitラッチ回路(一時的にデータを保持する部品)に 10ミリ秒単位で転送して、高速に切り替えていく方法でケーブルの束を32本まで省略しました。ふつうに考えたら 64個 3色分で 192本のカソード線。それに一色ごとにまとめて電源を流し込むアノードが 3本必要なので 195本になります。
ただし、切り替え時間が遅くなると、LEDがチラチラ瞬いてしまったり、最も遠くの LEDまでに時間のずれが生じてしまいます。実際ほんのわずかに遅れるのですが、それがなんとなく情報の流れが感じられて、とても心地よかったのですけどね。
最終的には処理時間が追っつかず、32階調は人間の目では見分けることがほとんどできないので、16階調に(4bit)落とすことで、処理時間との帳尻合わせをしたり、当然ですが高速処理をこなすためには C言語は一切使わずアセンブラ一本で、オーディオ信号は外部のオペアンプで整形。それを PICの A/D変換を通してデジタルデータにし、16段階の輝度コントロールを経てようやく完成させました。しかしそれは、きれいな色のオーディオレベルメーターと変わらないものになってしまい、しかも減ったといっても 32本ものケーブルの束は、コストの面でも到底商品化は無理だと断念しました。
その後、シリアル転送で個々の LEDへデータを送る方式で、ケーブルの束を数本にまでに減らしたのですが、これも 64個のシリアル→パラレル変換回路(シフトレジスタ)が必要になってしまい、最終的にその計画は陽の目を見ることはなくお蔵入りしました。そんな悔しさが、ずっと記憶の片隅に残っていたのです。
今回は、それを回路設計も無しに、もちろん半田付けすることもなく、部品を注文することもありません。すべてを AEと C4d Lで再現すれば、情報の伝達に関してはレンダリング時間がその肩代わりをしてくれますので、完成すれば瞬時に画面上で通達(動作)されます。
ただ、悔しいかな映像です。手に持って触ることはできません。でも見ることはできます。"こんなのを作りたかったんだ" というのを 16年ぶりに思い出したわけです。当時のことは 2010年 8月28日の記事に書いていました。いま読み返すと、あの膨大なケーブルの束やコスト計算に頭を抱えていた自分が、なんだか遠い昔の別人のようです。テクノロジーの進化とは恐ろしいもので……。
……と言いたいところですが、いざ パソコンで再現してみると、最終的なレンダリングに結局 7時間半も掛かってしまいました。形を変えてまた同じような『時間』の悩みを抱えているなんて、なんだか進化しているんだかいないんだか、自分でもおかしくて笑ってしまいます。
それでも AEではもう古臭い『音源との同期』ですが、 C4d Lを使えばこうなるんだよ。ということで、
限界突破!
そんなこんなで、次の映像がその 7時間半の結晶です。もちろん音楽も流れますので、音量にはご注意ください。
この映像は、AEに搭載されている "オーディオをキーフレームに変換" と、同じく AEのエフェクトにある "オーディオスペクトラム" を利用して、それを C4d Lに持ち込んで 3D化したものです。
AEでは使い古された手法ですが、3D化することでまた陽の目を見るかもしれません。
C4d Lで音楽に同期したオブジェクトを作る方法など詳しくは、下記ページにて加筆修正しましたので、ぜひご覧ください。
【C4d Lite:実践編5 AEとの逆連携(C4d Lを音楽と同期させる)】
ところで、なぜ今回、この程度の映像に 7時間半も掛かってしまったのか。あの霧に包まれた雨の神社でさえも 2時間ほどです。
この原因をあらためて反芻してみると、理想と現実の壁はテクノロジーが進化しても、別の形となってやっぱり目の前に立ちはだかります。
どう考えても、このエンコード時間はおかしいです。何かが足を引っ張ったのだと思います。
考えられるのは、中央で回転している円盤の表面に映り込んでいる宇宙の映像と、背面の宇宙はそれぞれ違うもので、それをカメラに撮影されるのと、映り込みとして現れるものとに分けた無駄な使い方が原因か。
あるいは、円盤の周囲でモコモコ出たり入ったりするオブジェクトのテクスチャデータに『ProRes 422 HQ 16bpc』という高負荷なものを使って理想を追いかけた豪華仕様の結果が 7時間半なのか。
もしパソコンが喋ったら、
「おっさんアホちゃうか。こんなチンケな画像にこの膨大な画像データ、どんだけ無駄や、っちゅうねん!?」
と文句を垂れながらも、健気に黙って 8時間全力疾走してたわけですね。健気というか、完全に筋トレ状態ですが……。
かつてPICの192バイトを極限まで削ぎ落としてアセンブラを組んでいたあのストイックなワタシが、16年後にデジタル空間で『全部盛り』の超贅沢ギガ盛りデータに手を出してしまい、FHD(1080p)サイズ、30fpsなのに 7時間30分というヘタこいたコトをしています。
今後のこともありますので、この原因は絶対に突き止めたいと思います。
ただいま調査中です。
本当の原因がわかり次第ご報告いたします。
希薄になった記憶の片隅にあった16年前の『音と光の舞い』が、PICマイコンから PCの3D環境へと形を変えて蘇りましたが、結局、またもや悔しさは残りつつも、上がってきた映像がとりあえずキレイだったので、「まあ、今回はこれでいいか……」と、自分に言い聞かせることにしました。
相変わらず ジェミー(Gemini)さんのイラストは、ワタシが意図することを的確に絵にしてくれていますね。何も伝えていないのに、半田コテが HAKKOのマッハ1って……。
知っている人はここでニタリとしてください。
というより……。
半田コテの持ち方が独特だと思ったら……。
この絵、両方右手ですよ。ジェミーさん。
言い訳もできるジェミーさんでした。 ( ̄‥ ̄!) AIも木カラ オチル…
2026年 7月 4日(土)28℃(午前 7時45分)
やれやれ またあなたですか……
最近またこのサイトのアクセス数が急上昇しています。と書くと、
「ほぉぉ。なんや景気のええこっちゃな。自慢でデっか?」と嫌みの一つも返ってきそうですが、とんでもないです。
GA4(Google Analytics 4)とアクセスログとを調べてみると、大勢で押し寄せてきているのは、迷惑な "ボット" たちです。
簡単な話、人間ではなく詮索ロボットのことです。検索ではなく詮索という言葉がピッタリ。ほとんどが怪しげな情報集めですね。ネタを探してネットの中をウロウロ、世界中のサイトを訪問しては情報をかき集めている連中のことです。
中には純粋に世界の動向を調べるために活躍しているボットたちもいますので、全否定しているのではないですが、中には以下のような "胡散臭い" 活動をしているボットがいます。
"GET /news/wp-includes/wlwmanifest.xml HTTP/1.1" 404
"GET /2018/wp-includes/wlwmanifest.xml HTTP/1.1" 404
"GET /2019/wp-includes/wlwmanifest.xml HTTP/1.1" 404
"GET /shop/wp-includes/wlwmanifest.xml HTTP/1.1" 404
"GET /wp1/wp-includes/wlwmanifest.xml HTTP/1.1" 404
"GET /test/wp-includes/wlwmanifest.xml HTTP/1.1" 404
"GET /media/wp-includes/wlwmanifest.xml HTTP/1.1" 404
"GET /wp2/wp-includes/wlwmanifest.xml HTTP/1.1" 404
これはある国からやってきていますが、ワタシのサイトのどこかに昔のWordPressと連携するための "wlwmanifest.xml" がないか必死で探しているのですね。しかもこれ、1秒ほどのあいだのことです。
では何のために探しているのかというと、これらはセキュリティが甘かった時代の産物なのです。他にも『wp-login.php』や『xmlrpc.php』があります。しかし未だにこれを使っている方が大勢おられますので、それを探し出して裏からちょっかいを出そうと、もくろんでいるわけです。
ほかにも何の情報を探っているのか分かりませんが、3日間に "250" を超えるアクセスが 30分間ほどの隙間に連続して入るなど、
「おいおい。お前らヒマ人か!」といってやりたいような気分になります。
そこで世界中の迷惑ボットたちに宣言します。
「このサイトは手作り htmlとcssだけで構成されて、情報閲覧だけを目的にした静的 HTMLサイトでっせ。
データベースもログイン画面さえも持ってない、そんな広告業界からも見捨てられた 非SSLサイトに来たって何もおまへん。無駄なことはやめなはれ」
とでも 16進数(Hex)で書いて、サイトのどこかに置いてやろうかしら。しかもファイル名は『wlwmanifest.xml』で。
恥の上塗り……。 ( ̄‥ ̄!) アホヤ…
これより古い記事は2026年・前半へ移動しました。

All rights reserved.














































