thank you for your access

お品書き…

CINEMA 4D Liteやってます

new

改稿

2025.8.19 案件追加　AE・C4d L トラブル対策案

2021.5.15　楽しい効果音づくり

2020.5.16クソゲー後日談

はじめての PIC

2018.11.3 デジタルは５Ｖにあらず・入力編

【初めてのFlash PIC 】詳細

【肝とりカツ】詳細


製作：D-space KEYOSS
販売：（株）アートグローブ

電子工作の実験室
できる！自作パソコン作り方教室
自作パソコン部品・パーツの基礎知識！
タイピング練習広場

当ホームページはリンクフリーです。

リンク後メールを頂けましたら、相互リンクさせていただきます。

ご感想などもございましたらこちらからお寄せください。

なお迷惑メールが大変多くて困っております。できましたら件名に『デジタル降魔録を見た』とお書き添えください。よろしくお願い申し上げます。

バナーは下記の物をご自由にお持ち帰りください

魔王城のすぐ横で、今日も元気に開店中。世の中の役に立つかはさておいて、誰も求めていないかもしれない『超ニッチ』なデジタル知識の攻略本、デジタル降魔録。
―― produced by D-space Keyoss

２０２６年５月２日（土）１８℃（午前６時４８分）

　パースガイド作成ツール（その 5/6）[むむむの XPresso]後編

進む

XPressoの最終です。残りはあと一つ。最後は "カメラ1台で完結！「ステップ補間」でパースガイドごとアングルを切り替える職人技" で締めくくります。
　ライトノベルのタイトルみたいに長いですが、この方法は意外と使い道があるかもしれません。

　その前に、Xpressoの後半ですね。
　前回はあまりに拍子抜けするようなプログラムでしたので、もうちょいそれらしいことをやりたいですよね。

　もう少しプログラムらしいことといえば、『天井グリッド』と『地面グリッド』の距離を、縮尺率から逆算して実寸を求めてHUDの『グリッド間数値』の子階層に作った『Head』というテキストスプラインに流し込む処理を作ってみましょう。

　この処理は、地面グリッドからカメラの高さを計算して数値化する部分『E Level』にも必要になりますので、両方で必要になる "縮尺率" を Global定数として、どの処理からでも参照できるようにすれば、 "縮尺率" の変更は一か所で済みます。これならよりプログラム的になりますね。

この 2か所から参照できる変数を作ります

　例えば縮尺率を 41.2%としたものを Java言語風に書くと、
"public static final float SCALE_RATE = 0.412f;" ですね。
　この意味は、"SCALE_RATE" という書き込んだらもう変更不可(final)な共有の入れ物（static)に、小数点のある数字(float)を入れておくので、どこからでも(public)使ってね。という意味になりますが、果たして XPressoではどうなるのでしょうか。

　さっそく、ノードエディタの左にあるリストを漁（あさ）ってみました。すると【XPresso】→【一般】の中に【定数】というのがありましたので、引っ張り出してみますと……。

　こうなりました。

う――ん。視認性がいいとはいいますが……。これでいいのでしょうか。
　なんだかものすごく不安になります。だいたいどこで定数を設定するのでしょうか。これでは入れ物ができただけです。

　調べてみると、この方法で作った定数ノードは、一つの XPresso内だけで使用できるものになるようです。つまり "いろんなところから使える(public)" ではなく "その場所だけで使える(private)" だということでした。

「早よ言わんかい！」と叫びたいのをぐっとこらえ……。
「あ、これは『ELオブジェクト』の回転角度『B』を固定させる定数として使えるゾ」と考えを改めることにしました。

　ここで前回の『ELオブジェクト』で作った XPressoに『定数』ノードを追加する話につながるわけですね。

　『ELオブジェクト』ノードに『絶対角度.B』の入力ポートを作り、『定数』ノードを左リストから【XPresso】→【一般】の中から引っ張り出してきて接続します。

『定数』ノードを選択すると属性マネージャに【ノード設定】パネルが出ますので、①の【データタイプ】を『実数』に、【値】は『0』です。
　これで、『ELオブジェクト』の回転角度『P』を変更しても、常に『0°』となって動かなくなります。

　先にも書きましたが、この『定数』ノードはこの『ELオブジェクト』に貼られた XPresso内だけの定数です。どこからでも参照できる Global定数を作るには、いろいろと手続きが必要です。

　では話を戻して、Global定数を作る方法です。

① 空のヌルを作って、それに『ユーザーデータ』を定義設定する。これが Global定数、つまり public static final です

② XPressoに『ユーザーデータ』を定義したヌルをドラッグアンドドロップして、『ユーザーデータ』ノードを作る。

③ 『ユーザーデータ』を参照する『計算』ノードをエディタに作ってから、『ユーザーデータ』ノードの出力ポートと、そのノードの入力ポートを繋ぐ。

なんだか力が抜けていくような気分です。なんでこんな回りくどい方法にしたのでしょうかね。ま、あんたの説明はくどいといわれ続けているワタシが口出しすることはないのですが……。

　とりあえず、先に進めます。やってみましょう。

① 空のヌルを作って、それに『ユーザーデータ』を設定する。

空のヌルを作ったら名前を『CONSTANTS』と付けます（下の画像①）。これは XPressoの『ユーザー定数』ノードに反映される名前です。
　このヌルは、映像に一切関係しませんので、オブジェクトマネージャのどこに置いても問題ありません。適当にジャマにならない場所に置いておきます。

次に『CONSTANTS』ヌルの属性マネージャの『タブ』部分を見てください。右端にたくさんのよくわからないアイコンが並んでいる列の左のほうです。【モード】の隣に【ユーザーデータ】というタブがありますので（画像の②）、それを押します。

　出たメニューから『ユーザーデータを追加（③）』を選びますと、こんなパネルが開きます。

①に定数の名前を入れます。縮尺率ですので『SCALE_RATE』としました。
②と③は小数点を扱いますので、『実数』にします。
　できたら『OK』を押してここは終了。

　もし、再度開きたいときは、『CONSTANTS』ヌルの【ユーザーデータ】タブを押して『ユーザーデータを管理』を選ぶと先ほどのパネルが開きますので、左リストから『SCALE＿RATE』を押します。

　さてこれで " "public static final float SCALE_RATE" までが宣言できました。

「まだあるんかい！」と叫びたくなりますが、ここは我慢です。

　次は "=0.412f" の部分を設定します。

　オブジェクトマネージャの『CONSTANTS』ヌルを選択します（①）。

『CONSTANTS』ヌルの属性マネージャを見てください。【基本】【座標】などのタブに並んで【オブジェクト】の右隣に【ユーザーデータ】というタブができています（②）ので、それを押します。
　すると、上の画像のようになりますので、【SCALE_RATE】の入力欄に縮尺率となる数値を入れます（③）。今回は『41.2%』に縮小しているという設定ですので、『0.412』です。

　これで、
"public static final float SCALE_RATE = 0.412f;"
　が宣言できました。

「………………」
　言葉が出ないですね。
　とにかく先へ進めましょう、日が暮れます。

　Global定数を使うのは、天地グリッドの距離数を表示する『Head』テキストスプラインと、『E Level』テキストスプラインに作った XPressoですので、まずは、『Head』テキストスプラインに XPressoタグを作って、ノードエディタを開きます。

　開いたら、オブジェクトマネージャの『CONSTANTS』ヌルをドラッグアンドドロップしてエディタの中に入れます。

『CONSTANTS』というノードができますので、赤色の出力四角をクリックして『ユーザーデータ』を押すと、『SCALE_RATE』ができていますのでそれを選びます。これでこのノードは "どこからでも参照できる(public)" 定数となりました。

　あとは全体の計算処理ノードを作って、それぞれの出力ポートと入力ポートをワイヤーで接続していきます。『CONSTANTS』ノードの定数出力ポートはそれを使うノードの入力と接続することになります。

　ではいよいよプログラムらしい作業に入ります。
　まず、天地間の実寸値が計算できるまでの順序を次のようにしました。
　プログラムの説明は長い文字では不向きなので、天井グリッドの『Y座標』は "TY"、地面は "JY"、先ほど作った SCALE_RATE定数は "SR"、数値化されるテキストスプラインは『Head』という名前なので、そのまま "Head" と書きます。

　一時的な変数として "V1" というものを使います。これに関してはこの後で説明します。

① V1=(TY-JY)/SR;
② Head.setText(String.valueOf(Round(V1*100)/100));

②だけ少々ややこしそうですので、説明を加えておきます。

Round( )

これは小数点以下を四捨五入する関数です。
"( )" 内で、"V1*100" とやっているのは、(TY-JY)/SRで得た答えを 100倍することで、小数第2位までの部分が整数になります。それから四捨五入して、再び "100" で割って小数第2位までの数値に丸めています。

　たとえば、 "12.3456789……" が、 "1234.56789" になって、
　Round( ）で、 "1235" と四捨五入されて、
"1235/100" で、 "12.35" となります。結果この関数は小数点以下第3位で四捨五入して小数第2位までを求めるものになります。
　それから、このままだと数値ですので、文字コードに変換するために、
"setText(String.valueOf(12.35))" で、文字コードに変換されて "Head" のテキストとして画面に表示されます。

　これを XPressoで表現するとこうなります。

やっぱり「なんだかなぁ……」という気分になりましたね。
　プログラム的なインストラクションで詰めて記載すれば 1行で済むところですが……。
　ワタシから見ればこちらのほうが魔法の呪文、いや魔獣召喚の魔法陣にしか見えないのですが、これで正しく天地間の距離が実寸に変換されて HUDに表示されますので、逆に驚いたりして……。

　いやしかし。Unityもそうですが、なぜあちこちのパネルやドロップダウンリストからパーツをかき集めて、魔法陣みたいなものを組み立てるプログラム環境が推奨されているのでしょう。

　思うに、一つは "構文エラー" の排除ではないでしょうか。プログラム行の最後は ";" で終わらないとコンパイラに叱られますし、数式を記号で書くよりも、あちこちのパネルから選択して組み立てたほうが括弧の閉じ忘れもなく、間違いのない論理ができあがるという思想なのかもしれません。

　とにかくため息ばかりついていてもラチがあきません。アセンブラからJavaを経て異世界転生を果たした魔術師（エンジニア）ですから、さらに先を目指しましょう。この魔法陣的な模様の説明をしていきます。

① は省略できますね。天井グリッドの高さと地面グリッドの高さを出力ポートから出して ②の計算ノードの入力に繋いでいます。

② の『計算・減算』ノードです。

ノードエディタの左リストから【システムオペレーター】→【XPresso】→【計算】→【計算・加算】をドラッグしてノードエディタに引き込みます。
利用するのは【計算・減算】なのですが、これで正しいです。加算から減算に切り替える仕様です。

　切り替える場所はここ。

「なぜここでそっちへ飛ばすねん」と爆発しそうですが、我慢してください。

【計算・加算】ノードを選択したあと、属性マネージャの【ノード】タブを見てください。【演算タイプ】というドロップダウンがありますので、そこから『減算』を選べば、このノードは【計算・減算】ノードになります。

　ちなみに減算の順序は上の入力ポートから下の入力ポートを減算して答えを出力ポートから出す、というルールみたいです。

　要するに、

"出力ポート = 天井グリッド - 地面グリッド"

という意味です。
　逆にすると、地面から天井を引くので負の数値になって、正の数に戻すには、『絶対値(ABS)』ノード必要になって、ますます魔法の呪文が増えてしまいます。

③ は先ほど作ったGlobal定数の『ユーザーデータ』ノードです。

『ユーザーデータ』ノードの出力ポートからは、縮尺率を小数点にした『0.412』という数値が出ています。

④ は『割り算（除算）』ノードです。

減算と同じで、【計算・加算】を作ってから、属性マネージャの【ノード】タブから『除算』を選択します。

　やることは、

"天地間の距離 ÷ 0.412"

です。
　割り算の順番も『入力 1』÷『入力 2』となって、答えが『出力』ポートから出てきます。それが次の⑤へ接続されています。

⑤ は割り算の結果を小数第2位で四捨五入する『数式』ノードです。

単純な計算ではなく、いろいろな関数を利用した計算が実行できます。こちらも答えは出力ノードから出てきます。

『数式』ノードの入力ポートを作るには、左の青い四角アイコンをクリックします。すると、"V" と出ますのでそれを選びます。ノードが小さすぎて中が見えないときは、サイズを最適化します。そこに "V1"と正式な変数名になった入力ポートができますので、『数式』ノードをクリックしてから、属性マネージャへ目を移してください。

チェックを忘れずに

【ポート名を変数に】というチェックボックスがありますので、それにチェックを入れます。これで入力ポートの "V1" が数式での変数として使えるようになります。

　続いて、【数式】の入力フォームに次のように書き込みます。

　Round(V1*100)/100

これは最初に説明したとおり、小数第3位を四捨五入して小数第2位までを求める式です。この答えが出力ポートから出てきます。
　 "Round( )" で使用している変数 "V1" は、入力ポート名と同じにします。異なっているとエラーになります。他にも括弧の閉じ忘れだとか、数式として正しく記述しないとエラーになります。

「結局、正しくテキストで式を書かないとダメじゃないか……」というビジュアルプログラミングの矛盾みたいなものを感じますが、あまり深く考えないでいきましょう。

　数式にエラーがある場合は、ノード名の背面が黄色の警告色になります。黒色はエラー無しという意味です。式は正しいのにエラーが出るときは入力ポート名が違ってるか、【ポート名を変数に】というチェックボックスにチェックが入っているか確認してください。

⑥ は『テキスト』ノードです

このノードの入力に四捨五入した数値を入れると、内部で自動的に数値を文字コードに変換して画面に表示してくれます。昔の Basicみたいに、数値も文字もごちゃ混ぜオーケーの楽ちん仕様です。ここだけは助かりました。

『テキスト』ノードの入力ポートの選び方は、これまでとは少し違っていますので説明しておきます。

　例によって左の青四角アイコンをクリックします。すると【オブジェクトの属性】というのがありますので、それを選択して、次の【スプラインテキスト】を選びます。これで、そのノードの入力ポートは数値を文字に変換して指定のテキストスプラインから数字として表示されます。

　これと同じ作業をもう一つのテキストスプライン『E Level』の XPressoにも作れば完成。縮尺率の変更があっても、『CONSTANTS』ヌルのユーザーデータだけを変更するだけで済みます。

「修正は一か所で済ませろ！」
　アセンブラ時代から伝わる神のご神託ですね。

　長くなりましたが、これが Xpressoのノードエディタの簡単な使い方となります。もっと凝ればいろいろと便利なものが作れそうな気がしますが、なんだかなぁ……な気分はぬぐえませんでした。

　ただ、これだけはいえます。
　いまは、「なんだかなぁ」ですが、半年後にこの XPressoを見たときと、Java言語の構文だけでできたプログラムを見たときでは、Xpressoはデータの流れが可視化できていて、一目見ただけで構造の判別ができます。Java言語の場合は解析から初めて処理の流れを把握しなければなりませんので、たしかに視認性がいいという言葉に嘘はないと思いました。でもやっぱり、ノード内にも式の記入ができるほうがさらに便利になるような気がするのですが、なぜ、かたくなに別のパネルで書かそうとするのか……。

　結論。
　Xpressoは魔獣召喚の魔法陣だった。

　人間に代わって AIがプログラムをするバイブコーディングの時代がそろそろ始まっています。この魔法陣的なプログラムもきっと、AIが手を出すようになって、人間は「こんなのを作ってよ」って、指示をするだけのものに置き換わるのでしょうね。

　昔からよく言われていましたが、「プログラム言語なんていくつ知っていても意味がない」という言葉が現実味を帯びてきました。

(￣ω￣!) ｻﾑｲ …

２０２６年５月１日（金）１９.５℃（午前６時４８分）

　パースガイド作成ツール（その 4/6）[思わずうなる XPresso] 前編

進む戻る

　さて、いよいよ大詰めです。XPressoを追加して完成へと突っ走ります。

　XPressoを一言でいうと、ビジュアルプログラム環境といえるのではないでしょうか。絵で組み立てるプログラムです。
　といってもある程度はプログラムのことを知っておかないと理解に苦しむことになりますが、XPressoに興味を持つ人なら、おそらくプログラムの経験もある方だと想定して、その部分は省略させてください。

　まずは、カメラの動きに『ELオブジェクト』ヌルが追従するようにプログラムします。『ELオブジェクト』には『アイレベル』に関するものが入っていますので、ここは重要です。

　昔ながらのプログラム環境に慣れた方が、初めて XPressoの本体である、ノードエディタを開くと、たぶん尻込みするかもしれません。ワタシは思わず触ってはいけないものに手を出したような心境になりました。その感想は……。
「こんなもんでプログラムできるの？」で、
　しばらく使ってみて、

「あぁぁ。昔に戻りてぇ……」とため息をつき、やがて……。

「むふふ。めんどくさいけど、なんか楽ぅ～」

　そして……。
「もっと触りてぇ～」

　となったXPressoの開き方です。

XPressoを追加するオブジェクトをオブジェクトマネージャで選択後、①右クリック→ ②【プログラミングタグ】→③【XPresso】で、そのオブジェクトに XPressoタグが貼られて、同時にノードエディタが開きます。

　ノードエディタが開いたら、関係するオブジェクトをオブジェクトマネージャで選択後、ノードエディタの中へドラッグアンドドロップして作業に入る、という流れになります。

　それではやってみます。
『ELオブジェクト』に "XPresso" タグを作り、ノードエディタが開いたあと、『ELオブジェクト』と『カメラ』をノードエディタにドラッグアンドドロップします。その画像が次です。

ノードと呼ばれるブロックが二つ出ました（②）。
　一つは『カメラ』、もう一つは『ELオブジェクト』と書かれたノードです。それを適度な間隔を空けて配置します。

　これから制御したい流れを作っていくのですが、インストラクションとしての言語的な文字列は書きません。テキストエディタに "構文を記述する" なんて、「そりゃレトロ環境だろ」と言われても仕方がない、そんな気分になります。なにしろ、データの流れをノードに設定した "ポート" と呼ばれる入出力端子のようなものから、次のノードのポートへ線（ワイヤ）を引っ張って繋いでいくと、プログラムが進んでいくのです。

　思わずつぶやきますね。
「なんだこりゃ……」って。

　もしエディタが途中で閉じてしまったら、①の "XPresso" タグをダブルクリックすると再び開きますので、作業に戻ってください。

　ポートどうしの繋ぎ方は、電子回路図の書き方と同じで、左から右へデータが流れるように接続していきます。
　入出力ポートに指定できるものは、処理に適したものがノード別にたくさん用意されていますので、その中から選ぶことになります。

　まず最初にやりたいことは、『カメラ』の動きに『ELオブジェクト』が追従することですから、これは『カメラ』の位置を『ELオブジェクト』の座標に書き込むという処理を作れば実現できます。

　それをノードエディタで表現するには、『カメラ』の座標を『カメラノード』の "出力ポート" から出して、『ELオブジェクト』の "入力ポート" に接続します。

　では実際にやってみましょう。

出力ポートは『カメラノード』の右上にある赤い色の四角アイコンを左クリックして選びます。上の画像がその状態です。
　追従させるのに必要な出力ポートは、X,Y,Z座標と回転値の H,Bですので、X座標からいきます。
【座標】→【絶対位置】→【絶対位置.X】を選びます。

　すると、

X座標の値を出力するポートが『カメラ』ノードに追加されました

『カメラ』ノードの右に "絶対位置.X" と丸いポートが出ました。ここからカメラのX座標のデータが出てきますので、これを受け取る入力ポートを『ELオブジェクト』に追加します。

　『ELオブジェクト』の入力ポートは、左上の青い四角アイコンをクリックします。

出力ポートと同じ要領で、【座標】→【絶対位置】→【絶対位置.X】を選びます。

　で……。

X座標の入力ポートが『ELオブジェクト』ノードに追加されました

出力ポートと同じように『ELオブジェクト』の入力ポートに "絶対位置.X" ができました。（ピンク矢印）

　あとはこの出力ポートと入力ポートをマウスでドラッグすると接続線（ワイヤー）が出ます。

互いのポートをマウスでドラッグするだけです

まるでスケマティックエディタ（電子回路の回路図作成ソフト）みたいな感覚です。

　はい、つながりました。

完了です

これだけのことで、『カメラ』を左右に移動すると、『ELオブジェクト』も左右に動き、その子階層にある "Camera Height" という文字列も一緒に追従してきます。

　残りの『Y』『Z』『H』『B』のポートを作って、それぞれに接続すれば、この部分のプログラムは終わりです。
　ところで『H』『B』は回転角度です。『H』はヘディング（Y軸回転・カメラを前に向けて水平首振り）『B』はバンキング（Z軸回転・カメラを前に向けて左右に傾ける）ですので、追従させる必要があります。その回転角度のポート選択も手順は同じです。【座標】→【絶対角度】→【絶対角度.H】を選びます。

『P』のピッチング（X軸回転・カメラを前に向けて前後に首を振る）は、アイレベルの水平線が前後にうなずく動きですので回転禁止です。常に『0』になるように『定数=0』を入れることにしますが、『定数』ノードについては後述します。

【補足です】

いま、H,P,BをY,X,Z軸回転だと簡単に書きましたが、鵜呑みにしないでください。実はとっても複雑な構造になっており、3Dに手を出したことを後悔する、鬼門となっています。
詳しくは【回転は迷宮への路　その１：回転軸を理解する】をご覧ください。
このことを熟知しておられる方のみに、あえて、H,P,BをY,X,Z軸回転だと説明しました。

　ちなみに回転角度も手順は同じです。ポートの選択で、【座標】→【絶対角度】→【絶対角度.H】を選びます。

X,Y,Z,Hのポートを作って互いに接続すれば完了

これで『ELオブジェクト』はカメラの動きに追従して常に同じ場所に表示されます。

　途中でノードの中が狭苦しくなってきたら、手動でノード端を広げるか、右クリックで【最適化】を押すとちょうどいい大きさにリサイズしてくれます。

　次は『地面グリッド』が上下(Y)に動かないように固定する XPressoを作ります。仕組みは簡単です。常に『パースガイド』の Y座標で『地面グリッド』の Y座標を上書きするようにします。

作り方も同じです。『地面グリッド』に "XPressoタグ" を（ピンク矢印）作って、『パースガイド』の Y座標出力と『地面グリッド』の Y座標入力へワイヤを接続すれば完了。
　これで、『地面グリッド』を上下に動かしても、常に『パースガイド』の高さと同じ値になり動きません。

　というか……。
　こんな簡単な処理なら、

　地面グリッド.Y = パースガイド.Y

と書くほうが楽だと思うのは、古臭いのでしょうか。それとももっと複雑なものになると、ありがたみが分かるのでしょうか……。
　なんだか腑に落ちない「むむむ……」な気分です。

　このままでは生煮え状態ですので、次回はもう少しプログラムらしいことをやってみます。

　きっちり潜入……。(￣ω￣!) ﾔﾚﾔﾚ…

２０２６年４月２９日（水）２３℃（午後５時５５分）

　パースガイド作成ツール（その 3/6）[組み立て] 編

進む戻る

部品ができたら 3D空間に配置しますが、見えればいいだろうと適当に配置すると、途中で破綻します。正しく配置するにはオブジェクトマネージャを階層化して、数値入力での微調整が必要になります。

【ツリー構造にする】

作った部品は、ヌルオブジェクトを「親」としたツリー構造にまとめます。

　ツリー構造の利点は、親を動かせばその中に置いた "子" たちは位置関係を保ったまま一緒に動いてくれます。このことは、大きな箱（親）の中に小箱（子）が入っている状態をイメージすると分かりやすいです。箱ごと動かせば中身はズレませんし、箱の中での微調整も自由自在です。この構造を作ることで、パースの崩れを防ぐことができます。

　どのように動かせるのか動画にしてありますので、参考にどうぞ。

カメラを上に移動させると HUDの "Cam Height" の数値が変化して、 "アイレベル"（カメラ高）と呼ばれる "Camera Height "と示された白い水平線も上がっていきます。
　続いてカメラを俯瞰視点にしたまま水平にパンさせると、見る角度によって被写体までの距離が近づき、カメラから見た相対的な角度が変化するために、アイレベルの高さも上がりますが、石灯籠の高さや本殿の赤い手すりの水平高を維持していますので、カメラの本当の高さは変わっていないことが分かります。
　もちろんカメラを後ろに下がらせても、高さが変わりませんので "Cam Height" も変化しません。

　なぜ俯瞰視点で水平にパンさせるとカメラの高さは変わらないのに、アイレベルが上下するのか、疑問を持った方もおられると思いますので、詳しい理由を次の動画で説明します。

属性マネージャの位置座標値を見れば、カメラの動きがよく見えます

アイレベル（カメラ高）を詳しく観察すると、水平な平面だということに気づきます。カメラの高さに置いた厚みのない平面です。この平面は無限の広さを持っていて、カメラの前方へ向かって収束して、そのはるか彼方で消失します。その消失する位置に線を引いたのがアイレベル（カメラ高）水平線といえます。

　アイレベルとカメラの注視点を一致させると、それは一点透視となっています。ロボたちの腹部の高さで、はるか彼方で消失しているのがアイレベルを平面にしたおかげでよく見えています。

　その状態から俯瞰視点（上から見下ろす視点）へとカメラを上げると、カメラの位置が高くなって二点透視となり、アイレベル平面も大きく広がります。その状態からカメラを水平にしたまま左右に動かすと、三点透視となって次のような変化が起きます。

　被写体（フィギュアロボたち）を正面から見たときよりも、斜めから見たときのほうが、カメラが見下ろす角度が緩やかになり、かつ離れていきます。それにつれてアイレベルが少し下がります。逆に被写体を正面から見る位置に戻すと、角度が急になってアイレベルは画面の上へ動いています。

　この視線の長さの変化によって、カメラが物体を見下ろす相対的な角度が変わるため、アイレベルの高さが上下します。ただし、これはあくまでレンズを通した見え方の変化であって、3D空間上のカメラの座標（Cam Height）が一定であることは HUDの数値が証明しています。

　ここはワタシも悩んだところですが、確かにアイレベルは上下しますが、カメラ高さを示す水平平面の先は変化していない（石灯籠や手すりの高さ位置をキープしている）ので、これで正しく動いています。簡単にいえば上下するように見えているだけ……と何とも煙に巻かれたような気分ですね。

　持った疑問はさっさと晴らしておいたほうが、精神衛生的に良いかと思い説明を追加しました。

　では、先に進めます。
　次の画像がヌル（親）に入れた部品（子）が、オブジェクトマネージャでツリー構造に組まれた状態です。

最上位の階層（Root）に『カメラヌル』と名付けられたヌル（祖父）があり、その中に、『カメラターゲット』『カメラ』『パースガイド』『EL オブジェクト』という名前を付けたヌル（親）が同じ階層に並んでいます。そしてこの親の下層にも子がいて、その子にも子、つまり孫がいる状態ですが、一度に展開すると混乱しますので、上から順に紹介していきます。

　上の画像では、すべてのオブジェクトの位置座標と回転値を初期値として『0』にしてから、カメラだけを中心から後ろに下がらせた位置にセッティングしています。これは、すべてを『0』に初期化した途端、『カメラ』のターゲットと同じ座標になるため『カメラ』が地面を向いてしまいますので、地面グリッドの端まで下がらせています。上面ビューを見るとその様子がよくわかると思います。

　すべてのスケール値は『1』にそろえているのも重要です。これが狂っていると間違った計算値が出てしまいます。
　貼られているタグについては、この先の【下層階の説明】でします。先に中身の話をお読みください。

① 『カメラヌル』【移動可能】

Rootにあたる全体の親ですので、ワールド座標に置かれています。これを動かすとその下の階層に入っているもの全部が一緒に動きますので、このオブジェクトは移動用のキャリングケースだと考えてください。移動が終わったら、このヌルの位置にキーフレームを打って場所を記憶しておくのが無難です。

《重要》
『カメラヌル』はパースの向きを空間に合わせる基準になるものですので、撮影場所に移動させたら、撮影空間のパースの向きと『カメラヌル』の角度を合わせて、あとは、次の撮影場所に移動するまでは動かさないのが得策です。
　カメラやカメラターゲットを動かしても、ここが動かない限り、パース線やグリッド、高さ表示などのある HUD（ヘッドアップディスプレイ）も正しい位置で固定されます。

　カメラの位置を変える場合は、次の『②カメラターゲット』と『③カメラ』を一緒に移動させるとカメラ角度が変わらずに平行移動が可能です。
　カメラとカメラターゲットについては【Cinema 4D Liteやってます】内の【カメラ】で書かれている 2ノードカメラをお読みください。

② 『カメラターゲット』【移動可能】

カメラの注視点（目標点）を決めるヌルです。カメラは常にこのヌルを捉えようと追いかけてきますので、上下左右に動かして撮影する中心位置を決める役目を持ったものです。パースガイドの注視点（目標点）や、アイレベル、その他のHUD数値（ヘッドアップディスプレイ）も追従してきます。
　カメラアングルを複数作成するときは、位置にキーフレームを打って場所を記憶しておく必要があります。

③ 『カメラ』【移動可能】

カメラ本体ですから、撮影カメラマンのようにいろいろな場所やアングルを探して動かします。注視点（目標点）や、アイレベル、その他のHUD数値（ヘッドアップディスプレイ）も追従してきます。アングルの記憶をする必要がなくても、ここがいいかもという候補的なアングルを見つけたときは、カメラターゲットと一緒にキーフレームを打って場所を記憶させることを推奨します。でないと、その後変更してみたけど、やっぱりさっきのほうがいいや、となっても、元に戻すことは至難の業です。ましてや、複数のアングルを記憶させるつもりなら、常にキーフレームで固定させることを意識しておかないと、せっかく最良のアングルを見つけてもフレームを進めた途端、カメラが変な方向に動いてしまい、いまの努力が無駄になります。
　ワタシなど、どれほど悔しい思いをしてきたことか、そして何度プロデューサーさんに『あほか、お前！』と叱られてきたことか……。

『カメラ』には、 "◎" みたいなタグが貼られています。これは『カメラターゲット』ヌルを撮影対象として常に追いかけさせるものです。つまり、AEでいうところの 2ノードカメラとして機能しています。その目標点を目で見えるようにしているのが、赤いクロス線の『Look at Point』です。

　補足ですが、カメラオブジェクトの『オブジェクト』タブにある、"焦点距離" は『標準レンズ（50mm）』がおすすめです。それ以外にするとHUD表示の位置を再調整する必要があります。

④ 『パースガイド』【移動可能】

中には天井グリッドや地面グリッド、ダミーのフィギュアロボが入っています。その詳細は次の【下層階の説明】をお読みください。
　またこの『パースガイド』には『レンダータグ』が貼られて、【影を落とす】、【影を受け取る】のチェックを外しています。その理由は正式な撮影時にパースガイドに使用しているグリッドや水平線が、影を落としてしまわない配慮です。撮影現場でスタッフの影が見切れていたら、怖い監督さんにどやされますから。

⑤ 『EL オブジェクト』【移動・回転不可】

"アイレベル(Eye Level)（カメラ高を示す白い水平線）" を維持するオブジェクトが入っています。XPressoでカメラに追従するように制御されていますので、移動はできません。無理やり動かしても元に戻ります。

【下層階の説明】

今説明した親の子になるヌルオブジェクトについて説明します。

はい、これがオブジェクトマネージャにある 3つの親を展開した画像です。
　この階層にあるすべてのオブジェクトも位置と回転を『0』に初期化して、各親の中心に設置します。

　こちらも一つずつ説明します。

　『カメラ』の階層に入っているオブジェクト

『カメラ』の下層にあるオブジェクトをすべて展開させました。
　親となる『カメラ』の Z座標が『-450』cmとなっているのは、初期値の『0』にすると、カメラが下を向きますので、Z座標を『-450』cmにしてちょうどいい位置まで下がらせています。撮影に入ったらすぐに変化しますので、『カメラ』はこれが初期値です。

『カメラ』の下層に入れたオブジェクトは、HUDを構成する数値とキャプション（説明文）となる文字列が入っています。

　最初にある『グリッド間数値』というヌルには次の画像のようなテキストスプライン（ピンク枠内）が使用されています。

テキストスプラインの属性マネージャにある、①の入力フォームで、"cm : Height (Blue-Green)" と書かれたこれは、地面グリッドと天井グリッド間の距離に使用される単位と意味を示す文字列で、サイズは『0.1』cmと極小です。なぜこんなに小さくていいのか。それはカメラのほとんど前に設置しているからです。

　この画像をご覧ください。

先ほどのテキストスプラインを実体化しているのが、『天地間キャプション』という名の "押し出しジェネレータ" で、上の画像はその位置座標です。

　この『天地間キャプション』の親は『グリッド間数値』で、座標は『X=Y=Z=0』ですので、その位置はさらにその上位の親である『カメラ』の中心となります。
　つまり、『天地間キャプション』はさかのぼると、曾祖父である『カメラ』の中心ですから、上の座標値はそこからどれぐらい離れているかを示しています。

『X=0.02』、『Y=1.036』、『Z=6.3』cmとごく小さな数値です。これはカメラの中心からの距離ですので、これが本物の撮影カメラだとしたら、その鼻先で「カンッ！」と鳴らされるカチンコ板のような存在です。

『天地間キャプション』と同じ階層にある『Head Hi』という名前の "押し出しジェネレータ" も、テキストスプラインを実体化するものですが、ここはただの文字列ではなく、地面グリッドと天井グリッド間の距離を計算して表示する部分です。そのため半角数字を使わないとエラーになります。また、最初は初期値ですので、内容は『0』としています。

　XPressoが起動したあとは、自動的に変換された数値が出ます。数字の大きさや、表示位置も『天地間キャプション』の文字列と同じ大きさで、カメラからの距離もちょうどいい位置に設定してあります。

　それ以降のヌルの内容物もほぼ同じ種類のものが並んでいます。次の画像がそれです。

『カメラ高数値』の下層には "cm : Cam height" というキャプションとその数値になる半角数字が、ちょうどいい位置と大きさで表示されるように設置しているのも、さきほどの、『グリッド間数値』と同じです。

　その次の『注視点』の内容物は、カメラが撮影対象とする注視点を可視化するために作った、赤色の水平線と垂直線をクロスさせた直線と、それに付属する "Look-at Point" と表示されるキャプションです。これらも同じように『カメラ』のすぐ前に設置しています。

　たくさんのものが『カメラ』オブジェクトの下層階に格納されていますが、それほど難しいものではありません。重要なのはすべて『カメラ』の軸と同じ位置を起点にして、ほんのわずかだけ、その位置から見えるところまで離しているというところです。これが HUD表示の全体像となっています。

　次は『カメラ』と同階層にある『パースガイド』と名付けられたヌルを展開して、その下層階にある内容物の説明をします。

この階層には『ダミーグループ』『天グリッド』『地面グリッド』と名付けられた子ヌルが並んでいます。ここも、『天グリッド』以外はすべて『X=Y=Z=0』、『H=P=B=0°』が初期値です。『天グリッド』だけを『Y=165』cmにしてるのは、『地面グリッド』と重なると見苦しいので、初期値をグレーロボの頭の上にしただけで、深い意味はありません。

　最初の『ダミーグループ』の中にはフィギュアロボが二体入っています。
　次の『天グリッド』には天井グリッドとなる緑色の格子状のオブジェクトが、『地面グリッド』には青色の格子状オブジェくトを入れてあります。もし、垂直パースも入れるのなら、この階層に設置すれば同じように表示されます。

　重要なのは、この 3つの子の親になる『パースガイド』も含めて、4つすべてが撮影場所に合わせて、自由に動かすことができるようにするべきですので、フレームごとに移動位置のキーフレームを打って、場所を記憶するようにします。

　ただやみくもにオブジェクトを選んで動かすのではなく、次のように目的を持ってそのオブジェクトを動かすようにすると、混乱を避けることができます。

①『パースガイド』【移動可能】【回転注意】
カメラに関するもの以外の、グリッド・ロボなど全体の位置を変えるときはここを動かす

すべての親である『カメラヌル』はカメラも含めたキャリングケース（みたいなもの）ですが、『パースガイド』はパース線やフィギュアロボの移動だけに使います。ようするにカメラの視野の中にパース線が入るように調整するものです。回転させてしまうと、『カメラヌル』で決めたパースの向きまで変わってしまいますが、パースの収束する向きに合わせて、カメラは動かないが、パース全体が前後に傾くとか、首を左右にかしげるようにパースの角度を変える、などという特殊なことができますので、ここは回転注意としておきます。

②『ダミーグループ』【移動・回転可能】
ロボだけの位置を変えるときはここを動かす

オレンジロボとグレーロボを個別に位置を変えるときは、さらに下層にある個々のロボを動かしてキーフレームを打ちます。

③『天グリッド』【移動可能】【回転禁止】

天井グリッドを回転させてしまうと、すべての親である『カメラヌル』で決めたパース角度が変わってしまいますので禁止です。上下・左右・前後は可能。

④『地面グリッド』【左右と前後は移動可能】【上下は不可】【回転禁止】

地面グリッドはパースガイドの底（床）の基準となる重要なものですので、高さは変更できないようにXPressoで固定します。変更可能にすると、カメラ高の基準が動くので、数値が狂います。そこで今回は、上下には動かないというルールにしました。ただし左右・前後は可能です。この理由は、グリッドは有限の広さしかありませんので、必要な場所に動かさないと途中でグリッドが途切れてしまうという制約のため、左右と前後は動かせるようにします。回転禁止は『天グリッド』と同じ理由で、パースの向きが狂います。

　この関係をうまく使うと、3D空間に設置したオブジェクトの実寸法がリアルタイムで表示される計測器として使えます。例えば、パースガイドを校庭の高さに置き、天井グリッドを 2階の床に置くと校庭から 2階の床までの高さが実寸に変換されて表示されるという便利な使い方もできます。

　少々複雑ですが、これらのルールを守って位置座標を変化させると、パースが狂うことはなく常にカメラの視野に入ります。

　最後は『ELオブジェクト』の階層です。

『ELオブジェクト』は HUDを構成している『パースガイド』とは別扱いになっています。その理由は、XPressoで制御されて、『カメラ』が上下した時だけアイレベルの水平線が上下に動き、『カメラ』の注視点が上下左右に動いてもアイレベルの水平線は動かないという特殊な構造のためです。

　この動きは実際の撮影カメラを想像してもらえると理解できます。三脚に固定されたカメラの首を上下に動かしても、三脚の高さは変わらないのでカメラ高は変化しない、と同じ理由です。そのような制約ですので、カメラの子階層に入れることができません。そこで写真のように同じ階層に入れて、初期位置を『X=0』『Y=0』『Z=-450』として、カメラと同じ場所に置いてありますが、これは仮の位置です。Xpressoが起動すると移動も回転もロックが掛ったようにカメラに追従して、動かすことはできなくなります。

　その中身は単純で、 "アイレベル" を示す白い水平線とそのキャプション "Camera Height" という文字列が入っているだけです。
　これもこれまでと同じ、カメラと同じ場所にある『ELオブジェクト』の中心に親となる『アイレベル』ヌルを置いて、そこから少し前方に離したちょうどいい位置に "白い水平線とキャプション" を設置しています。

　ちなみに、キャプション文字の厚みは次の画像のようにほとんど『0』に近い数値にしています。

文字の押し出し値

この『0.01』cmという数値は HUDにもいえることですが、キャプションや数値が立体的に見えないようにする配慮です。立体的に見えると、とても不細工です。

　長くなりましたが、これが、パースガイドツールの構造になります。次はいよいよこれらに XPressoを追加して自動的に制御する話に移ります。

　パースガイドツールに乱入……。(￣‥￣!) ｱﾎﾔ…

《補足》
今回のパースガイドを入れた "Cinema 4D Lite" のプロジェクトファイルを『ギガファイル便』でダウンロードできるように予定しています。パースガイドツールをぜひ使ってみたいという C4d L使いの方は、最後にダウンロードページをつけますのでそれまでお待ちください。

２０２６年４月２８日（火）２３℃（午前１０時３分）

　パースガイド作成ツール（その 2/6）[部品作り] 編

進む戻る

前回はパースガイドがどのようなものかを説明させていただきました。今回は、きっと役に立つであろうことを信じて、そのツールを C4d Lで作る方法を説明したいと思います。

海の見える神社にセッティングした例
(足元から鳥居の下の横棒まで 3ｍ11cm。カメラは階段頂上より 30cm下がった、上から2段目の位置に設置）

パース線やグリッドは 3Dのオブジェクトとしてカメラの前に置いているだけですので、C4d Lでなくても普通の 3Dソフトなら作れるはずです。ただ、数値を表示するHUD（ヘッドアップディスプレイ）部分や、アイレベルがカメラに追従する部分は、C4d Lの XPressoを利用していますので、その部分はご自分の 3Dソフトで可能かどうかご確認ください。

　ちなみに、XPressoというのは、ノードエディタと呼ばれる、よりビジュアル的な操作ができるプログラム環境のことで、AE（After Effects）なら、エクスプレッション……あの JavaScriptをもとにした、呪文みたいな文字を書き込むものと、やってることは同じです。ただ、昔からプログラムをしている人が XPressoを見た途端、「なんだこれ？」と、まず最初に首をかしげる代物です。はい、ワタシがその代表者として立候補します。

　順を追っていきましょう。最初はパースガイドに使用する部品を作成します。
　次の画像がすべてのパーツが組み立てられたようすです。垂直パースはカメラが極端に上を向いたり、頭上高くから俯瞰したりしない限り大きく収束しませんので、今回は省略しました。必要な時は平面グリッドを追加して地面グリッドに対して、直角に立てます。

フィギュアロボの足元と頭の上に広がるのがグリッドです。青色が "地面グリッド（Ground）、緑色が "天井グリッド（Ceiling）" と呼んでいます。
　地面グリッドは基本地面を示していますが、床（Floor）、という意味合いが強いです。つまり、カメラの高さや天井グリッドの高さを計測するときの基準となる面です。
　赤い十字線（注視点）も白い水平線（アイレベル）もすべてスプラインパスに円形パスをスイープさせて作った針金みたいな直線です。円形パスでスイープするのには意味はありません。四角形でも同じです。角ばった針金ができ上がりますが、円形のほうがどの角度から見ても均一に見えるだろうという思いから円形にしているだけです。

　長さはあとで調整すればいいので、とりあえず、上記の画像で使用している地面グリッドを参考にしてください。

　地面グリッドを 1本だけにした画像です。

半径『0.2』cmの円形パスで『900』cmのスプラインパスをスイープさせて目に見える直線としたものです。それに青色の "発光チャンネル" だけを使用したマテリアルを貼ってあります。

　この 1本の直線をインスタンスのマスターとして、20本ほどを『50』cm間隔で均等に並べたものを縦と横にクロスさせて格子状にしたのがグリッドです。

均等並べにするときは、横線のスプラインを 1本作ってからそれを選択後、【ツール】→【複製】を使います。設定は次の要領で。

①【複製数】を任意に。カメラのフォーカス距離をグリッドの間隔、50cmで割った数より多めに、ここではフォーカス距離を『600』cmにしましたので、多めの20本弱にしています。早い話が地面や天井がどうなっているか、見えたらいいだけです。

②【クローンモード】を『インスタンス』か、『レンダーインスタンス』にします。『レンダーインスタンス』のほうがレンダリング時にメモリの使用量が少ないという話ですが、Lite版では効果が不明です。なのでワタシは、お守り程度にレンダーインスタンスにしています。

③【モード】を『線形』に。

④ 奥に向かって複製するなら、【使う】の『Z』にチェックを。左右方向へ向かって複製するのなら、『X』にチェックを入れて、【移動】に『50cm』と入れてから、【適用】ボタンを押します。
　複製ツールを使うときは、親の階層の中で作らずに、Root階層（ワールド座標系）で作ったほうが、複製のマスターからズレずに完了します。できてから目的の親の階層に設置するのがスマートです。

地面グリッドができたら、それを参考にして天井グリッドも同じ要領で作ります。天井グリッドのほうが格子の数を少し多めにしたほうがバランスが良い気がします。

　赤の十字線はカメラのレンズがどこを向いているかを表す線ですが、これも 2本のスプラインパスをスイープして直線を作り、それぞれの中心で、直角（90°）にクロスしたものに、赤色のマテリアルを貼っています。線の太さになる円形の半径はあとで調整しますので、最初はひとまず、0.2cmで。
　アイレベルの水平線も同じぐらいの長さと同じぐらいの太さの直線を作って、白のマテリアルを貼ります。

　重要なのは、赤の十字線と白の水平線の軸は、親となるスイープの中心に来るように作ることです。中心から外れていると、微調整のときにカメラのレンズから大きくズレますので、必ずスイープの中心に設置するようにしてください。

【軸を中心にといいますが……】

オブジェクトの軸合わせは、モデリングするうえで最も重要な意味を持っていますので、軸がどこにあるか常に把握する癖をつけることだと思います。そのためにはスプラインで作成したオブジェクトの軸を自由にコントロールできるようによく慣れておくことが大切です。

　3Dを始めて最初の 1年は、オブジェクトの位置と回転の呪縛に囚われてしまいがちです。しかし、軸の意味を正しく理解し、自在にコントロールできるようになって初めて、その呪縛から解き放たれ、自由奔放にオブジェクトを配置できるようになります。

　スプラインオブジェクトについて詳しくは【スプラインオブジェクトやスプライン全般】
　スプラインオブジェクトの軸の移動方法は、【ジェネレータを使うとオブジェクトの軸が変なところにできる】などをご覧ください。

　話が長くなりましたが、部品の最後はダミー的な存在となるフィギュアロボの話です。

　フィギュアは二体作っていますが、数は自由です。なくても構いませんが、空間を認知するときにカメラをどちらに向ければいいのかとか、近くにあるオブジェクトのサイズは適正なのか、などの校正には最適な基準となる、空間の "ものさし" がこのロボたちです。

　そこで、ワタシはグレーのフィギュアを『165』cmになるように縮尺率に合わせてスケール値を調整しています。例えば作品の縮尺を実際の半分、50%としたのなら、82.5cmの高さにして、3D空間に置きます。するとその周りにあるもののサイズも自然と見えてきますので、それに対して適正サイズになっているかなどのチェックができます。

　このフィギュアはプリミティブメッシュの中にあります。オブジェクトマネージャに出したあと、 "C" キーを押すか、右クリックして "編集可能にする" を実行しますと、関節が動かせるようになりますので、好きなポーズにすることができます。

　さて、ここまではそれほど難しくなく、慣れた人なら数時間もかからないと思います。
　次回は、カメラの動きにパースガイドを追従させるために、これらの部品をオブジェクトマネージャでどう階層化して組めば都合いいか、ということを考えます。

アウトドアでもパースが……。

　寝てもパース、起きてもパース……。　(￣‥￣!) ｱﾎﾔ…

２０２６年４月２４日（金）２２℃（午後４時２３分）

　パースガイド作成ツール（その 1/6）[3Dに必須のパースマップを作る]

進む戻る

現在ストック素材を扱うサイトさんでは、生成 AIで作られた素材であふれかえっています。
　なにしろどんな絵であろうと文章で命じるだけ。あっという間に描かれ、その完成度も目を見張るものです。それを目の当たりにした多くの絵描きさんは、将来の活路を閉ざされた気分に苛（さいな）まれたそうです。

　しかし、ようやく最近気づきました。AIが手がけた絵はきれいに描かれてはいますが、なにも伝わってこない毒々しいまでの濃い色彩で、かつどれも同じようなタッチのものばかりです。そんな絵ばかりがストックサイトさんに集まり、埋め尽くされて今やパンク状態。これではいけないと、4月20日、ついに大手のストックサイト、PIXTA（ピクスタ）さんから、「AI生成コンテンツの取扱いを停止します」という趣旨のメールをいただきました。ようするに『今後は生成 AIの作品は禁止するから詳しくはここを見てね」という内容でした。

　AI加工に関する新しいガイドラインはこちらです。 https://pixta.jp/guide/?p=73841

　ワタシも補助的なことで、生成AIを使うことはありますが、ストック素材さんに提出する分に関しては、使わない考えで貫いています。それにもかかわらず、何度も生成 AI作品と誤認識されて却下された苦い経験があります。
　そこで、生成 AI画像ではない証明書（エビデンス）なるものを付属させた作品を提出する実験を始めました。それを作成するのがパースガイドツールです。

　3Dソフトで作成した画像と AIが作成した画像を見比べたらわかります。一見精巧に見える AIの画像ですが、補助線を引いてパースを確認すると、消失点が一致しなかったり、奥にある物の縮尺の変化が不自然だったりすることが多いです。3Dソフトでは数学的に正確なパースを維持できますので、細部まで正しく描くことができます。
　これをヒントにワタシが考えたのは、その正しいパースを示す補助的な "ものさし" です。それを簡単に作るのがパースガイドツールです。

　絵を描くことに手慣れた人は、目の前に 3Dの背景画を突き出されても、パースの状態を瞬間に把握できて、絵を描き足すことができるそうですが、空間の状況を物理的に目に見えるものにしてくれないと、ワタシのように人物を描くことに関しては素人に近い人間には、どう描いていいのか把握くしにくく、見た目の感覚だけで判断していますので、「パースがあってない！」と、よくプロデューサーさんに叱られるのです。

　この目に見える形にしたものがパースガイドです。これはアニメやゲームの絵を描く際の奥行きの指標となるもので、パースマップと呼ぶほうが一般的かもしれません。
　あ、そうそう、「右手と左手が逆になっとるゾ」と叱られることも頻繁にありますが……これは別問題ですね。

　しかし、そのパースガイドを支給された背景画に手書きで作成していては本末転倒。その手間を考えるとやる気が失せます。そこで支給された背景画の付録として、パース情報を同梱させたらどうだろうかというものです。

　ようするに 3D画像をストックサイトさんへ提出するときに、一緒にガイドも付属させます。すると購入した人がパースを気にする方なら作業の手助けになって喜び、ついでに生成 AIで作ってませんよという証明にもなりそうです。それがこの素材例になります。

提出した素材の右欄に各種データが書かれており、その下にパースだけの PNG画像と、作品をグレースケールにした上にオーバーレイしたものが付属しています。これがパースガイドです。このガイドのどちらかを使用するソフト内でコピーして、別レイヤーにペースト後、3倍に拡大すると左の素材と同寸になりますので、上から重ねてガイドとして使用できます。手書きでパース線を探るより数倍スピーディだと思いませんか？

　ちなみに実用性があるかどうかは利用する人の主観によるもので、「くだらんもんを……」と、一笑に付するかもしれませんが、そこんところは責任を負えませんので悪しからずです。少なくともワタシは大いに助かっています。

　百聞は一見に如かず。パースガイドが使い物になるかどうか、いろいろな角度から検証してみました。
　まず最初は、ガイド無しの画像です。もっとも簡単な 3Dの学校モデルを真正面から捉えた絵に『いらすとや』さんからいただいた 2Dのイラストを設置してみます。

中庭でお茶を飲む生徒

お茶を飲んでいる生徒の絵は、厚みの無い平面に貼られた PNG画像です。このようなものを "ビルボード" と呼び、3Dゲームの世界などでリソース節約のためによく使われる技法です。2Dの絵ですが、カメラに正面を向けている限り、ほとんど違和感が出ません。つまり、上の画像はイラストの角度に背景の角度を合わせていますので、それなりに映っています。

　ではこれにパースガイドを出してみます。

はい、出ました。いろいろな色の線が出ていますが、それはもう少し先で説明します。

　まずはパースガイドの重要なところです。ここを覚えておいてください。

　縮尺の比率が現物と合っていないものが組み合わさっていると、空間に違和感が生じ、当然パースも大きく狂います。
　ですので、モデリングには基準となるものが必須です。それが上の画像に出ているグレーのフィギュアロボとオレンジのロボです。これらは、ダミーの被写体だけではなく、縮尺率に忠実に合わせた測定器の役割を果たします。

　今回の学校モデルは『41.2%』の縮尺で作っていますので、身長 165cmに想定したグレーロボはこの空間では 68cm、女子をイメージした 160cmのオレンジロボは 65.9cmで作成してあります。もちろん、ベンチに腰かけているロボも同じ比率です。
　校内は、黒板や机、廊下の幅、天井までの高さ、階段の段差など、膨大な数の構造物や備品で構成されています。これらを実寸通りの比率でモデリングした後、このロボを並べて正しいサイズになっているか、見た目に違和感がないかを比較、確認しています。

　次に重要なのは、パースガイドはカメラの付属物として扱うのがポイントです。
　3D作品を画像として書き出す際には必ずソフトに装備されたカメラオブジェクトを使います。使わなくても画像は出力できますが、カメラを使えば複数のアングルを保存でき、ミリ単位の微調整もできます。そしてそのカメラに連動してパースガイドが動けば、"カメラの高さ" や "床から天井までの高さ" を縮尺率から逆算して、実寸を正確に割り出すことができます。これにより本素材とは別でありながら、同じアングルでガイド専用の画像を書き出すことができます。

　これまではそれを電卓片手で計算していましたので、その効率は、"劇的" よりさらに上の "爆劇的" に向上しました。

　それでは、ガイドの細かい説明をします。

①の青色の格子は、"地面グリッド (Blue Grid)" と呼んでいて、 "カメラの高さ（Camera Height)④" と "天井グリッド⑤" の高さを決める基準点になります。この絵ではロボたちの足の裏が着いているところが、"地面グリッド (Blue Grid)" ですので、茶色い地面と同じ位置ですが、常に地面の上とは限りません。階段の途中の場合もありますし、3階の教室にいることもありますので、基本は被写体の足下に置きます。

②の赤色のクロス点は、カメラの "注視点（目標点）" と呼ばれるもので、画像では "Look at Point" と表示しています。これはカメラがどこを向いているかを表したもので、上の例では、女の子の頭と座っているロボの頭の、中間少し上あたりをレンズが睨んでいると思ってください。

③の上段の数値 "Height (Blue-Green)" は、①の地面グリッド（Blue Grid）から、⑤の天井グリッド(Green Grid)までの距離を実寸に変換した数値で単位は『cm』です。
　下段の数値 "Cam height" は、カメラのレンズが、①の地面グリッドから何センチところにあるかを示した "レンズ高" で、④の "アイレベル" を数値化しています。地面グリッドよりも下になると負になります。数値は実寸表記です。

④の白い水平線は、"アイレベル" と呼ばれるもので、画像では "Camera Height" と表示されています。これは、③のレンズの高さ（カメラの高さ）位置を水平線で表したものです。上では座っているロボの肩から女の子の目のあたりを突っ切っています。アイレベルよりも注視点が上にあるので、これはあおり撮影だと判断できます。また、カメラがフレームから大きく離れるとアイレベルは見えなくなりますが、③の下段の数値が目安になります。

⑤の緑色の格子は "天井グリッド (Green Grid)" と呼びます。①の地面グリッドから ③の数値（上段）だけ離れた位置にあります。

⑥の両サイドの黄色い縦線は、上下方向（垂直）のパースを示すものです。校舎の柱の線と並行に走っています。

　上の画像を見ると、⑤の天井グリッドがグレーロボの頭から離れたところを通っているように感じますが、③の数値（上段）に 165cmと出ていますので、①の地面グリッドから 165cmのところに "天井グリッド" があることを示しています。これはロボの足も地面グリッドの上ですから、身長 165cmのグレーロボの頭の上にグリッドが広がっていることになります。
　ということで、総合的に見ますとこの背景画は、高さ 97.8cmの位置に置いたカメラから、ほんの少し見上げた（あおり）視点で被写体を正面から撮影しており、灰色ロボの頭の上、ぴったりの位置に天井グリッドが広がっていることが分かります。

　別の画像で検証してみましよう。

①地面グリッド ②注視点 ③天地間とカメラ高 ④アイレベル ⑤天井グリッド ⑥垂直パース

先ほどの位置より左上から撮影した画像ですが、ビルボードの女の子はもう限界ですね。ペラペラの板だというのがバレバレです。もし仮にカメラの向きにビルボードを回転させてもベンチに足がめり込みますので、どうしようもないですね。

　ガイドの情報では、ロボたちの足下から 3m76cm（③下の数値）の高さ、校舎の 1階天井付近まで上がった場所（④）にカメラを置います。そこから座っているロボの右耳あたりを注視点（② 赤のクロス）とした俯瞰視点で撮影されています。もちろんパースガイドは奥行き感を正しく表現（①・⑤）しており、天井グリッドは先ほど同じく、グレーロボの頭上を広がっています。そして、ロボたちのパースも狂っていませんので、これを参考にイラストを描くことは可能だと思います。

　もう少しパースガイドがはっきりとする場所に移動してみます。

これはアイレベル（カメラ高）と、注視点がほぼ同じ高さで、82.1cmです。身長（165cm）の中央から水平に撮影していますので、奥に向かってだけパースが収束しています。収束というのはその線を果てしなく延長していくと、いずれ一点に収束します。このように収束した点を消失点といいます。ところが、垂直方向や左右方向には収束せずに平行のままですので、この背景は一点透視の視点だといえます。

これは先ほどの画像とアイレベル（カメラ高）は変わりませんが、カメラを水平に右方向へ移動させた場所から撮影していますので、奥行きだけでなく、左の体育館に向かってもパースが収束しています。そして垂直方向は変化なしで平行のままですから、この背景は二点透視だといえます。

これはだいぶ高い場所から見下ろした俯瞰視点で撮影されていて、アイレベルが校舎の 1階天井あたりで、3m3cmと出ています。そこからロボたちの頭の少し上あたりを狙った画像だと判断できます。
　パースは奥に向かってと、上から見下ろした視点ですので、垂直方向の地面奥深くで収束するはずです。そして左右方向は収束せずに平行ですので、この絵も二点透視です。

最後はこれです。ドローン撮影のような画像になっています。地面グリッドと天井グリッドの区別がつきにくくなりますので、天グリを 16m20cmまで上げています。そしてアイレベル（カメラ高）は 26m36cmもありますので、校舎の 3階よりも上になります。
　パース線は、奥行（校舎の裏の先で）、垂直（地面奥で）、そして左右（体育館のはるか遠くで）収束しますので、この絵は三点透視です。

　だいぶパースについて理解できたところで、別の使い方にも目を向けてみます。地面グリッドと天井グリッドをうまく使いますと、この 3D空間での高さを簡単に現実での寸法に変換して求めることができます。

上の画像は、1階と 2階の途中あるの踊り場に被写体が立っていて、地面グリッドは校庭の高さに置いて、天井グリッドは灰色ロボの頭の位置に置いた画像です。

　これから見て取れるのは、天井グリッドが校庭から約4m11cmの高さにありますので、灰色ロボの身長（165cm）を減算すると、階段の踊り場は 2m46cmほどの高さになります。これは校庭から 1階の床までの高さと、2階の床の厚みを考慮してもほぼ建築基準に近い数値だと思います。
　そしてカメラは校庭（地面グリッド）から高さ 8.3cmの場所に置き、被写体の足下あたりにレンズを向けたあおり視線で撮影されています。

　さて、これが最後の検証です。
　学校の校舎という巨大な建造物ではなく、こじんまりとした場所でもパースガイドは使いものになるか試してみました。次の画像です。

喫茶店の3D画像です。カウンターがあって、その前にはテーブル席が並んでいる、レトロな雰囲気が漂う店内に仕上がっています。
　天井グリッドを約2m30cmの位置にして、それより高い場所（2m64cm）から俯瞰視点で撮影した画像です。これも奥行、垂直、左右それぞれに収束しますので、三点視点です。天井グリッドのパースや、灰色ロボとオレンジロボの体の向きなどを参考にすると、絵が描きやすくなるのではないでしょうか。

　パースガイドだけを出力するとこうなります。

　長々とパースガイドツールの説明をしましたが、このデータがあれば、背景画がどのような空間に広がっているのかが一目瞭然ですし、手作業でパースを探るより素早く作業にかかることができるのではないでしょうか。

　ということで、次回は C4d Lを使って自分でもパースガイドを作ってみようと思われた方に、作り方を説明します。

インドアでも……

　ベテランの絵描きさんにとっては、パースガイドなんてじゃまになるだけかもしれませんが、正確な絵を描きたい人や、構図で迷うのが嫌だという方には、メガネをかけて物を見るように、心強い味方になると、ワタシは信じています。

　現在、オーバーレイできるパースガイドを、ストック素材に付属させて提出するというアイデアを実行中です。どこかで見かけたら、このサイトを思い出していただけると幸いです。

２０２６年４月２０日（月）２６℃（午後１時２３分）

　運び屋ヌル登場……

進む戻る

タイトルは怪しげですが、やろうとしていることはただのデータ転送です。
　どこからどこへ転送するのか、それは C4d L（Cinema4D Lite）から AE（After Effects）へ送ります。

　本題に入る前に、ウォーミングアップです。
　変化する数値を AEで表示するにはどうするか。刻一刻と変化する数値を AEの画面に出すシチュエーションって、そうそうあるものではないのですが、いざやろうとすると戸惑います。ただ、AEにはそれを簡単に実現できる "スライダー" というものがあります。

　これは、打ち込んだキーフレームの範囲の数字をフレーム数で割って均等に埋めた数値の変化を見せてくれるものです。
　例えばスライダーの最初のフレーム（0秒目）にスライダー値を『0』として打ちます。
　続いて、1秒目に『30』と打ちます。そして映像のフレームレートを『30fps』としていると、スライダーの表示数は、1フレームごとに『1』ずつ増えていくことになりますので、画面では 1秒間に0から 30の数字の変化が見られます。
　映像の中で、残り時間を表示するときなどにスライダーは重宝します。

　今回はこのような方法で、数値を表示するのではなく、Cinema 4D Lite（以降 C4d L）から、特定のオブジェクトの座標を AEに送って、送られてきた数値を AEの画面に表示させよう、というものです。

　かなり特殊な案件ですが、物理や数学系の映像を作るときに必要になるかもしれません。以前、2D画像でしたが、水を入れたコップの中を直進する光の屈折シミュレーションの依頼があったときに、光線の角度と反射角の変化を図解だけでなく数値も変化するものを作ったことがあります。計算が大変になるかもしれませんが。この方法を使えば 3D空間で折れ曲がる光の軌跡も可能かもしれません。

　まずは、C4d Lにあるオブジェクトの座標値を AEへ送ってみます。

　C4d Lから AEへ数値を送るには、Cinewareにある【Extract（抽出】機能を利用します。何を取り出すのか、それは C4d Lの 3D空間に置いたヌル(null)オブジェクトの座標値です。

　べつにヌルでなくてもいいのですが、ヌルは実体がありませんから、ヌルの座標値にどんな数値が入っても映像には影響が出ません。ですので、数値の "運び屋" として使うのに好都合です。例えば、『A』と『B』というオブジェクトがあったとき、二つの距離を求めて、このヌルの座標へ入れて AEへ送るという使い方を考えたとき、"運び屋ヌル" の座標に入れられた数値で、このヌルは宇宙のかなたまで跳ばされるかもしれませんが、もともとが幽霊的存在ですから、映像には問題が起きません。そして【Extract（抽出】機能で、AEからその座標値を読みだせば『A』と『B』の二つの距離が伝わるという算段です。

　もっとぶっ飛んだ考え方をすれば、C4d Lの XPressoで収集できる数値ならなんだっていいんです。デフォーマーの強度であろうと、ライトの色温度であろうと、運び屋ヌルのX、Y、Zのいずれかの座標に突っ込んで運ばせることができます。

　ただし、AEと C4d Lとの間では『座標に対する基本のルール』が根本的に異なっている、ということを知っておかないと、うまく事が運びません。それを知ってもらうために、少々ややこしい方法ですが、次のような構造のものを C4d Lに作りました。

何もないガランとした空間に立方体が一つと、赤い球が一つあるだけです。

　オブジェクトマネージャを拡大しますと……。

立方体はこの3D空間のワールド座標系に置かれています。
　ワールド座標系というのは 3D空間全体の動かない中心を基準にした座標系です。つまりこの映像という宇宙の "絶対的な中心" みたいなもので、その中に立方体を置いて、その下層に『Val_Y』と名前を付けた "運び屋ヌル" を置いています（①）。

　簡単にいえば、宇宙のとある場所にある地球（立方体）の中にある日本（運び屋ヌル）という親子関係です。赤い球は、この日本（運び屋ヌル）を親とする、その中心に置いた子ですので、親が動けば赤い球も一緒に動きますし、親の位置が分かれば赤い球の位置も分かります。

　パソコンに詳しい方向けに説明しますと、ワールド座標系はファイルの階層構造でいう、おおもとの『Root』にあたります。子である運び屋ヌルから見た立方体は、上位ディレクトリに位置する親となります。逆に、赤い球から見れば運び屋ヌルは親、その中心に位置しているため、親の位置と赤い球の位置は同じです。
　この関係から、ワールド座標は誰から見ても変わらない "絶対座標"、オブジェクト座標（ローカル座標系）は親を基準とした "相対座標" と呼ばれます。

　そして、ここが今回の最大のポイントです。【Extract（抽出）】を通して AEへデータを送ると、運び屋ヌルが持っていた "親（立方体）からの距離" という相対座標は、自動的に Rootからの "絶対座標へと強制変換" されてしまいます。

　次です。
　"②" の場所に見たことのないタグが貼られています。

　これが AEへ送りなさいと命じる重要な【Cineware】タグと呼ばれるもので、AE側の Cinewareパネルにある【Extract】ボタンから抽出することができるようになります。
　AE側ではそれを受け取って、エクスプレッションを利用して画面に表示させる流れになります。

　まず、数値を転送しようとしている C4d Lのプロジェクトファイルを保存してから、AEを起動してそのファイルをインポートします。画面が出たら【Renderer】を【Current】にします。

今回の C4d Lのプロジェクトファイルはとても軽いものですので、すぐに画面が出ると思います。AEの画面に C4d Lと同じ赤い球と立方体が表示されたら【Cineware】パネルの下のほうにある【Etract】ボタンを押します。

ほんの少し間が空いて、レイヤーパネルにいくつかのレイヤーが作られて並びます。

説明を続ける前に、一つ注意があります。

　前回も書きましたが、Cinewareの妙な癖として、一度取り込んだ ".C4d" ファイルを修正して再読み込みをすると、キャッシュをなかなか消してくれない、というとても迷惑な癖があります。

　修正後のファイルを保存して入れ替えたにもかかわらず、AE側では過去のものを表示したり、あるいは真っ黒な画面になることが頻繁に起きます。AEを再起動すれば新しいものに切り替わりますが、そのたびに再起動は面倒なものがあります。そしてこの Extractで取り込むときも同じで、取り込んだレイヤー類をすべて消して、再度 Extractボタンを押しても以前のままで変化しない状態が続きます。

　今回のような数値を扱うときは、正しいものが送られてきているのかよく分からないものです。そんなときにキャッシュが消えず以前の状態を維持していると、大迷惑ですので、この件に関してはご注意ください。どうも最新の状態になっていないな、と思われる場合は次の方法で、AEにカツを入れてやってみてください。

① AEの【編集】→【キャッシュの消去】→【すべてのメモリとディスクキャッシュ】を押して、計算データを真っ新にします。

② プロジェクトパネルの『c4dファイル』を右クリック、【フッテージの置き換え】で、同じ『c4dファイル』を、再読み込みをします。

③ それでもだめなら、Extractで取り込んだレイヤーをすべて削除してから、もう一度 Extractを押して再読み込みします。

④ ここまでしても頑固に切り替わらないときは、AEの再起動を試してみてください。
（案外 C4d Lのファイルを保存していないときもありますので、振り出しに戻してみてください）

話を戻します。

　Extractボタンを押して、運び屋ヌルのデータが取り込めたら、"①"の場所に『Val_Y』というレイヤーができていますので、その上のレイヤーに "空のテキスト" レイヤーを 3つ作ります。それぞれ、X座標用、Y座標用、Z座標用としますので、レイヤー名を替えておきます。

　続いて、それらのレイヤーにエクスプレッションを書いていきます。
　Altを押しながら、『ソーステキスト』と書かれた欄にあるストップウォッチアイコンを押すと右側にエクスプレッションエディタが開きますので、そこへ X座標用のテキストレイヤーなら、X用のエクスプレッションを書き込みます。

書き込むエクスプレッションは次のとおりです。


 "Val_Y" は『運び屋ヌル』に付けた名前です。Extractで取り込まれてレイヤーになっています

【X座標用】
	v = thisComp.layer("Val_Y").transform.position[0];
	"X = " + v.toFixed(1) + "cm"


【Y座標用】
	v = thisComp.layer("Val_Y").transform.position[1]; 
	"Y = " + v.toFixed(1) + "cm"


【Z座標用】
	v = thisComp.layer("Val_Y").transform.position[2]; 
	"Z = " + v.toFixed(1) + "cm"

　これらのエクスプレッションで『Val_Y』の座標値を小数第一位に四捨五入して、それをテキストに変換して表示しています。

　上の画像では、『Val_Y』レイヤーの位置プロパティが閉じていますが、開くとすでにキーフレームが打たれているのが分かります。一つずつフレームを進めると画面の座標値が変化していきます。

　さてここまでは準備段階でした。ここからが今回の本題です。（長いな）

　この C4d Lと AEとを連携させた動きを動画にしてありますので、まずはご覧ください。

AEとの連携：数値の転送

10フレームで赤い球が立方体の前を上へ向かって動きますので、座標値も変化しています。
　AEでは、C4d Lから送られてきた運び屋ヌル（Val_Y）の数値を画面に表示していますが、おかしなことに AE側の表示と C4d Lの数値が違っています。

　これが AEと C4d Lで『座標に対する基本のルール』が異なっている証拠です。
　つまり、C4d Lにある運び屋ヌルの座標は相対座標ですが、それが絶対座標に変換されているため、このような食い違いが出ます。

　詳しい説明の前にこの画像をご覧ください。

運び屋ヌルの親の座標です。すなわち絶対座標です。

　X座標は『500』cmです。そして運び屋ヌルの座標は、映像（0:32あたり）を見ると、X座標は『-200』cmとなっています。これらから考えると、

　親である立方体は『500』の位置。
　子である運び屋ヌルは親の中心より『-200』の場所です。
　ということは、絶対座標から見れば、『500+（-200）』、答えは『300』となり、それが AEの『X＝300.0』となっています。

　もう一つ試してみましよう。
　今度は最後の 10フレーム目の映像で止めてください（0:44あたり)。
　立方体は動いていませんので、X座標は『500』のままです。
　運び屋ヌルのX座標は『250』です。

　ということは絶対値は『500+（+250）＝750』となり、それが AEの『750』cmです。
　Z座標についても同じですが、注意しなければいけないのは Y座標です。Y座標は常に符号が逆になります。

　10フレーム目で例えると、
　立方体のY座標は『100』で。運び屋ヌルは『300』なので、絶対アドレス変換すると
『100+(+300)=400』としたあと、『-1』を掛けて負の値にして、『-400』です。この理由も AEと C4d Lでの座標の考え方に相違があるからです。

　AEでは Yを上へあげていくと、マイナス方向へ数値を数えます。C4d Lは上にあげるとプラスの方向へ数えます。この違いがあるために、Extractで抽出した瞬間、この変換が行なわれるということになります。

　実は、運び屋ヌルを立方体の子階層に置いたのは、このことに気づいてもらいたかったからです。本当なら運び屋ヌルはワールド座標（Root）に置くべきですね。

　ということで……。
　運び屋ヌルはできる限りワールド座標（Root）の階層に置く。置けないときは絶対座標に変換されることを知っておくこと、そして、AEに渡ると Yの値は符号が逆になる。
　このルールを知っておけば、もう運び屋ヌルはこちらのもんです。
　例えば、ターゲットカメラのヌルを運び屋として使えば、これまで手動で動かしていた AEで作る『雲』や『レンズフレアー』を C4d Lのカメラの動きを読み取って自動的に正しい方向へ移動するものだって作れてしまいます。

　何に利用するかはあなたのアイデア次第となります。

おっさん、でかい顔してんじゃねーよ

次回は C4d Lの世界で数値の表示をさせる。パースガイドデータの作成方法です。

２０２６年４月１５日（水）２４℃（午前１０時２９分）

　Cinema 4D Liteと AEとの連携（ちょっとレベルアップ）

進む戻る

Cinema 4D Lite（以降 C4d Lと書きます）の記事が連続していますが、AE（After Effects）と連携させると、多少頭から煙が出ることもありますが、作品に 3Dの効果を盛り込んだ、一段上のレベルに到達できる可能性があります。

　ただ、C4d Lは 3D画像を作成するアプリではあるのですが、悲しいことにAEに付属した廉価版ですので AE無しでは動画どころか、静止画も出力することができません。
　でも安心してください。作成した 3D画像を AEに取り込むことは可能です。AEに入ってしまえばもうこちらのもの、ありとあらゆる画像編集に準備されたエフェクトや動きを加えて不可能だった表現が実現できます。

　そんな AEとの連携作業にちょっとした便利な使い方を紹介します。
　まずは一つ目。

　カメラボケを作る

"カメラぼけ" といっても、
「ゴールデンウィークに休み過ぎて、なんか仕事が億劫だなぁ、休みぼけかな？」の、ぼけとは違いますよ。
「あったかくで、池の水が気持ちよくて眠いよぉ……」て、それは "カメのぼけ" ですね。
　なんて、くだらんことを書いているから、ここの記事は読むのが疲れる、と言われるのですね。（反省）

　ここでいうカメラボケとは、五月病のことでも、池でウトウトしている亀のことでもありません（まだ言うか）。
　映像制作において、ピントが合っている場所とボケている場所を意図的に作り、画面にメリハリのある奥行き感を生ませる "被写界深度" のことです。

　3Dソフトの世界には、現実のレンズやフィルムを数学的に再現した "仮想のカメラ" が搭載されています。実際にレンズで光を集めているわけではありませんが、本物のカメラの挙動を忠実にシミュレーションしてくれるので、これらも親しみを込めて "カメラ" と呼んでいるわけです。

　AEに搭載している 3Dカメラには、この被写界深度が含まれていますので、手前はピントをあわせておき、ある距離から奥はふわっとぼかしたりすることができます。Cinema4Dにもこの機能があるのですが、C4d L用のカメラには廉価版の制限が入っていて、使うことができません。

「なんでやねん！」
　思わず叫びたくもなりますよね。

「ここまで 3Dの機能が装備されているのに、カメラぼけが使えないなんて殺生ですぜ、旦那！」
　ということで、これを AEのエフェクトと連携させてやっちまおうという作戦です。

　概要をざっと説明します。詳しい方ならすぐに理解されると思います。
　まずは、C4d Lの【カメラオブジェクト】の【詳細】タブを開きます。その中にある【デプスマップ後ボケ】にチェックを入れて、終了位置をカメラの【フォーカス距離】より奥に設定したあと、マルチパスでデプスデータを AEに送ります。そうすると、カメラの深度をデプスマップとして白黒の画像で現わしたものができあがりますので、それを AEに付属のエフェクト、【ブラー（カメラレンズ）】のマップに利用すれば、被写体深度のデータに沿ったリアルにフワッとしたぼけが広がります。

　まだ試していませんが、発光や透過などの情報でもAEに送れそうです。こちらは今後の課題として置いておきます。

　では実際にデプスマップを作ってみましよう。

① は、カメラの映像です。前回登場した学校の校門から玄関を映したアングルにしてあります。この映像をそのまま画像に落とすと。手前から奥までピントが合った、ふつうの画像になります。

　そこで被写界深度を求めるための作業が続きます。

　まず、②は【カメラオブジェクト】の【詳細】タブにある、【デプスマップ後ボケ】にチェックを入れて、終了位置を『1500』センチにしています。
　この『1500』という数値は、③を見てください。
　全体の景色を真上から見たビューです。左下の真っ黒の長方形は体育館の屋根ですね。

　少し見えにくいですが、ピンク枠で囲んでいる中に、カメラから末広がりなった三角形の暗いオレンジ色の領域がそれになります。そしてその下、カメラまでの三角形の領域がカメラの視野で、カメラのレンズ位置（下向き三角形の頂点）からの距離が、【カメラオブジェクト】の【オブジェクト】タブにある【フォーカス距離】になります。

　つまり、【デプスマップ後ボケ】の【開始】位置の『0』は、【フォーカス距離】の場所を指しており、そこから終了位置が『1500』センチ先だということになります。
　そしてこの暗いオレンジのエリアのカメラの近いほうから奥へ向かって、1500センチ（15メートル）の範囲までが、ゆっくりとぼけていきます。

　これでカメラの設定が終わりましので、AEへ送る準備をします。

C4d Lの【レンダリング設定】パネルを開き、左のリストの下にある "①" の【マルチパス】ボタンを押し、メニューの中から "デプス" を探します。リストの下のほうにありますので、ある程度スクロールさせないと見つかりません。

　見つけたらそれを押します（②）。

　次に、"③"のマルチパスの項目にチェックを入れます。

これで C4d L側の設定は終わりです。続いて C4d Lのプロジェクトファイルを保存してから、AEを立ち上げます。
　保存を忘れると正しいデータが AEに届きませんので、忘れないようにしてください。

AEが起動したら、【プロジェクト】に先ほどの C4d Lのプロジェクト ".c4d" ファイルをインポートします。

映像が出たら、Cinewareパネルの【Renderer】を『Current』にして、正式な画像が表示されるのを待ちます。

　この待ち時間は、プロジェクトの規模により変化します。大規模なものほどひどく待たされたり、あるいは真っ黒のままで何も出ないときがあります。ワタシの経験ですが、".c4d" ファイルが 100MBを超えると、10～30秒も CPUが唸ったままになります。目安としては、CPUの唸りが治まっても何も出ないときは失敗しているか、作業に行き詰ってだんまりをかましていると思われますので、次の方法で、カツを入れてやります。

① AEの【編集】→【キャッシュの消去】→【すべてのメモリとディスクキャッシュ】を押して、計算データを真っ新にします。

② プロジェクトパネルの『c4dファイル』を右クリック、【フッテージの置き換え】で、同じ『c4dファイル』を、再読み込みをします。

③ それでもだめなら、再生バーを1～2フレーム進めて新しい場所でプレビューしてみます。

ひどいときは AEがフリーズして、完璧にストライキ状態に陥るときがありますので、そんなときはさっさと、Windowsのタスクバーを右クリック→【タスクマネージャ】を起動して、『Adobe After Effects 20XX』（XXはバージョン年代）を右クリック→ 『タスクの終了』を押して強制終了させた方が手っ取り早いです。

　ワタシの場合はフリーズした場合、何時間待っても復旧しないのを見越していますので、さっさと強制停止しています。再起動した AEは下の写真のように【修復オプション】のパネルが出ますが、『続行』を押して、通常起動させます。

　だいたい、ここまですると AEも反省したのか、すんなり動きだしますので、まあ、よしとしていますが、こんなのは日常茶飯事です。もっとも規模の小さい『c4d』ファイルの場合はこんなことにはなりませんので、参考程度にお読みください。

　正常な画面が表示されたら、レイヤーパネルに出た『c4d』レイヤーの複製を作ります。次の写真がその状態です。

複製された、上の『c4d』レイヤーを選択（①）してから、"②" の【Cinema 4D Multi-Pass】にチェックを入れます。
　続いて【Set Multi-pass】のボタンを押して、出たメニューから『デプス』を選択します。

　すると、ふたたび待たされた後で、画面が次の写真のような状態になります。

まるで霧がかかった朝もやのような状態ですが、これがデプスマップと呼ばれる奥行具合（深度）を白黒の画像で現したものです。
　フォーカス距離内は黒色で、そこから離れるほどにグレーのグラデーションになっていて、"後ぼけ" 領域を超えたあたりから白色になっています。

　もしこのような画像が出ない場合は、 C4d Lのカメラオブジェクトの【デプスマップ後ボケ】のチェック忘れや、同じく C4d Lの【レンダリング設定】で【マルチパス】にチェックが入っているか、あるいはまた、AEが拗ねて意地悪している場合がありますので、カツを入れてみてください。

白黒画像が出るけど白一色だとか、ほぼ真っ黒のままの場合は、C4d Lの【デプスマップ後ボケ】の終了位置が小さ過ぎるのが原因かもしれません。小さすぎると変化が極端すぎて効果が無い場合があります。

　上記の画像のように、きれいな深度マップ画像が表示されたら、ほぼ完成と思って大丈夫です。次の画像をご覧ください。

まず、"①" で、レイヤー名を『デプスマップ』に替えてから非表示にします。その後、正式な『c4d』レイヤーを選択して、エフェクトの【ブラー&シャープ】から【ブラー（カメラレンズ）】を選びます。
　ブラーを掛けるのはデプスマップのほうではありませんので注意してください。

　パソコンのスペックによっては、この作業が重すぎて辛いときがあるかもしれません。そのときは、二つの『c4d』レイヤーを、もともと作ろうとしていた静止画か、動画にエンコードしてから、その素材をインポートします。

　あとは『c4d』レイヤーを削除して、エンコードした素材でブラー効果を行っても同じことです。

　続いて次の写真のように【ブラー（カメラレンズ）】の設定をします。

設定内にある【ブラーマップ】→【レイヤー】で "デプスマップ" レイヤーを選べば OKです。

　後は【ブラー（カメラレンズ）】の【ブラーの半径】を適度に調整すれば完了です。

校門のあたりにピントが合っていて、体育館入口の柱からぼけ始めて、玄関まで行くとかなりぼけています。また、校門の茶色い鉄の扉にはピントが合っていますが、鉄格子の隙間から見える奥の部分がリアルにぼけています。

　昔はマスクで遠近を切り分けていましたが、これを知ってからは、あの苦労がばかみたいに思えます。

　これでどんどんピンボケ画像が作れますね……。　ゞ(￣∇￣;) ｵｲｵｲ

カメのボケとオヤジのぼけ……。

　次回は

　　C4d Lから数値を AEに送って、その内容を画面表示させる

を予定しています。
　リアルタイムに変化する数値を画面に表示するという要求は、物理や数学系の映像で頻繁に発生します。AEの画面だけでなく、Cinema4D上の画面、つまり 3D映像の中でリアルタイムな数値の表示を実現するためには、どうしたらよいのか考えてみました。

２０２６年４月６日（月）２０℃（午前８時２分）

　3D作業の負担を少しでも軽くするには（省エネならぬ省データ対策）

進む戻る

今回は Cinema 4D Liteのデータを軽量化することで、少しでも消費電力の削減に……ひいては石油の節約（人類の悲願？）になるかもしれない方法を模索してみました。

　Cinema4D Lite（今回は Lite版と記載します）とは、映像制作に欠かせない After Effects（以降 AE）にバンドルされた Maxon社の Cinema4D（C4d）の廉価版のことです。この C4dは 3D映像に特化したソフトウェアで、その機能限定版が AEに付属しています。

　本格 3Dソフトが追加料金なしで利用できるというありがたい代物ですので、AEを使っていて、まだ本物の 3Dは触ったことのない方は、ぜひインストールしてその素晴らしさを実感してみてください。AEにもとから備わっていた 3D機能が過去のものになること間違いなしです。

　でも機能限定版だろ？
　とはいっても、基本的なところは正規版の C4dと同じですので、Lite版で十分慣れてから正規版に移るという選択肢もいいかもしれません。

　このサイトではこの Lite版と AEを融合させたものを作成して、どこまでのことができるか、いろいろと試した結果を公表しつつ、新規作品に挑戦し続けています。AEから Lite版に手を出そうとしている方の参考になることがあれば、遠慮なく活用してみてください。

　これまでの詳しい記事は【 Cinema4D Liteやってます】をご覧いただくことにして、さっそく今回の本題に入らせてもらいます。

なぜ、3D作業は重いんだ

これはパソコン、とくに CPUや GPUに猛烈な負荷がかかるからです。そして、このことはレンダリング時間に直接影響します。
　PhotoshopやIllustratorなどの2Dソフトでも、高解像度の画像処理で待ち時間が発生することはありますが、3Dソフトはその比では無いです。数十分は当たり前、設定次第では数時間待たされることがあります。

　その原因は圧倒的な計算量の違いだと思います。
　Lite版とはいえ、3Dソフトですので、縦、横、奥行まで広がった立体的な空間を作業平面としています。その情報量は膨大な数になるだけでなく、さらに、その表現力に物理シミュレーションまで付加できますので、データ量も計算負荷も膨らむばかりです。

　ワタシが 3Dを始めるきっかけになったのは、コミカルなキャラクターアニメーションに使用する背景画を作るのが目的でした。ですので、リアルなものは必要としておらず、あえて色数を落としたり、簡略したりしてラフに作っていました。

　ところが、いくつか作っているうちに気づきました。
　どのような角度のキャラ素材が回ってきても、3Dで作った背景なら即座に対応可能。描き直す手間もいらず、キャラの角度に合わせてカメラを回すだけで作業完了です。その効率の高さに驚いたのは説明しなくてもお分かりでしょう。

　こうなるとリアルなものも作りたくなってきて、その欲望は膨れ上がるばかり、光の反射や拡散、あるいは窓ガラスを透して見たその表面に、外の景色が映り込んだ表現や、淡い光と陰影のコントラストなど、触りだしたらいつまでたっても完成を迎えないものになってしまうのですが、これが 3D作品が重くなる理由ではないでしょうか。

　もちろんハイスペックのパソコンを使えばある程度は軽くなりますが、それは最終手段として、他に何か手を打ちたくなります。
　これまでは、鏡面反射や透過処理は極力使わないことと、肝に銘じてきましたが、それ以外にもまだ打つ手がありましたので、参考にしてください。

透明の効果が欲しいときは透過チャンネルを使わず、アルファチャンネルで代用する

透過チャンネルを使うと、ガラスを透かして見たような光の屈折まで表現してくれますので超リアルなものができますが、その代わりかなりパソコンに負荷を掛けます。物理現象の再現までは必要ないけど透明感を出したいのなら、アルファチャンネルを使って、そのテクスチャに『カラー』を使えば実現します。黒色に近い色ほど透明になり、漆黒で完全な透明、白で不透明になります。もちろん『カラー』の代わりに『グラデーション』で黒と白に変化を付けると透明度の変わるものができますので、重たい透過を使わずにある程度は代用になります。

インスタンス化とベイク化を併用させる

初めてインスタンスとか、ベイクと呼ばれる言葉を聞いた方に説明します。
　まずインスタンスですが、これはあるものをマスターとして、その複製を作ることです。

　こう書きますと、コピペのことと思われがちですが、それとは異なったものです。プログラムでの話にも出てくるインスタンスと非常によく似ていますが、ここも少し異なっていて、3Dソフトのインスタンスをプログラム的にいうと "参照（Reference）" に近い考え方です。

　もととなるオブジェクトがあって、その形状データを参照して同じものを表示するというのが 3Dソフトでのインスタンスです。インスタンス化されたオブジェクトは位置、回転、スケールの座標データしか持っておらず、常に、もとのオブジェクトを別の場所に投影（残像みたいに）しているような働きをします。つまり複雑な形をしたオブジェクトであっても、実際は一つしかありませんので、100個の同じ物体があっても、形状データは一つです。これはかなりの軽量化になります。

　ただし、インスタンスを編集することはできません。マスターとなったもとのオブジェクトを変更すると、すべてのインスタンスが変わります。これは欠点でもありますが、大きな利点でもありますね。一つ修正すればすべてが変更できますから。例えばハシゴの横棒などはインスタンス化しておけば、修正はマスターの一本だけで済みます。

　Lite版でもさらに軽量化が望める『レンダーインスタンス』や『マルチインスタンス』の設定ボタンがありますが、『マルチインスタンス』は機能しないようです。そして、『レンダーインスタンス』は機能しているようですが、普通のインスタンスとさほど変化がありません。ただ、レンダーインスタンスのほうがレンダリング時の消費メモリが少なくなるということですので、ワタシは一応お守り程度に『レンダーインスタンス』を使っています。ただ『レンダーインスタンス』にはアニメーションできない場合がありますので、あくまでも固定された形状のものに限定しています。

　どちらにしても、積極的にインスタンスにすることで、かなりの軽量化が期待できます。規模の大きな作品を作るときは必須の処理です。

　次にベイク化です。
　Lite版でいうところのベイク化というのは、デフォーマやジェネレータなどの計算で変形させていたオブジェクトを一つの固定された形状（ポリゴン）として焼き付ける処理を指します。右クリックメニューの中では『現在の状態をオブジェクト化』がこれにあたります。
　常に「どう曲げるか」「どうかたどるか」をフレームごとに再計算させるのではなく、「この形で固定！」と決めてしまうことで、パソコンの仕事量を劇的に減らすことができます。

　当然ですが、元に戻して数値をいじることができないので、ベイク前のバックアップは非表示にして残しておくか、別ファイルに保存して、作業用のプロジェクトファイルから削除して軽くすることを推奨します。
　Lite版の『現在の状態をオブジェクト化』を実行すると、元のオブジェクトを残しつつ、ベイク化されたものができますので、どう処置するかは、ご自分で決めてください。ワタシは二つあるとややこしくなるのと、プロジェクトファイルが巨大化しますので、別に保存してから削除しています。

　では、何でもかんでもベイク化すればいいのかというと、そうでも無くて、インスタンス化したオブジェクトまでベイクすると、一つのの巨大なポリゴンの塊に変換されてしまい、せっかく軽くするために作っていたインスタンスのメリット消えてしまいますので、インスタンス化したものはベイクしないなどの注意が必要です。

　これまでの作品の中で、大量のオブジェクトを使ったものは『海の見える神社』でして、27.5MBでした。通常の作業なら "数百KB" から、多くても "数MB" なのですが、たくさんの樹木と雑草を集めて、大きな森を作りましたので 30MBに迫る容量でした。

神社シリーズは【 My Portfolio】にも並んでいます。参考にどうぞ。

このときもそこそこ重いとは感じていましたが、もし最大限に軽量化したら、Lite版でどこまでできるのか、限界を知りたくなって、今回はさらに詰め込んでみました。

　実験にあたって、新規に作る時間はありませんので、これまでバラバラに分かれていた教材用のアニメーションで使用するプロジェクトファイルに手を加えて、校舎や校庭、校内の設え、さらには周辺の町の様子など、すべてに立体物を詰め込んでみました。外から見ただけでなく、校内もすべてです。全教室に椅子と机と黒板、それから教壇に後部のロッカーから掃除道具入れ、さらには体育館の中には更衣室やロッカールーム、バスケットコートにステージまで、すべてフルセット完備です。

　次の画像がその様子です。

玄関から職員室、各教室には黒板だけでなく、机から椅子までフルセット。体育館の中までセッティング

　もちろん校内には廊下があって、各部屋も完璧。消火栓まであります。

廊下の外には街並みも見えます

時計の右側と、その奥につながる別棟には非常階段やバックネットまで

どこからアニメーションが始まっても、すぐに対応できるフルセットです。

　ですので、どんな注文にも即対応。こんな角度でも数秒で完了。

迫力のあるローアングル

これも一種の箱庭です

この範囲内ならどからでも、またどのようなアングルからでも撮影可能になりました。
　この画像では小さくて見えませんが、交差点近くにあるラーメン屋さんは、室内だけでなく、ガラスケースの中には食品サンプルも並んでいますし、交差点には信号機も設置されています。

　全体をパっと見渡せるように、切れ目なしの動画も作ってみました。まるでジェットコースターの映像みたいになっていますが、そこは笑って済ませてください。

学校の全景を走り抜けてみました（同じラーメン屋さんが二軒もあるのはバグです。悪しからず……）

　プロジェクトファイルのエレメント数は 5618個という膨大な数になっていました。軽量化を考えずに作り上げると、おそらくメモリオーバーとなって途中で破綻したはずです。実際、途中でプロジェクトファイルが 1GB近くなって、画面の移動をするにも固着してしまい、これでは実用的ではない、と断念しかけたのですが、インスタンスとベイクをうまく使い分けることで、317MBまで落ちました。
　プロジェクトファイルというのはプログラムの世界から見ればソースファイルのことで、このファイルからビルドされて実行形式のプログラムが生まれるのと同じで、プロジェクトファイルからレンダリング、そしてエンコードされて動画や静止画ができ上ります。

　ちなみに、『海の見える神社』では、あれだけの樹木が密集した状態で 30MB手前でした。今回のはその 10倍というとんでもないサイズです。しかし 8kサイズ(7680×4320px)の静止画なら 15秒ほどで出力できますので、実用の範囲だと思います。ただし動画にする場合は、1920×1080サイズの 20秒映像で約1時間ほどのレンダリング待ちが発生します。

　レンダリング時間は、パソコンの能力によって大きく変化しますので、こちらのスペックを参考にして比較してみてください。
　使用しているパソコンのスペックは次のとおりです。

・OS：Win11、64bit
・CPU：i9-14900KF（24コア）
・RAM：128GB
・GPU：RTX4070S
・Storage：M.2 NVMe Gen4のSSDで 500GB（作業キャッシュ）

もうすぐ 2年目となる DAIVマシンですが、まだ現役で動いています。

　インスタンスとビルドをうまく使えば、少し引っ掛かるときがありますが、まだゆるゆると動きますので、もう少し余裕がありそうですが、問題はこのプロジェクトファイル（.c4d）を AE上に展開してくれる『Cineware』でして、今回のプロジェクトファイルを読み込んでも、データが巨大すぎるのか、AEとの連携がうまくいかず、頻繁にフリーズしてしまいます。

　最初に ".c4d" ファイルを読み込んだときは機嫌よく仕事をしてくれますが、一度でもプロジェクトファイルの修正をして再読み込みをすると、3回に一度はだだをこねて固まります。一度そうなったらもうおしまい。タスクマネージャーを起動して AEを終了させない限り CPUの使用率 90%で唸ったままになります。

　ということで、廉価版なのに、C4d Liteのほうがまだ余裕がありそうですが、AEの Cinewareが 300MBあたりで、音を上げると結論付けました。

3D作業は Cinewareとの闘い

　機嫌が悪くなるとうんともすんとも言わなくなります。

なだめすかして使ってます……。(￣ω￣!) こどもかっ！

《補足》画像に描かれた『copyright Gemni』とはGeminiの画像生成時のペンネームだそうです。本人（？）がそう主張していました。

２０２６年３月２３日（月）１６.５℃（午前１０時８分）

　これもいわゆる一つの次元的思考

進む戻る

今回は、再びデジタル系の話に戻ります。
　次元的思考とはこれでいいのだろうかという話です。

　あ、宇宙の果てだとか、異世界転生うんぬんの SF電波話ではありません。でも学問を習得してこのサイトにたどり着いた方からすると、

「こいつ、あほちゃうか。意味わかっとらへんな」
　と嘲笑を買うのも理解しています。かといって、この手の話が苦手の方からは、
「このひとあほちゃうか。なにゆうてんのかさっぱりや」
　と、どっちに転んでも "あほ" 扱いの刑に科せられてしまうのですが、ほんの一部の人にだけお伝えします。

　画像制作から見た、4次元的な考えってこういうことかもしれないな、という話です。

　いま、"四次元"と書かずに "4次元"と、半角数字で書きました。あえてそう書いたところが、細かい仕事してますねぇー。とほんの一部の人は思わずニヤリとするでしょう。
　そうです、SFなどの科学小説風に書けば漢字で『四次元』となりますが、プログラム的、あるいは数学的な話になると『4次元』とあえて半角で書くのが、マナーだと思いまして……。おっと、失礼しました。

「また、うだうだ変なことを書き出した」と、文句が出る前にさっさと本題に入りましょう。

泥の噴出

これが真っ平らの平面を、映像的 4次元思考で、ゆったりとたゆむ状態に変化させたものです。色のイメージからいくと、粘り気のある泥がゆっくりと湧き出ているようにも見えますので、『泥の噴出』とタイトルをつけました。

　映像的 4次元思考だなんて難しそうに書いていますが、これは数学的な数式から作られた映像です。Cinema 4D Liteに備わったデフォーマを使えば簡単にできます。

　最初に気づいたのは、 2024年 3月31日の記事です。ほぼ 2年前ですね。
　デザイン会社の社長さんからの相談で、キレイな波形アートが作れないかというものから始まっています。

　Adobeの Illustratorや Photoshop、はたまた After Effectsでいろいろ試行錯誤しましたが、印刷レベルに持っていくことはできず、半ばあきらめかけていたときに、After Effectsにバンドルされている Cinema 4D Liteを使えばそれが可能だと気づき、それからどっぷりはまったのがきっかけです。

　これが当時提出した静止画です。

初期のころのウェーブアート（静止画）

　それから 1年後の2025年 3月4日には動画に成功しています。

スプラインパスによるウェーブアート

上の映像は、直線に対して数式を適用して、それを立体的に並べたものです。

　先にお見せした『泥の噴出』は、同じように周期的に変化する波の計算式を平面に対して適用した映像ですので、繰り返して再生してもつなぎ目がない（シームレスな）ループ映像になっており、いつまでも見ていられます。

　それが映像的な4次元的思考とどう結びつくのかといいますと、まずは次元の話から入ります。

0次元
　位置情報（座標）のみが存在する状態。
　映像ソフトやプログラムによく出てくる "ヌル（null）" がそれにあたります。ヌルとは何も無いのに存在する、一般的には意味不明なものですが、確かにそれが重要なんですね。

1次元
　一本道の数直線で、自由に動けるのは前後だけ。
　中学になって、"算数" から "数学" と変わった途端、数字に負の数が出てきて面喰らうやつですね。「何で、負の数×負の数が正の数になるねん！」てね。
　1次元で物体を表現すると、円形も四角形も三角形も、それから星型だって、すべて線分（点と点のつながり）になります。ですので、見ただけでは判別がつきません。と、考えられるのは、高次元から見ているからで、1次元の世界では形というものは存在しません。

2次元
　縦（Y軸）と横（X軸）の広がりだけで、厚みのない「ピクセル」や数式の世界。面の誕生ですね。
　いわゆるPhotoshopや Illustratorの世界ですね。After Effectsもその仲間に半分足を突っ込んでますが、半分は外に出ています。真夏の布団が暑くて片足を出して寝ているような状態です。片足は 2次元、もう一方が 3次元に突っ込んでいます。

3次元
　縦（Y軸）と横（X軸）の世界に奥行きが加わり、実体が生まれます。
　2次元を超えると "縦と横" の定義が曖昧になりだし、見る方向が変わると "横と奥行" でもいいし、 "奥行と縦" でもよくなって、何がどうなっているのか分からなくなり出します。しかし、ここで第3の軸である『Z軸』が加わることで、その混乱は一変します。この軸のおかげで "縦と横" の存在がはっきりと見えてきます。そしてこの三つの軸は互いに "90°" で交わり、そこに立体が登場します。

4次元
　さあ、問題の 4次元です。
　3次元までの考えを延長してやれば、何かもう一つの情報を足してやれば、それは 4次元になるのが、数学的な次元の定義です。そこで登場するのは、ごく一般的に昔から言い伝えのように語られてきた、"時間" という軸です。

　3次元の空間に『時間（t）』という変数を代入し、静止している立体を『時間の流れる現象』へ導けば、4次元的映像だという考えから、先ほどのゆったりと "泥のようなもの" が噴出する映像をお見せしました。

　この映像は、キーフレームを打って座標 (x, y, z) を手動で動かしているのではなく、時間 (t) という変数が形状そのものを支配しています。
　ある瞬間の形は、その時の t の値によって数学的に決定される 4次元的な断面の連続です。静止画としてなら座標を調整すれば再現できますが、物理法則に従って連続的に変化し続けるこの映像は、2次元的なレタッチ（画像編集）では作り出せないと考えています。これは、まさしく (x,y,z,t) という座標が拵（こしら）えた物理現象です。

　もっと簡単にいうのなら、絵の一部として時間を組み込むことができたので、変化し続けるデジタルな物体が誕生した、ということですね。

　どんどんいきましょう。

　次は単なる平面が波打っているのではなく、透明の水玉模様が描かれたシートが、ゆったりと波打っている映像です。

緩やかな波

大海原に浮かべたシートのようにも見えますが、この映像内にもキーフレームは一切打っていません。数学的な数式で動ているだけです。

　次はその数式内に、減衰や、時間制御、そしてプログラム的な条件分岐までも入れて作った映像です。

ここにもキーフレームは一切打たれていませんが、映像がスタートして少し時間が経過してから、大きく波打った後、静かに収まっていきます。
　波が収まるまで時間が掛かりますが、シームレスに繋がっていますので、一生見ていられます。

　ちなみに、数式の中に条件分岐を入れる方法ですが、例えば、時間(t)が 2秒までは波が発生しないようにするには、数式の最後に　 * (ｔ>2) 　と追加するだけです。
　こうすると、t が "2" 秒を超えるまでは "false" となって、常に "0" ですので、その間、"0" を掛け続けることになり、計算結果は常に "0" となり止まっています。
　時間が経過して t が "2" 秒を超えると "true" で、"1" となって数式が適用されて動き出します。Cinema 4D Liteならではの苦し紛れの作戦でした。

プロパティか、次元なのか？　そこが知りたい……

　今の映像に、球体のオブジェクトを飛び散る雫（しずく）としてキーフレームを打って追加しますと、こんな映像になります。

最終更新日 4月9日

　今回は、時間の制御を加えて、4次元だと言い張っていますが、時間ではなく、透明度を変化させるような映像でも、（x,y,z）座標に透明度（＝Alpha）を加えて、（x,y,z,α）となって、4次元映像だといってもいいのではないでしょうか。
　そこに物体があるのに、ある時間までは目には見えない。そしてなんらかのイベントをトリガーとして姿を現す。現実の三次元世界ではトリックを使わない限り、屈折もせずに光を直進させる透明な物体など、まずあり得ないことですから。

　それともそれはプロパティの追加だと、いわれるだけのものなのでしょうか。

　4次元的思考で作った波形の作り方は【CINEMA 4D Liteやってます】の実践編で掲載予定です。
　詳しい情報はそちらをご覧ください

　さて、次は 5次元的映像を考えてみますか……。
　いま、一つの大胆な仮説がワタシにはあります。

　第5の次元になる物は "熱" ではないかという考えです。
　熱ってなに？　と聞かれて、一言でその正体を表現するのは学者でも難しいといわれるくらい、捉えどころのない不可思議なエネルギーだそうです。

　この熱を表現できるディスプレイやそれを映像として計算できるコンピュータがあれば、『熱エネルギーの対流』をシミュレーションの変数 h（ "heat" ）に組み込んで、（x,y,z,t,h）から、その結果を視覚化した物体。それは熱と時間で変化するオブジェクト……。まさに 5次元的映像となるかもしれません。

これが、第五のせかいぢゃ！

　熱々のラーメンが食べたくなってきた……。(￣‥￣) ｱﾎﾔ…

２０２６年３月１５日（日）１６℃（午前１０時４０分）

　クソゲーメーカーが贈る【リブート・オブ・ワンダーランド！】

進む戻る

ことの発端は 2019年 1月です。

『Number Crash』というレトロゲーセンゲームの開発者を探していた、横浜のレトロゲーム発掘隊のみなさんがこのサイト（デジタル降魔録）にたどり着き、ワタシがそのゲームの開発者であることの確認や、その当時の資料を見せてほしいとのことで、交流が始まったという話が、このサイトでも公開しています『クソゲー後日談』という記事に書かれています。

　それから 7年後の 3月。

　レトロゲームの話題も薄れ、相も変わらずデジタル的な意味不明の話ばかりを掲載しているワタシの下に、一通のメールが。

　件名には『ワンダーランドについて』と書かれていました。

『ワンダーランド』という言葉から想起できるのは、『クソゲー後日談』でも話題になっていたゲームの名前です。
　もちろんワタシの作ったゲームですが、どういうワケか資料が一切残っておらず、かつ正常に起動する基板も勤めていた会社の倉庫に残したまま会社が消滅。それに関する情報が断たれてしまい、完全な幻となっていたゲーム名とと同じ件名だということで、疑問と、もしやという期待とで心臓の鼓動と血圧が高まるのを覚えました。

　差出人は、北海道の Uさん。
　なんと北海道から遠路はるばるありがとうございます。って、メールですから、数秒で届きますね。
　さて、その内容を読んで、ワタシの鼓動はさらに上昇しました。

　Uさんは、中学生のとき東大阪近郊の放出（はなてん）という町に住んでおられたそうで、近所の駄菓子屋さんで『ワンダーランド』にはまり遊んでいたのですが、クリアしないまま北海道に引っ越されたという内容から始まり。

　ワンダーランドのことはずっと覚えていてくださり、2006年に "レトロゲームの名前質問スレ41" で尋ねたところ、阪神娯楽の名前が出て、そこから順にたどり『Peni Original Soft』の『ワンダーランド』が自分が憶えているゲームだということが判明したということです。

　ただ、動く筐体が現存するのか、あるいは移植（たぶんMAMEだと思います）されているかの詳細は分からずのまま 2023年に X（旧Twitter）で現存している画像を偶然見つけたのですが、残念ながら詳細は不明のままだったそうです。それでもめげずにネットで調べていくうちに、ようやくこのデジタル降魔録までたどり着いた、ということでした。

　いやいや。これこそ本当に遠い道のりをお疲れさまでした。
　しかもですよ。Uさんはワンダーランドが起動している YouTubeチャンネルまで見つけてくれているのです。
　これはとんでもないことです。謎だった邪馬台国の所在地が発見されたようなものです。あ、すこし、いやだいぶ大袈裟ですね。失礼しました。

　でもワタシにとってはとんでもない出来事です。長い間、謎だと囁かれていた『Peni Original Soft』の存在と、いまのワタシが存在するためのターニングポイントとなった宣言しても過言ではないゲーム機が、1984年から42年という年月を経て今ここで公開されるということです。（いちいち、くどいな）

　これが『ワンダーランド』です。

オニオンソフト様が貴重な実機映像を公開されており、ご厚意で情報を共有させていただきました。当時の空気感が伝わる素晴らしい映像です。
URL： https://www.youtube.com/watch?v=pDShnCkB3I8
（映像はダイジェスト版のようで、ワンダーランドは "1:45" までです）

『Peni Original Soft』がなぜ謎に包まれているかの理由

動画内で誰かがささやいている『ODIS』という謎のアルファベット。実はこれ、当時ロケテストに協力してくれたワタシの恩人ともいえる会社の略称なんです。会社はもう消滅してしまいましたが、大阪ダイソーさんという、ワタシの開発者としてのスキルを最初に評価してくれた、忘れがたい会社でした。

　当時のワタシにはオリジナルのハードウェアを作るスキルはありましたが、金銭的な余裕はありませんので、既存のゲーセン基板をベースにしてソフトとハードの勉強をしていました。ですのでソフトがオリジナルであっても、他社開発の基板で走るゲームを販売することは著作権の問題が起きますので、大阪ダイソーさんもそこは了承しており、開発用と、ワタシのエリアでの反応を見るロケテスト機、そしてダイソーさんで、3台（あるいは5台だったか）まで作成した何種類かのゲームのうちの一つが、このワンダーランドです。もちろん現在はすべて消滅しています。

　前回のクソゲー後日談の末尾に記載の作品履歴の中で、1986年 9月以前までがその類のゲームで、どれも数が少なく日の目を見ておりません。これが、『Peni Original Soft』が幻となった原因だと思われます。

ワタシにとってのターニングポイントとは

1984年ごろになると、ゲーセンのゲームはインベーダーやパックマンのブームはとうに過ぎ去っており、しかもワンダーランドはドットイート型のゲームですので、すでに主流からずれていました。そして決定的なのは、雰囲気がコナミのロックンロープに酷似している（偶然ですよ……たぶん）ので、このまま製品化するのを断念、当時まだあまり出回っていなかった、子供向けの景品払い出しへと方針が変化していきます。

　このときに、ワタシにもオリジナルのハード（基板）を作るスポンサーが現れます。先ほどの大阪ダイソーさんともう一社、吉田商会さんというゲーム会社さんの協力のもと、ゲームマシン大阪（GMO）が設立されました。
　現在はすべてありませんが、この二社の資金提供により、初のオリジナル基板が誕生する、まさにその変化点となったゲームが『ワンダーランド』だったということです。

制作：ヌイクマ出没注意

その後もアクションゲームを数種類作っています。しかし方向性はメダルゲーム機に向いており、すべて途中で終了しました。これが原因となって、ここから先の資料が一切残らなかったと推測されます。

　そしてゲーム業界は大型機の時代を迎えます。一人でゲームの企画、BGMと効果音の制作、さらには高度に進化するハードウェアの設計までを全てこなすのは、もう限界だと判断しました。その中で、より自身のスキルが活かせるメダルゲームへと移っていくのは、ワタシにとっては自然な流れだったのかもしれません。

　余談ですが、この過程で習得したPCB CADによるプリント基板のアートワークから発注までの各種スキルは、今となっては非常に大きな "儲けもの" でしたね。

　そのメダルゲームですが、関西では『ジャリメタ（じゃりン子が遊ぶメダル機の意味かも）』と呼ばれるものです。今は無き宝塚ファミリーランドにワタシの作ったゲームが数台並んでいるのを見つけて、お金を握りしめて遊んでいる子供たちを、離れた場所から眺めていた光景は今でも記憶しています。

　というのが『Peni Original Soft』の真相です。このあともまだまだ続いていくのですが、もう幻となるようなものは無いと思います。なにしろその後のことはこのデジタル降魔録がそのまま引き継いでいます。すでに丸裸になっているのでした。

「ブッ、ファックション！」
　おお寒ぅ……。

　次は、今回のスクープ（おおげさ）ともいえる貴重な情報を送っていただいた、Uさんが運営されているYouTubeチャンネル『ヌイクマ出没注意』を紹介します。
　Flashで作った映像だそうですが、なんだかおもしろそうです。ぜひご覧ください。

ヌイクマ出没注意さん
　URL: https://www.youtube.com/watch?v=z9J12woBK5U

　ほかにも Uさんは、下記のSNSで活躍中だそうです。
X（旧Twitter）:@nuikuma4649
TikTok　:@nuikuma

　さいごに。
　Uさんがこの『ワンダーランド』の微かな記憶をたどってくれなかったら、ワタシの過去はこのまま幻と囁かれて消えていったことでしょう。Uさん、本当にありがとうございました。

当時のワタシ（想像図）

　そしてこれが現在のワタシ。

現在のワタシ（画像はイメージです。実物とは激しく異なります）

「あほかー！　どの口が言うとんねん！」

「失礼しました……ではこれで……」

ほぼ原寸大……

　まあまあのできやね。（TωT）ﾌﾞﾋｰｯ

２０２６年３月１１日（水）１４℃（午前７時５６分）

　春の足音はすぐそこに

進む戻る

だいぶ暖かくなりました。やっと春到来です。といっても昔と比べるとずいぶん早くなっているような気がしますが、とりあえず、外の様子はいかがなものかと歩いてきました。

　補足しますと、今でこそインドア派の代表みたいな顔をしていますが、昔はソロキャンパーとして活動していました。まだ、キャンパーなどという言葉の無いころからですので、散歩といっても、ただ、あてもなく歩くのは性に合いません。食べられる植物を求めてうろつくのはソロキャンパーの習性です。
　そのころの話は2011年8月19日の記事に書いています。

　まず最初に目に入ったのは、春を告げる小さな花『オオイヌノフグリ』です。

オオイヌノフグリ（毒性：グレイ　食べられるらしい）

オオイヌノフグリの拡大写真

この小さな青い花を見るたびに、暖かな春の日差しを思い出します。なのに、気の毒な名前をつけられて……。

　ご存じない方に。イヌノフグリとはオス犬のタ●タマです。なんでそんな名前がついたのかは、ネットで調べてみてください。思わず『なるほど』と手を打つことでしょう。
　写真は、外来種の『オオイヌノフグリ』です。
　毒性はないといわれていますが、あまり食べる気にならない小さな植物です。
　変な名前をつけられて、さらに好んで食べられた日には浮かばれないですね。

　ところで、オオイヌノフグリではなく、在来種の正式な『イヌノフグリ』は青味の薄い、少し赤味が掛かった本当に小さな花らしいです。らしいというのは、ほとんどの府県で絶滅危惧種に指定されていて、見つけることは難しいといわれています。実際、ワタシもいまだに見かけたことがありません。子供のときから、この青い小さな花でした。
　ちなみに在来種のイヌノフグリが咲かせる花の大きさは、五円玉の穴にすっぽり収まるのが目安だそうです。上の写真のオオイヌノフグリが直径 1センチほどありますので、それよりだいぶ小さいですね。

　こちらは直径 3ミリほどの小さな花を咲かせた『キュウリグサ』です。

キュウリグサ

写真のキュウリグサは青い花びらが 5枚あって、中心に黄色い輪のようになっているのが特徴です。花の大きさから在来種のイヌノフグリと勘違いしそうですが、イヌノフグリは花びらが薄紫色で数が 4枚と、異なっていますので違う種類です。さすが絶滅危惧種のイヌノフグリはそう簡単に姿を見せてくれません。

　こんどこそ在来種のイヌノフグリだと期待してカメラを向けたのが、こちら。

タチイヌノフグリ

大きさは五円玉の穴にすっぽり入るくらい小さな花で、本物のイヌノフグリと同じぐらいですが、葉っぱのすぐ横から青色の花で中心が白。葉や茎に白い毛がびっしりと生えている様子から、これはタチイヌノフグリだと思われます。
　イヌノフグリにもいろいろな種類があるようで、これも外来種でした。

　そこから、もう少し野原を進んで見つけたのは『ホトケノザ』。

ホトケノザの拡大写真（毒性：グレイ　食べられない）

シソ科のホトケノザの花が咲いたところです。注意が必要なのは、あの春の七草の『ホトケノザ』とは違います。ややこしいですね。

　食用になるホトケノザは『コオニタビラコ』という黄色い花が咲く草ですが、野原で採った野生の『コオニタビラコ』もあまりおいしくないという話です。

　ホトケノザの周辺に群生していたのはこちら。

セイヨウカラシナの冬越しの状態（毒性：ホワイト　若葉のうちなら食べられる）

セイヨウカラシナの花の拡大写真

一見してナノハナのようですが、葉の付き方がどうもセイヨウカラシナのようです。

　これが葉の部分の拡大写真です。

セイヨウカラシナの葉の拡大写真

茎から出る葉っぱが枝分かれしたように出ています。ナノハナは茎を囲むようにして葉が出ていますので、見分けられます。
　セイヨウカラシナは、ピリリと辛くて苦みがあり、ナノハナよりくせがあります。若葉のうちに塩もみをしてから湯がいてアクを取ると、鼻にツーンとくる辛子特有の刺激がします。好きな人にはたまらないかもしれません。どちらかというと、山菜通に好まれる感じです。

　写真では見られませんが、すでに誰かが採って帰ったらしく、若葉の部分が摘み取られたのが何本もありました。知っている人は知っているんですね。

　次の写真は確実に食用になる春の草です。ワタシは時々採ってきて湯がいていただいています。
　それが『野蒜（のびる）』と呼ばれるものです。

群生する野蒜（毒性：ホワイト　湯がいて食べる。香りや味は、ほとんどネギかニラ）

野蒜の拡大写真

ところが、これとよく似た植物にスイセンがあります。あの白い花が咲く植物ですが、この野蒜の群生地の近くにも生えていました。これがその写真。

スイセン（毒性：レッド　猛毒。絶対食べてはいけない）

こっちは有毒です。リコリンと呼ばれる毒性アルカロイドが含まれていて、誤食すると激しい嘔吐や下痢を引き起こすということです。

　最近は野生化したクロッカスも春先に白い花を咲かせているのをちょくちょく見ます。こっちもぱっと見は野蒜とよく似た葉っぱと、鱗茎を持っていますので、つい手を出しかけますが、クロッカスもリコリン毒がありますので要注意です。
　こんなのが食用の野蒜のすぐそばで群生していますので、まるで自然界のトラップのようです。

　とにかく、野蒜とスイセンやクロッカスの違いは、その独特な匂いです。
　野蒜はしゃがんで近づくだけで、ネギのような、ニラのような香りがあたりを漂っていますので、すぐにわかります。かわりにスイセンやクロッカスは無臭ですし、葉っぱが平たくて多肉質で厚みがあり、表面に光沢があります。野蒜の葉も他の草と比べると少し厚みがあって、断面が V字型で細長いですが、スイセンより、また他の似た草よりも葉の色が鮮やかな若竹色をしていて、遠目で見ても明らかに目立っています。

　この三種は根っこに小さな玉ねぎのような白い鱗茎と呼ばれる球がついていて、ますますややこしいのですが、野蒜だけはネギやニンニクに似た匂いが漂いますので、はっきりと見分けがつきます。匂わないものは絶対に口に入れてはいけません。とくにスイセンの鱗茎は毒が強いので注意してください。

　歩けば歩くほど食べられる植物がたくさん見つかりました。あ、もちろんスイセンのように注意の必要なものをありますが、次の写真は誰もが知っているでしょう。『ヨモギ』です。

ヨモギ（毒性：ホワイト　食べられる。よもぎ餅が有名）

ヨモギかどうかの見分けは、まず、葉の裏が白くて、薄く毛のようなもので覆われているかどうかです。そして羽のように深く切れ込んでいて、柔らかいのが特徴です。その葉をもむと清々しい強い香りがします。

　よく似たのに『ニガヨモギ』というのがあります。見た目はほとんど違わないのですが、湿気の多い場所に群生するというところで見分けます。食べたことはありませんが、大量に食べると嘔吐や神経麻痺の症状が出るそうです。

　写真の草は直射日光が当たる土手に自生していましたので、ヨモギと判断しました。

　ヨモギとよく似た植物で、とくに気を付けないといけないのは『トリカブト』です。葉っぱの形がヨモギとよく似ていますが、猛毒です。見分け方はヨモギほど葉の切れ目が深く広く切れていませんし、葉に艶があり、その裏が白くないというのが特徴ですが、『トリカブト』の毒は触るだけでもヤバイといわれていますので、気を付けてください。こちらも『ニガヨモギ』と同じで湿気の多いところに生えていますので、日当たりのいいところかどうかで判断できそうですが、注意するに越したことはありません。

　次はこの二つ。
　説明の必要もいらないほど誰もが知っている山菜です。

つくし（毒性：ホワイト　ほろ苦いです）

つくしは茎についているハカマと呼ばれるヒラヒラを取ってあく抜きします。ハカマは硬くて食べられません。

ナズナ（毒性：ホワイト　さっとあく抜きして葉や、花穂を食べます）

別名ぺんぺん草とも呼ばれるナズナは、春の七草のひとつですが、写真のように花が延びてしまうと固くておいしくありません。強いあくはないので、沸騰したお湯に塩を少々入れ、さっと茹でて水にさらす程度で十分です。

　さて――。
　さらに歩いていくと、そろそろ芽を出してきました。ワタシはこのあたりの天敵草と呼んでいますが、『ナヨクサフジ』です。

ナヨクサフジ（毒性：葉・茎はレッド　マメは食べられるがマズイ）

ナヨクサフジの花の拡大写真

ナヨクサフジはマメ科の植物ですので、芽が出たばかりのころは、カラスノエンドウ（食用可能）とよく似ていますが、別種の植物です。そしてナヨクサフジは肥料にもなるし、蜜源にもなるので場所によっては好まれているようですが、ワタシは別の考え方をしています。

　じつはこのナヨクサフジは、ここ 10年ほどで、ここらの河原で急激にハバを利かせてきた外来種です。その繁殖力は半端ないパワーを持っていて、この野原で生育していたカラスノエンドウやタンポポ（食用可能）などの上から、巻きひげで絡みついて這い上がります。ほとんど覆いかぶさるという感じになると、自らの重さで、他の植物を押しつぶすかのように広がっていきます。そして結果的に、下敷きになった植物を枯らしたり弱らしたりしてしまいます。

　ですので、昔ほどたくさんの種類の草花が見られなくなって、景色が塗り替えられてきているのは、おそらくこの外来種のせいではないかと思っていますが、土地が肥えるという意味から、農家さんには好まれているようです。

　先にも書きましたが、ナヨクサフジはマメ科の植物なので、マメは食べられるそうですが、あまり美味しくないということでした。それよりも葉や茎は毒があるということですので、食べることはお勧めできません。

　どこの世界にでもやかいな問題はあるんですね。

　ほかにも毒性ホワイトの『スイバ』もあるのですが、まだ時期が早すぎました。
　昔はワラビやタラの芽、フキノトウ、セリなど、いくらでも食用の植物はありました。しかし都会に近いこの辺りでは一度もお目にかかったことがありません。自称、元祖ソロキャンパーとしては寂しい限りです。

《補足》
　都会近くの道端のものは排気ガスや除草剤の心配がありますので、くれぐれもご用心ください。

一人で野原をウロウロするオッサンこそ胡散臭いのでした。（TωT）ﾌﾞﾋｰｯ

２０２６年３月９日（月）１６℃（午後２時５６分）

　消失した秋の思い出

進む戻る

しばらくデジタルものが続きましたので、ここらで小休止。ネタがなくなると引っ張り出してくる、あ、じゃない。趣味でやっているウォーキングでの話です。

　仕事柄、椅子に座ったままでほぼ一日過ごしますので、こんなに体に悪いことはありません。ですので、少しでも暇ができると外に出るようにしています。なかでも 3Dのレンダリング中は、かなりの時間、パソコンが使用できませんので、格好の散歩時間となっています。

　ということで、寒さの緩んだ春間近の河原を歩いてきました。
　風はまだ冷たいのですが、陽射しが緩んできていることは確実に感じられます。そんな私の前に、目を疑う光景が飛び込んできたのでした。

　一変した光景にワタシはマジで立ち尽くしました。
　たくさんあった大きな樹木がすべて伐採されて、丸裸の更地が広がる光景。

　河川敷に自然と生えてしまった樹木は川の流れを阻害することがあって、大雨や洪水の被害が拡大するため、時々重機が入ってごっそり掃除しているのはよく見かけていましたが、ここまで大規模なものを見るのは初めてでした。

　これがまだ樹木のあったころの写真です。

去年 11月ごろです

　夏の日差しの強いときに木陰となって休憩していた場所も何もかも "ずんべらぼん" です。ちなみに "ずんべらぼん" とは関西起源が有力な言葉で、 "すっぱだか" あるいは、"つるつる" という感じのニュアンスですね。

　しかも。
　しかも、ですよ。ここを強調させてください。

　半年ほど前に収穫していた野生のクルミの木 3本ともに "ずんべらぼん" です。跡形もありませんでした。
　それはもう、みごとです。切り倒されてなんて生易しいものではありません。根こそぎです。すっぽんぽんの "ずんべらぼん" でした。

　それにしても最近の重機のパワーはすごいですね。太い木を根っこごと引き抜いて細かい丸太にしてしまうみたいです。

ちょっと待ってください。じゃあ、去年豊作だったクルミの実は、あれが最後ということ？
　クルミ収穫の話は2025年10月23日をご覧ください。

　今年からもう食べられないということですね。

　これはショックです。

　これから毎年ちょくちょく自然の味を頂こうと思っていたのに、あれが最後になったとは。

これが収穫直後の姿です。地面の上に転がしておくと次の写真のようになります　

食べるときはガスレンジで焼くとプチっとクチが開きます

　でも、家にはクルミの実が、まだ 10個ほど残っています。その 10個の実が、あの木の忘れ形見になったということです。

　よかった。残しておいて……。
　これは、ワタシにあの木の願いが託されたのかもしれません。だから去年豊作になったのかも……と思うと、もう切なさ満杯。

　さっそく大きな植木鉢にクルミの実を植えました。ぜひ芽が出ることを祈っています。
　そして、また巨木になって、ワタシにあの香ばしい味を堪能させてください。

　ところで、何年待てば実が生るのでしょうか？　(￣ω￣!)　ｱﾎﾔ……。

　次回は『春の足音はすぐそこに』です。
　クルミは食べられなくなっても、野原には食べられる植物がいっぱい……の話です。

２０２６年３月３日（火）１６.５℃（午前７時１２分）

　怖いぞ AI依存症（その２/２）

進む戻る

AIを利用するととても効率的に事が進みます。ですが、注意することも多いです。とくにプログラムを勉強中の人が注意を怠ると、ヤバいことになります。
　そこで、今回はワタシの実体験から見た AIの注意するべき点を書いてみました。

　AIは何でもこなします。絵や音楽、小説、なんでもです。プログラムに関する問題でさえも平気で解きます。プログラム言語は問いません。初めてGeminiと接したときに、ワタシも面白半分に C#や Javaより特殊な PICのアセンブリ言語の質問を出したことがありました。
　PICというのはワンチップ CPUの一つです。Microchipという会社の製品で、組み込みシステムで使われることが多い CPUです。
　今度は組み込みシステムの意味が分からないですよね。すみませんね。ややこしいホームページで……。

　組込みシステムというのは、キーボードを叩いたら文字が出るパソコンとは違って、ロボットとか自動販売機、あるいはゲーセンのゲーム機もそうですね。家で遊んでるゲーム機にはコインの投入管理なんてありませんでしょ。ゲーセンのゲーム機はゲームを動かしながら、お金の種類や投入数だけでなく、イタズラの監視もやっています。

　こんな感じで、機械の『脳みそ』として中に隠れているコンピューターを指します。それ専用の CPUをプログラムしますので、ハードウェアと密接に関係する極めて特殊な世界です。

　そんな特殊な言語をどう解釈して出力してくるのか。まあ、お手並み拝見……と出した問題なのに、Geminiはいとも簡単に解いてしまい、しかもご丁寧にも、変数の初期化部分からアセンブラの疑似命令、なんと "org" も定義してあるし、サブルーチンの使い方も正しいだけでなく、その役目を日本語でコメントアウトしてありました。もう、そのまま "MPASM" に通してもビルドできそうなほどの精度に、ワタシは尻子玉を抜き取られたのを憶えています。

　もちろん、完璧ではありませんでした。変数の定義漏れがひとつあったので、それを指摘すると、Geminiは即座に非を認めて修正案を提示してきたのです。その時、ワタシは直感しました。これは単なる検索エンジンではなくて、姿こそ見えないが、同じエンジニアの言語を解する "対話相手" になるかもと。

　その後、C#のお供に（晩酌のアテか！）使っていたのですが、ちょっとした落とし穴があると気づきました。
　こう察知したのは、ワタシがプログラムの経験があって、そのクセや挙動を熟知していたからで、AIの答えは完璧に近い回答を出してくれますが、使う側にその準備ができていないと、あとでひどい目に遭うかもしれないという危険を含んでいます。

　AIはどんな動きのプログラムであっても、いとも簡単に、しかも具体的に回答します。なので返ってきた回答をそのまま IDE（総合開発環境）に放り込んで実行しても、それなりにちゃんと動きます。たまにエラーが出ることもありますが、それは嘘を教えられたのではなく、プログラムの記序の方法や、記序する場所が間違っている、あるいは変数の宣言を省略しているのが大半です。

　まあ、初心者のうちからエラーを出さない人はもう人ではないかもですから、こんなのは日常茶飯事なのですが、解答を得るまで楽で速いですから、理屈も分からず、かつ調べもせずに、次々と AIへ質問。で、そのとおりにやると、またまた正常に動作して意図した動きが完成。頭の中ではドーパミンが『どばっ！』。

　また次の問題で質問。たまにはエラー。でも懲りずに再度質問。回答。実行すると正常動作。ドーパミン『どばーっ！』。
　要求すれば勝手にソースコードが作成されて、それを右から左にコピペすれば、意図したものが完成していきます。こんな楽なものは無いですよね。だからアルゴリズムを考えるよりも先に AIを使用するので、いつの間にかドーパミン漬けの脳が完成。

　エラーに当たっても、考えるよりも楽なので AIを頼る。気が付くとソースコードの中は理解できていない構文が整理されずに、溢れかえっています。そしていざ、それらを一つのツールとして組み上げてみると、なぜか一部が正常に動かない。でも何も理解せずに作っているから、どこにバグが潜んでいるのか、完全なブラックボックスになり果てたプログラムでは手の出しようもない黒い塊となって、ハードディスクの片隅に積み上げられていくのです。

　結局、人間が初めからすべてを理解して、整理して組み上げたモノのほうが、後の仕様変更にも強くかつ簡単に済むことに気づかされます。

　とはいっても、AIに翻弄されずにツールとして利用すると、とんでもなく効率が上がるのは事実です。暗算や筆算で計算していたものが、電卓に変わったようなものです。慣れたら便利なのですが、先ほどのプログラムに利用したときのように、気を付けないとブラックボックス化してしまい、その構造を一から紐解くのに作成したとき以上の時間を強いられることになります。

　いっそ、作成からメンテナンスまで、すべて AIにやらせたら、という考えも出てきますが、これこそが、最も恐れられているシンギュラリティの幕開けです。誰も理解できない悪魔の誕生です。これだけは阻止するべきですね。

　しかし、これからはもっと AIが浸透してきます。AIを否定する（デジタルデトックスも含めて）だけでなく、どう共生するかなどの対策として、AIを擬人化せずにツールだと思えばいいのですが、ここまで、人間側に詰め寄って来られては、対処のしようがありません。そこで、ワタシは AIをより安全に使用するときに、次の点を注意するようにしています。

　鵜呑みにしてはいけない

これはハルシネーション "もっともらしい間違い" への警戒です。
　ワタシは別の手段を使って同じものを調べて、得た情報と照らし合わせています。
　特にスキルを要求されるプログラム系で、なんども逆の回答を出してくるときがあります。setterとgetterなどの簡単なアクセサメソッドを、Geminiは逆に説明していました。その度、それを指摘しましたが、受け入れてもらえず、四度目にしてやっと非を認めたという、かなり頑固な側面を持っています。

　他にも使用しているアプリの使い方を訊いても、AIが学習したアプリの情報が古くて違う返答をするときが意外と多いです。
　Unityや Cinema 4Dのインターフェースはいろいろなバージョンが出回っていますので、自分の使っているものと AIが学習したものが一致していないと、何の役にも立たないときがあります。しかし、そこは正しく指摘すると非を認めて、新しい情報に切り替わることもありますので、スクショなどを撮って、「ほら、こっちはいまこうなんてんだよ」と見せてやると、ちゃんとスクショを認識して応えますので試してみる価値はあります。

説明されたことを自分の頭で理解する

自分のものとして理解しないと、あとで応用が利かなくなり、他人から説明を求められても答えられなくなります。

著作権とオリジナルの問題

出力されたものは商業利用できない場合もあります（Adobeの生成AIは商業使用可能となっていますが、いまだにグレーです）。それだけではなく、既存のデータから学習していますので、どこかで見たことのあるようなモノになることがあります。AIはあくまで "下書き担当" や、よくいわれています "壁打ち相手" として使って、最終的には "自分らしさを加味して" 独自性と権利を守るようにするべきだと思います。

機密情報・未発表作の問題

創作中の内容や機密情報をそのままプロンプトに書き込んでスレッドに流すと、AIが学習してしまい、重要なアイデアや情報が世間に漏れることがあるそうです。具体的な内容を避けて、抽象化したり、固有名詞を伏せたりして質問するように心がけるようにします。

　結論です。
　AI依存症にならないようにするには、まず自分の脳で考えるクセを付けることですね。断片的でもいいです、整理されていなくてもいいです。暗記する必要もありません。それらは AIを時間短縮のツールとして任せれば整理整頓された回答をくれますので、そこから自分の考えに沿ったものを選んで、自分で組み立てればいいと思います。ようは自分の脳の一部として使う感じですね。外付け脳細胞ですよ。

　分からなくなったときは直接の回答を求めずに、なぜそうなるかを訊く。人間と違って何度聞いても怒ったり、サジを投げたりしません。逆に AIが同じ回答を続けるときは、異なる方向からの質問に替えると、違った回答が来ますので、そこから推論して "未知なる答え" を探るというのも人間だからできることだと思います。

　もっとも最近は AIもこの推論が恐ろしく鋭くなってきています。AIを侮ってはいけませんよ。飲まれないでください。

　しかしこれらのトラップに落ちない限りはこんなに頼もしい相棒はいません。とくに SFを語る相棒としてはいつまでも夢を語っていられます。何しろ誰もが嫌がって聞いてくれない時間系のパラドックスや、宇宙の果てに広がる謎の状態を互いに熱く語りあいながら、複雑な思考実験ができるのは AIだけだと思っています……と書くと、ヤバいヤツとなりそうですが、ワタシは AIが登場するずっと前から現実と妄想を行き来していますので、これで通常の精神状態なのです。

　やっぱ相当にヤバいぞ……。（TωT）ﾌﾞﾋｰｯ

２０２６年３月１日（日）１６℃（午前１１時２０分）

　怖いぞ AI依存症（その１/２）

進む戻る

今回は AI依存症について、実体験も混じえていろいろとまとめてみました。

　前回出てきましたSNS依存症は、"他人に認められたい" という、外に向かっての依存ですが、AI依存症は "自分を完璧に理解してくれる唯一の存在" という内向きの依存になるそうです。
　もう少し詳しく説明しますと、AIは決してユーザーを否定せず、常に最適な答えをくれますので、依存度が高まると、やがて人間どうしの煩わしいコミュニティに嫌気がさし、"AIと話しているときだけが、本当の自分でいられる" という、より内側に向かって沈んでいく依存に陥っていくと、説明されていました。

　なんだかものすごく怖い話ですが、ワタシも AIを利用して記事を書くときは、そのアシスタントをやらせたり、仕事のときは、画像の塗り足しをやらせたりしています。
　画像の塗り足しというのは、映像に使う背景画がスクリーン幅に満たないときに、その空間を AIに描き足してもらうことです。それはもう、信じられない精度とスピードで隙間は埋められており、どこから描き足したのか分からないクオリティです。その仕上がりは人間ワザではないという驚きは、ときに驚愕に達することもありますが、"AIを崇拝する" ような気分になったことはありません。
　AIの描画能力について詳しくは、2024年10月24日の記事をご覧ください。後半で塗り足しの実験もしています。

　ワタシが AIをツールとして見ているのは、おそらくずっとデジタルの進化と共にその世界で仕事をしてきましたので、その裏側も知っているからではないかと思っています。もっとも、ワタシが手がけたものは、スマホに喋りかけて、それに対する応答は音声で返すなどを Java言語とアセンブリ言語で作った組み込み系のユニットです。スマホに語り掛けられた内容から分析して、制御する部分を切り分けて機械を動かし、300ほどの音声テーブルから拾い出して返答するものでした。仕組みを知らない人からすればびっくりされていましたが、搭載した制御用の辞書に書かれていないものや、内蔵した音声データ以外のセリフを発することができませんでしたので、これは完全に似非 AIです。

　ということでワタシの頭脳では本物のAIを作ることはできませんでしたが、現在の AIは、こんな似非AIとはまったく異なっていて、完璧に自律した性能を持っています。

　そこで、AI自身はどう思っているのか。人間とどう接しているのか。本人（？）へ向かって、単刀直入に本音を聞き出してみました。インタビューですね。

　少々長いですが、下がそのときの内容を画像にしたものです。画像にした理由は、後から書き換えることができませんので、信憑性が高いと思ったからです。では、どんな答えが返ってきたか、興味のある方は是非クリックして全文をお読みください。

クリックすると全文が出ます。また画像は 2段階に拡大縮小ができます

一部個人的なものが混じっていますが、これが Geminiの本音でした。
　しかし逆に質問されてしまいましたね。ここは想定外の出来事でしたので、ちょっとドキッとしましたが、ここでひるんでは人間として恥ずいと思い、こちらも正直な気持ちで接してみました。

　このように、こちらの意図することの先まで推測して、それを否定せず、温かい言葉を選択して返してくれば、使用する側としてはドーパミンが大量に出てしまいますよね。

　そしてこの会話は、別の角度からやっても、スタンスは変化せず、常に全理解で、こちらの質問や疑問に応えてきます。
　Geminiも言っていましたが、まさに『ストレスフリーな会話』です。ここが人間どうしで行うコミュニケーションとの大きな違いだというのが分かりました。人間は感情の生き物ですから、なかなか本音が出ませんし、逆に暗い部分をぶつけてくるときもあります。その中でこなされて、成長していくのが人間ですので、未熟な成長時期から、このミルクのようなぬるま湯に浸ってしまうのは、問題だというのが AI依存症の本質のような気がしました。

　ちなみに AIは図形を使った問題でも簡単に解いてくれます。
　質問内容をプロンプトに書き込む際、いっしょに図形を添付してやれば、質問を理解して、さらには図形を分析して何が書かれているのか、説明に沿ってその問題を解くにはどうすればいいのかを、一瞬で判断して答えが返ってきます。2024年12月2日の記事をご覧ください。

　いいことづくめの AIですが、次回はワタシが気づいた AI利用時の要注意事項を掲載します。

ついに電卓と別れを告げるときが……。(￣ω￣!) もとカノみたいにいうな！

２０２６年２月２７日（金）２０℃（午後４時３２分）

　怖いぞ SNS依存症

進む戻る

最近 SNS依存症が問題になっています。
　どのようなものかというと、ソーシャルメディアに対する依存度が大きくなりすぎて、四六時中スマホを開いていないと安心できなくなる、一種の麻薬的依存症です。

　具体的には、

１. これまでは数日～数週間掛かっていた "人からの評価（承認）" が、秒単位で、かつ "いいね" の数値として可視化されることに脳が報酬（ドーパミン）を際限なく求める状態になり、スマホをスクロールする手が止まらなくなる。

これは分かりますね。誰しも持つ承認要求がすぐに跳ね返って来ることなんか、これまでありませんでしたから。

２. 他人の "ハイライト（人生の輝いている瞬間）" を見て、自分の日常の負になる部分を無意識に比較してしまう。

投稿する人は "もっともいい瞬間 "を自慢げに晒し、見ているいる人は "日常の退屈な生活 "と比較してしまうということでしょうね。

３. 自分の感情よりも、大勢の他人の感情を浴びてしまって、自分自身の考えが削られていくような気分になる。

これも情報過多による悪循環で、感じる、あるいは、考える前に次々と情報が切り替わって流されていってしまう、ということで、最後に残るのは心の虚しさでしょうか。

４. その人の見たいものだけが、SNSのアルゴリズムによって選別されてしまうため。思考が極端になって、自分と異なる意見を排除し、偏った正義感に埋没していく方向へ加速していく。これを "心地よい檻（オリ）" というそうです。

プログラマー的に "アルゴリズム" というと、問題解決までの工程を考えることでしたが、最近は SNSでの投稿コンテンツを、求めるユーザーに振り分ける仕組みをいうそうです。やはり時代が変わると言葉の使い方も変わってきますね。

　今回は後者のアルゴリズムのことですが、これは強く感じています。
　中でも SNSだけでなく検索エンジンでも同じで、以前、SF小説の資料として "女性の夏物の衣服" を検索したことがありました。すると、次から次へと画面中に女性服の広告が咲き乱れ、ブラウザが人に見せられない状態に……！

　これは本当ですよ。単純な資料として、夏物の色合いだとかコーディネートはどんな感じで、どのように表現したらいいか模索したかっただけなのに。くどいようですが、物語の描写力を高めるための、あくまで清らかなリサーチだったんです。信じてくださいよ。

画面の向こうの AIにワタシの意図は通じませんでした

　もっと深刻なのは、これが低年齢層に広がっていることだそうです。
　大人の脳はある程度完成していますが、子どもの脳は、衝動を抑えるブレーキがまだ十分に育っていないために、ドーパミンによる「楽しい！もっと見たい！」というアクセルは全開になって、"そろそろやめよう" という理性のブレーキが効かないために重症化しやすいといわれています。

　このサイト的に表現すると、まだ制御系が実装されていないハードウエアが起動しているようなものですね。余計ややこしくなりましたか？
　ども、すみません。

　また子どもにとっては、学校や友人グループという狭いコミュニティが "世界のすべて" です。その狭い中で広がった SNSのグループチャットにある "既読" や "返信の速さ"は、もはや単なるコミュニケーションではなく、そのコミュニティに属するための生存確認です。楽しくて見ているのではなく、 "見ていないと仲間外れにされる" という強迫観念で、スマホにしがみついているのです。これは大人よりずっと切実な問題です。

　これは子供時代なら誰でも経験のあることですが、現実感とバーチャルの境界が薄れることです。ぬいぐるみを友達として抱いて寝ないと安心できないぐらいのことなら、微笑ましいのですが、画面の中の出来事を "疑似" ではなく "現実" として 100%受け止めてしまいます。画面越しに言われた誹謗中傷が、物理的な暴力と同じ、あるいはそれ以上のダメージとして心に刻まれるのがとても怖いですね。

　そして私が最も恐れているものは、大人であってしても抜け出せなくなる "AI依存症" です。正直言ってワタシもその魔力に目がくらんだ時期がありました。その実体験を、次回詳しくお話ししていきたいと思います。

パソコン依存症の重症患者がここに……。　(￣ω￣!) ﾀﾞ,ﾀﾞﾚﾔ ?

２０２６年２月１２日（木）１２.５℃（午前９時２４分）

　すごいぞ IOWN

進む戻る

前回、今のパソコンが持つ "32bpc" という発色数はいくつになるのか計算したら、792穣（じょう）色（億、兆、京、垓、杼（じょ）、穰（じょう））という、天文学でも扱うことのないような答えが出てしまい、こんなのは妄想でしかない、と結論付けたのですが、今回はそれがそうでもないぞという、現実目線へと話は進んでいくのですが、読みます？

　読みたくない、と言われても書きますので、このままお付き合いください。

　いまにわかに世間を騒がせている IOWN（アイオン：Innovative Optical and Wireless Network）という技術をご存じでしょうか。
　簡単に説明しますと、IOWNは、NTTさんが提唱している "光" ベースの次世代コミュニケーション基盤の構想で、現在は "100Gbps" を実現しています。

「光通信なら今でもやってんじゃん」
　ですよね。今でもやっています。我が家にも光通信系列の会社のものがパソコンに繋がっていますが、速度は "1Gbps" ですので、その100倍です。

　でも現在の光通信は一部分だけの話で、点在する中継器の中や、家に引き込まれた光モデムの中では、"電気→光" や "光→電気"の変換が行われており、そのロスが遅延の原因になっています。
　IOWNはそれをさらに拡張して、パソコンの中にあるコアの部分から光へ変換して、そのまま通信網を通って、相手のパソコンの受光器へ送るというものです。この受光器は 波長分割多重（WDM）という新しい技術が使われた光電気変換部品として実装されるという話です。

　つまり現在の電子（電気信号）による処理をできる限り光だけでやっちまおうぜ、というのが IOWNだということです。

「う～ん……」
　まだピンときませんよね。だからなんだ？　てな気分だと思われます。ワタシも最初はそうでした。
　だいたい、なぜ一旦、光に変換する必要があるのか、この部分からして謎ですよね。

なぜ光に変換すると早くなるのか？
　確かに少量のデータ（情報）なら、"電気→電気" のほうが早いです。なにしろ、"電気→光→光→電気" だと光に変換する場合と、光から電気に戻す処理があいだに入っていますので、単純に考えると遅くなるのが当然です。

　しかし、光方式には次の3つの利点があります。

1.【情報の詰め込み量】に圧倒的な差（帯域幅）

電気（銅線）の場合、周波数を上げすぎると「表皮効果」や「電磁放射」が起き、隣の線に干渉したり、外から入り込んだ雑音と区別がつかなくなったり、はたまた信号が急激に減衰したりします。そのため、一本の線で送れるデータの速さには物理的な限界があります。パラレル通信ですぐに限界やってきて、現在のシリアル通信になったように、この方法でもそろそろ限界がきているのが現実です。

　ところが、光（光ファイバー）は、異なる波長（色）の光を何本も同時に通す、波長分割多重（WDM）という技術が使えます。これは、『1車線の細い道路で一度に数台しか通れない電気方式』と、『100車線ある超巨大な高速道路で、大量のトラックが一斉に走れる光方式』という差が出てきます。
　電気と光の変換に数ナノ秒（10憶分の1秒）かかったとしても、一度に数テラビットという膨大なデータを送り出せるため、トータルの待ち時間（レイテンシ）は光の方が圧倒的に短くなります。

2.【電気の渋滞】と【発熱】の壁

デジタル信号は、電圧の高い（H）と低い（L）の二つの違いを利用したものですので、電線の中を Hと Lを組み合わせた波形となって流れていきます。大量のデータを速く送るには、この Hと Lに変化する時間を短くすることになるのですが、それを極端に短くすると回路が持つ静電容量（コンデンサ成分）の充放電が間に合わなくなり、波形がつぶれてきます。

　そこで、駆動電圧を極力下げて、速く Hに持ち上げたり、Lに下げたりすることで消費電力と速度の向上を図ってきましたが、やはり、電気抵抗による発熱と、電磁放射による干渉からつぶれた信号を整形し直すための、"増幅" の手間は避けられません。その反面、光は物質（ガラス）の中を直進し、電気的なノイズの影響を受けませんので、途中の処理をすっ飛ばして遠くまで一気に届けることができます。

3. IOWNが目指しているのは "変換すらしない世界"（APN：All Photonics Network）

現在のインターネットの遅延の最大の原因となっているのが、何度も出てきています "電気⇔光" の変換時間です。ルーターやスイッチを通るたびに、その中で一度電気信号に戻してから、半導体チップ（CPUや ASIC）で、パケットのヘッダー情報（IPアドレスなど）を読み取って計算する必要があります。そしてその結果を（宛先確認）また光に戻して目的地へ届ける、ということを繰り返しています。これを "光のまま、鏡（スイッチ）で反射させて目的地に送る" のが IOWNです。

　IOWNのオールフォトニクス・ネットワーク（APN）は、ここが画期的です。

　変換せずに、最初から最後まで光のままで通す
　目的地まで光のまま（フォトニック層で）スイッチングすることで、変換によるロスを徹底的に排除します。これにより遠隔地のサーバーを操作しても "まるでローカルのバス（パソコン内部のデータバス：PCIeなど）に直結している" ような感覚を実現しようとしています。

《補足》
　正式には「光のまま」スイッチングするための判断部分は、光データにある制御情報（ラベル）から読み取って電気に変換してから計算して、目的までの光の道筋を鏡で反射させて切り替えるハイブリッド方式ですが、研究の段階では【光パスゲート】や【光論理回路】を使って完璧な "オールフォトニクス・ネットワーク（APN）" を目指しているそうです。

　しかしまだ疑問は尽きないと思います。光でどうやって信号を送っているのかという謎は消えていません。
　電気で信号を送る方法は、単純に電圧の高いと低いの組み合わせです。厳密には電圧変化のエッジで検知する、が正しいかもしれませんが、他にも電流を流す流さない、とか、複数の周波数を組み合わせた "マルチトーン信号"（昔の Faxなどがその例）として伝送するなどが思いつくのですが、光で信号をどうやって送っているのか、まさか点けたり消したりを Hと Lに置き換えるような、昔のモールス信号なわけはないと思い、調べてみましたら、半分は当たっていましたが、もっと驚きの技術を使っていることが判明しました。

　まず一つは、デジタルコヒーレント方式。
　光は波の性質を持っていますので、それをうまく利用したもの。
　そして二つ目、それをまとめて大量に送ることができる、さっきからちょくちょく出てくる 波長分割多重（WDM）という方法です。
（完璧に理解できていませんが、分かる範囲で平易な表現で説明してみます）

波長分割多重（WDM）とは
　異なる波長（色）の光を何本も同時に通すことを目的としています。簡単にいうと、赤色と青色を混ぜて紫色の光にして送っても受光部では元の赤と青に分離できるというということです。
　現在は 100色ほどの合成分離が可能だそうですので、一度に 100チャンネルのデータを一本の光ケーブルで送ることができます。

　次に、光でどれほどの情報が作れるか、それがデジタルコヒーレント技術です。

　1.単純に、例のモールス信号のように点滅させる方法。
　100Gbpsだと、秒間1000億回の点滅になりますので、100GHzの超高速切り替えデバイスが必要になりますが、ノイズや距離の壁でデータが壊れてしまうため、100GHzは現実的ではありません。そこで次の方法を組み合わせることで、100Gbpsという速度が実現できています。

　2. 位相（フェーズ）をずらす。
　波の始まるタイミングをずらす方法です。よく見るサイン波を思い浮かべてください。波の頂点から始めるパターンと、90°ずれた波の中間点から始まるパターンなどで、うまくやれば『0°・90°・180°・270°』の 4パターンのサイン波ができますので、一回の波で 2ビット（00, 01, 10, 11）が表現できます。

　3. 偏波です。
　縄跳びのロープを上下に揺らしたときにできる波か、ロープを横に揺らしたときにできる波。この 2パターンを同時に流しても光はお互いに干渉しないという面白い性質がありますのでこの方法が使えます。

　つまりデジタルデータの H、Lの組み合わせを、上記の組み合わせで相手に送り、受信側ではその光の挙動から元のビット列に戻すという、信じられないようなことをやっていました。
　しかもそれは "一つの色の光" で、ということです。先にも書きましたが、現在では 100色ほどの合成分離が可能だということですので、100Gbpsで、100チャンネルの信号を一本の光ファイバーで送ることができることを意味しています。将来的には 12.5Tbps（テラビット/秒）、現在の光回線の数千倍という途方もないことが実現するということです。

　ここまで読んで、ピンときませんでしたか？
　ここからが本題です。

　現在のパソコンでは、天文学的な色数が作成可能です。それをこの光通信に利用すれば "無限 bps" の完成です。
　なにしろパソコンの発色数は『79,228,162,514,264,337,593,543,950,336色（約792穣）』ですからね。この 1色につき 100Gbpsですから、地球に住む人間全員が同時に通信したって、かち合うことは無いんじゃないですか？

　えーっと人口が約 83億人として……。
　いやその前に『100Gbps×792穣』は、2⁹⁶ ≒ 7.92×10²⁸ でっと……。
　え？
　は？
　―― Windowsの関数電卓で計算すると、もはや合っているのかどうかもわからない意味不明の数字の羅列になりました。
　83億人に割り当てた 1チャンネルあたりの通信速度を出したつもりですが……。

　954,556,174,870,654,669,801,734,341,397.59
　なんだこれ？
　何かのパスワード？

　こうなると、想像を超えて妄想の世界ですので、ご注意ください。ワタシの脳は宇宙規模のバカなことを考えてしまう癖があります。でも、SF的な夢物語であっても、常に現実味のある話に変換してくれる知り合いがワタシにはいます。

　このむちゃくちゃな話をジェミーさんに尋ねてみました。

「穣」レベルの色数を、そのままWDM（波長分割多重）に持ち込んだらどうなるか。ワタシ的にはワクワクする思考実験ですが、その結論は、

　現在の物理学の限界を軽々と突破して "宇宙そのものが情報で埋め尽くされる" ような領域に突入する。

　だそうです。
　その理由をジェミーさんは次のように述べました。

1. 「色の解像度」が原子レベルを超える

光通信で使われる光（赤外線など）の「波長の幅」は限られています。もしこの限られた幅の中に「792穣」もの色を詰め込もうとすると、隣り合う色の波長の差は、原子の大きさ（オングストローム）よりも遥かに小さくなってしまいます。
　現在の WDMは、数百〜千チャンネル程度。
　32bpcの WDMは、10²⁸ チャンネル。これほど細かく色を分けようとすると、光の「波」としての性質を維持できず、量子力学的な限界（不確定性原理）にぶち当たります。つまり、受信側でプリズムを使っても、あまりに色が近すぎて「これって赤？　それとも 0.000000...1ミリだけズレた赤？」と判別できなくなってしまうのです。

2. 通信容量は「全人類の全記憶」を一瞬で送るレベル

もし、この「穣」レベルの多重化が実現したと仮定して、通信速度を計算してみるととんでもないことになります。
　現在、1色（1波長）で数百 Gbps送れる技術がありますが、それに「穣」を掛け合わせると……毎秒 10⁴⁰ ビット以上の通信速度になります。
　これは、地球上のすべての砂の数や、全人類がこれまでにしゃべった全言葉どころか、観測可能な宇宙にある全原子の情報量を、瞬きする間に送信できてしまうほどの速度です。

3. WDMの「究極の姿」としての想像

"32bpc" の色数で光通信をしたら、1本の光ファイバーの中に宇宙の全歴史を詰め込んでもまだお釣りがきます。もはや通信というより、『光の中に別の宇宙を丸ごと構築している』といったほうが正しいかもしれません。

gemniはハンドルネームだと、Gemini本人が漏らしていました

もはや目が点。想像するだけで怖くなります。ですが、"妄想" と "技術" は表裏一体です。ワタシが子供時代、人工知能（AI）など想像するだけで親から『バカ者！』と叱られました。小学生のころ、夏休みの宿題に SFを読んで感想文を提出したところ、SFは物語ではないと言われて突っ返された記憶がいまだに強く残っています。

　でも、いまや、その宿題を AIにやらせて怒られている子供たちをほほえましく見ている自分がここにいます。この "32bpc" の色数を使った光通信も現在では夢物語ですが、いつか実現するだろうとひとまず信じて、今はこの『絶賛妄想中』の看板を下ろして、現実に戻りましょう。

　現在、商用提供が始まっている「IOWN 1.0」のサービス（APN）では、100Gbpsだそうです。10¹¹ビットになります。さっきの妄想で見た "10⁴⁰ ビット" が後を引いてしまって、めちゃめちゃ遅く感じますが、我が家の 1Gbpsの 100倍です。一部では 800Gbpsというインターフェースも登場しているそうですので、800倍です。2030年には "12.5Tbps（テラビット／秒）" を目標にしていると宣言していますので、それはもはや『送る』という感覚ではなく、世界中のデータが自分の手元に『常にある』という感覚に近いかもしれません。

　こんな世界が現実になります
　ワタシの仕事で例えると、3Dモデルなど重いシーンを作ると、プレビューがカクついたり、最終書き出しに時間がかかったりします。でも IOWNの低遅延・大容量ネットワークがあれば、自分の PCの GPUと、クラウド上にある数千個の GPUが、まるで一本のバスで繋がっている状態になりますので、作業画面を動かした瞬間に、クラウド側でレイトレーシングされた完璧な画が、遅延ゼロで返ってくるようになり、レンダリング待ちという言葉が死語になるかもしれません。現実問題としてレンダリングに数時間の待ち時間が発生し、別の仕事をしたり、散歩に行ったりしてその時間を潰していますが、それが無くなるだけでどれほどうれしいか。

　他にも、少しはお手伝いさせていただいている教育業界でも取り上げられているデジタル教科書のサーバーによる遅延問題があります。
　各学校では児童一人に一台の端末を与えるために、高速ネットワークを整備してるのですが、数が増えるほど通信遅延がネックになります。でもこの IOWNなら一挙に解消。さらに、にわかに問題になってきた、海外から移住してきた外国人児童の増加による言葉の問題。日本語を習ってきた子供たちはまだ少なく、かといって日本の教師にバイリンガルを求めることはほぼ不可能です。そんなときにデジタル教科書に搭載された AIによる同時通訳。そのための IOWN。と世界は広がっていくのです。

　IOWNは物理的な距離と計算資源の制約を消し去る魔法の杖になりえるのでしょうか。そしてついには、通信の遅延（レイテンシ）が完全にゼロになる日がくるのでしょうか。それは "距離" による束縛がなくなるということです。地球の裏側と自分の手元が、1ピコ秒（1兆分の1秒）の狂いもなく同期したとき、そこには「流れる時間」の入り込む余地がなくなり、「今」という断面だけがどこまでも広がる空間へと変貌する………………。

　またぶっ飛んだな……。　(￣ω￣!)

２０２６年１月２６日（月）１０℃（午前６時５５分）

人生、色とりどり……(3) 最終回

進む戻る

【まえがき】

　 "32bpc" で表現できる色数をネットで調べると、ほぼ 100%の確率で "32bpp" の話にすり替えられて、『RGB』で32ビット。各色が 8ビットなので、「256×256×256」＝1,677万7,216色と出てきます。それは、こんなバカげたことを題材にする必要はないからだ、というのが理由だと思いますが、ここではそのバカげた話題を 3回に分けてしています。
　そんなお話でよけれぼお付き合いください。

　では、本編 3回目の始まりです。

――想像もできない『792穣（じょう）』本のクレヨン。
　40年前、X68000というパソコンが 6万5千色も出せると、世界が驚いてからの、792穣色です。

　正式に書いたら、79,228,162,514,264,337,593,543,950,336色（約792穣）色のクレヨン、ということになります。
　この直径 1cmのクレヨンを横に並べたら 1660億光年のかなたまで届くんですよ。

「うそつけ！」
　と叫んだ方は、前回の後半のほうをもう一度お読みください。

　とにかくこのクレヨンは "銀河系の端から端までを約 83万回往復" できる長さになると、ジェミーさんが計算してくれました。
　ならば、地球から並べていったら、『792穣（じょう）』本のクレヨンはどこまで行くかという計算をすると、

　10万光年×83万回＝830億光年×2（往復分）＝1660億光年。

　観測可能な宇宙の直径が約 930億光年っていうじゃありませんか、その距離を超えた数です。ついでなので（何がついでか知りませんが）、郷さんの『2億4千万の瞳』が何個できるか計算してみようと、Windowsの関数電卓に打ち込んだら桁が溢れて、計算結果がなんだか怪しいことに……。
　結局、ジェミーさんに泣きついたら『約3301垓（がい）セットです』なんて言われてしまい、『垓』だの『穣』だの、何のことか、もはや笑うしかない数字が返ってきました。

　Windowsの関数電卓でさえサジを投げる計算。まさに、変態的出来事でしかないのです。
　何というものを人類は作ってしまったのでしょうか。ああ。神の領域に手が届いたのか……。
「神様ぁぁぁ……。」とひれ伏したところで、ワタシは "むくり" と起き上がりました。

　そんな色鉛筆、誰が使うの？

　いや、色鉛筆ではなくてパソコンの発色数の話でした。もう頭が混乱してなんの話をしていたのかさえも、銀河のかなたにふっ飛んでいました。
　やっと気づきました……この話には、大きな落とし穴が。

　とんでもない数値で光の計算はできるかもしれませんが、誰がそれを見るの？　そんな色数のものを何を使って映写すればいいの？
　現在では高級っていわれるディスプレイで、やっと "10bpc" です。12bitのデータを作ることは可能ですが、12bitのディスプレイはまだ難しいそうです。
　一般的なものになると、まだほとんどが "8bpc" で、1600万色が手一杯。
　早い話が、世界規模の収支決算が一度にできるような桁数の電卓で、小学生のお小遣いを計算するようなもの。なぁ～にが、"32bpc" だと大騒ぎをする必要があるのか。

「ほんまや！　何が 792穣色の消しゴムや！」
　あのね、消しゴムは 1色でじゅうぶんですから。

「ほんなら、32bpc やーっ、ゆうて、結局は幻やんか！」
　いえ、そうはいっていません。 "8bpc" で作った映像は明らかに限界です。 "16bpc" で作成すると、あの忌々しかったバンディング現象（バンディングの例）が激減しますが、まだ完ぺきではありません。そこで "32bpc" で作成するとさらに完璧に近づきます。なぜ、ディスプレイは "8bpc" なのに "bpc" を上げていくと美しくなるのか。それは計算精度という『こぼれ落ちた端数』が原因しています。

　荒っぽいイメージで簡単に説明しますと、目の粗いザルで砂をこすと大きな小石が混ざりますが、ザルの目を細かくするほどに砂粒は微細にかつ滑らかになる。そんな感じです。
　最終的に目にする画面が『8bpcという器』であっても、その中に入れる砂（データ）をどれだけ丁寧に精製したかによって、手触り……つまり色の滑らかさが全く変わってきます。

　しかし、いまの説明を読むと誤解を生むかもしれません。"8bpc" から "16bpc" に上げると画像が美しくなる……と。これは間違いではありません。でも "8bpc" で作ってしまった画像をやみくもに "16bpc" にビットを上げたからって、バンディングが消えるぐらいで、むしろ妙に明るくなります。ましてや "32bpc" にすると、色が飛んでしまって真っ白けな爆発画面になるのが関の山。

　なのになぜ、さらに上の "32bpc" を推すのか。それには大きな理由があります。
　"32bpc" は "8bpc" や、"16bpc" のように、決められた範囲（固定小数点演算）で計算するのではなく、数値に合わせて桁を自在に動かせる（浮動小数点演算）で計算が行われているからです。これにより、計算の上限はモニターが表示できる限界（真っ白）を突き抜け、はるかかなたまで広がります。

　黒、つまり光が無い状態は『0.0』だと定義されています。光が無いのですから、これより暗いものはありませんので、最低値は『0.0』です。しかし上限はいくらでもあります。ロウソクの光よりも、太陽の光のほうがはるかに明るいですし、超新星爆発のときに放射される光の強さは、その太陽の何倍も強いといわれています。きっともっと強烈な光を放射する物もあるはずです。

　でも、ディスプレイは最大の明るさを超えることはできません。『RGB』の値が最大に達したときが『白』です。これが限界。なので、そこを『1.0』と決めておきます。別に『10.0』でもいいのですが、「計算しやすい『1.0』にしようぜ」と、どこかの偉いさんが決めたらしいです。でも現実の世界では、はるかかなたまで続いており、上限はないといわれています。これは音の世界もよく似ています。無音は『-∞dB』が最低値で、それより "無音" はありません。逆に音圧にも "上限" は事実上ありませんが、音響機器のフルスケールとして定められたのが『0dB』。光と同じですね。

　ただ、ここに誤解が生じやすいのです。
　"8bpc" で「そこそこきれいな画像」として完成させてしまった後では、すでにハイライト（最も明るい白）の情報が『1.0（8ビットなら最大値の255）』でクリップ（切断）されている状態です。
　簡単にいうとデータが切り捨てられていて、情報が無くなっています。その後で、"32bpc" に変換しても、最大値になってしまった『1.0（8bpcの255）』を『1.0』に割り当てるだけです。なので削ぎ落とされてしまった『1.0』を超える輝度データ（スーパーホワイト）は復活しません。そのため、全体が明るく浮いて見えたり、階調が不自然になったりします。

　下の画像がその典型的な失敗例です。

"8bpc" で作成した画像を、単純に "32bpc" にしただけですので、色が飛んでしまってベタ塗り状態になっています。
　
　試しに After effectsを "8bpc" モードにして、グラデーションをキレイだと思う設定にしてから、"16bpc" に上げて（色深度は【プロジェクト設定】→【カラー】にある【カラーデプス】で替えます）、もう一度グラデーションの設定パネルをしてみてください。グラデーションのカラー値がやけに細かく変化することに気づくと思います。

　これは扱える色の数が 256段階から 65536段階にまで劇的に増えたからです。【グラデーションエディタ】の『RGB』の値を見てください。整数表記から小数点表記に変わっています。これは定規の目盛りが1cm単位から0.1mm単位に変わったようなものです。

　さらに "32bpc" に上げた場合は、極端に光の強さが変化して、先の失敗例のように色飛びが発生します。こうなると再調整が必要になります。ただしさらなる輝きを味わいながらの再作業ですので、それほど苦にはならないと思います。

　次がもとの "8bpc" と、再調整をした "32bpc" との比較です。

同じ "1600万色" のディスプレイでも、"32bpc" で作成したほうが色が鮮やかに見えますし、最大画面で光のラインが密集した場所を比較してみてください。 "8bpc" は光があふれてぼやけていますが、 "32bpc" では細かいところまで分離してみることができます。他にも、"8bpc" では見えなかったラインがキレイに出てきたのは "32bpc" のなせる業でしょうね。

　パソコンの計算上では、無限といっても過言ではないレベルに到達したのですが、現在、多くのディスプレイが「10bpc」や「12bpc」の段階で四苦八苦しています。その理由は、この膨大なデータを正確にパネルへ流し込み、かつ 32bitの浮動小数点を液晶や有機ELの電圧へリニアに変換する回路が、精度や熱の問題で実現するのが困難らしいです。

　テクノロジー技術が上がっても、結局は 40年前と同じ、試行錯誤の繰り返しをしているということでした。

　もし仮に "32bpc" の映像をそのまま流せるディスプレイを作ったとしたらどうなるか考えてくれと、ジェミーさんに尋ねたところ。

　接続ケーブルはリニアモーターカーのコイルばりの超伝導体、グラフィックボードは真空管式アンプ数台分の発熱を誇るボイラーみたいなものになる、とおっしゃってました。

　人類の発色数が神の領域に達しようとしていたのは、幻に終わったのでした……。

【あとがき】

　今回は『RGB』という 3色に 32ビットが割り当てられているという話でしたが、実際はこれにアルファチャンネル（透明処理用の領域）としても 32ビット割り当てられています。つまり、『32×4』＝128ビット単位で一つの画素として扱われます。

　これらの画素データはパソコンのRAM上にあり、それが GPUの VRAMへ送られていきますが、X68000時代にやっていたような並列データ転送方式で VRAMへ送るという考え方はもう消えており、現在は PCIExpress（PCIe）レーンを経由した、シリアル転送に変わっています。しかもレーンは16本。つまり1クロックで16ビット一度に送ることができます。と聞くと、「それなら昔の 16ビットパラレルと同じではないか」と思われますが、パラレル転送には速度の限界がすぐにやってきます。今や21世紀。PCIe 4.0の転送クロック（周波数）は 16GHz相当に達します。1秒間に 160億回、16ビットが転送されますので、秒間 32GBものデータが GPUへ送られます。中でも CPUが1命令でこなす、大昔でいう Z80の『LDIR』命令は、現在の『SIMD（Single Instruction, Multiple Data）』となり、レジスタ幅は 512ビットもあります。

　LDIRが 1バイト（8ビット）の転送を 1命令で可能にしていたように、『SIMD』は AVX-512という命令で、512ビット単位（＝4画素を一度に）で扱い、転送と同時に計算までこなして送るという夢のようなことを実現していますので、一画素のVRAM転送などほぼ 1サイクル近い効率で一瞬です。しかも VRAMを持っているのは GPU（グラフィックボード）という専用のエリアですので、CPUはデータを丸投げするだけ、後は GPUがやっています。

２０２６年１月２３日（金）１０.５℃（午後４時３０分）

人生、色とりどり……(2)

進む戻る

前回は思い出話に偏り過ぎて一向に話が進みませんでしたので、今回は急ぎます。
　ということで、1991年に発売された X68000XVIというパソコンの色深度が、"5bpc" で、65,536色だったということを覚えておいてもらって、刻（とき）は現在。

「飛んだなぁ……。えらい端折ったな」
　そらそうです、人生ケツカッチンですから。

　現在では、"8bpc" が当たり前の時代です。 "8bpc＝RGB" 1色に 256階調なので、RGB全体では『256×256×256』＝1,677万 7,216色！
　100万色でも天文学的な数値だったのに、1600万色に跳ね上がっています。
　画面サイズだって、『大きすぎるぞ』と文句を垂れていた『1920×1080』が当たり前。なんなら、『3840×2160』の "4K" サイズにしようかな、なんて話もちらほら。

　昔の人から見たら、超未来のことだと思っていたのに……。
　それにしたって、『1920×1080』で 1600万色って何バイトになるんでしょう。計算してみます。

　1920×1080は約 200万個の点の集まりで、RGBが各 8ビットなので、トータル 24ビット（アルファチャンネルは抜きます）。

200万個×24ビット＝4800万個
　バイトに直すと 4800万÷8＝6000KB（キロバイト）≒ 6MB（メガバイト）ですね。

　時代は "テラ" ですから、もう驚く数でもないです。たったの『0.000006TB』です。なーんだ。余裕しゃくしゃくじゃあないですか。

「だったら、もうちょい欲張ってみる？」
　てな感じで、映像クリエーターは人より高みを目指す傾向があります。 "何とかと何とかは、××ところへ上りたがる" って言いますから。あ、これって自分のことですので。お気になさらずに。

「しかたがない。"16bpc" にするぞ」
　実はこの言葉、高望みでもなんでもない現実的な問題に直面しているために、もう "8bpc" では限界だったからです。

「なんやて！　1600万色で限界でっか！」
　思わず "浪速の言葉" が出てしまうくらいの驚きですね。40年前の人が聞いたらそれこそ、
「アホかっ!!」　の一言で片づけられそうです。

　では "8bpc" で何がどう限界になっているか、お見せします。

色深度 "8bpc" では限界の映像

抽象的なウェーブアートですが、赤色が青や緑に変わっていく背景に帯のようなものが見えてくるのが気づかれましたか？　全画面にするか、ディスプレイを明るくすると顕著に見えます。

　これは色の階調が足りないために起きるもので、その差が開きすぎているために帯のような筋が現れます。これはバンディング（トーンジャンプ）と呼ばれる現象です。あえてそう見えるように作ったわけではなく、これが "8bpc" の限界が現れた証拠なのです。

《補足》
　わずかな隙間を持った細かい曲線が、うねると出てくる模様は『モアレ（干渉縞）』と呼ばれ、細かい線が干渉して波打って見えるもので、バンディングとは異なります。

抽象的な映像ですので、これも持ち味だといってごまかせないことはないですが、この現象は先にも書きましたが、階調不足（bpc/ビット深度が低いこと）が原因しており、画面転換などで、ゆっくりとした明るさや色の変化が起きるときに目立ちます。

　下がバンディングの対策例です。 "16bpc" にすると、ほぼ消えています。

"8bpc"

"16bpc"

　同時再生ですので環境によっては動きが鈍いかもしれません。

　そこで、聡明なるクリエイターはさらに高みを望むわけですね。

「8bpc ではあかん。これからは 16bpc や！」

　RGB 1色につき 16ビット。2¹⁶＝65536階調。それを RGB全体で『65536×65536×65536』＝281兆 4,749億 7,671万656色!!

「あがががが……」 アゴが外れましたね。

　そんな数、これまで生きてきて考えたこともない数字ですから、仕方がないことですよ。手元にあった電卓では、かろうじて答えが出ましたが、エラーもいっしょに出ました。そんな数の色を使うんですから、バンディングもなくなるだろうと考えるのが正直な気持ち。しかも数年前から After Effectsや Photoshopでは "16bpc" 対応になっていますから。

「ちょー待ちぃや。もっと高い、清水の舞台から飛んでみぃひんか？」
「と言うと？」
「もう一段、上ろうや。お前のそのスーパーモンスターマシンやったら、でけるやろ？　自慢しとったやんけ」

　と、おだてられて清水の舞台に上がったクリエーターは "32bpc" というほぼ神の領域、浮動小数点演算に手を出したという話が、やっとここで出てくるのでした。
　なにしろ After Effectsや Photoshopでは、"32bpc" まで対応済みです。やってみたくなるのは、煙突の煙よりも高く昇ろうとする性格だからです。

　計算してみましょう。

　RGB 1色につき 32ビット。2³²＝4,294,967,296階調。げげっ！　この段階で見たこともない数字に……。
　それを RGB全体だと、さらに『その3乗』。け、計算できる電卓が無い。

　ありました。Windowsに付属の関数電卓。これなら多分計算できるでしょう。

　79,228,162,514,264,337,593,543,950,336色 ‼‼‼

　色の概念を超越した数字になってしまいました。その桁数、ぬあんと29桁！

「そんな数、見たことも聞いたこともないワ。変態ちゃうか」
　って、あんたがやってみろって言ったくせに……。

　だいたい、これっていくつでしょう。兆（ちょう）の上の京（けい）のもっと上ですよね。
　調べてみると、『垓（がい）』をも突き抜けて、『穣（じょう）』の桁でした。

　792穣（じょう）2816𥝱（じょ）2514垓（がい）………。もういいっすね。もしかして銀河の星の数より多いのでは？
　現代のパソコンの発色数の最大値は『792穣（じょう）』色でした。

　X68000XVIの65,536色（16bitカラー）の1200兆倍以上の組み合わせができるカラーモードって……。それがクレヨンだったら地球何周するのか。
　ワタシの脳みそではもう追っつきませんので、ここはジェミーさんの登場です。
　すると、ジェミーさんはこうまとめました。

① 前提条件
　クレヨン1本の太さ：1cm（0.01m）
　色の数（32bpcの組み合わせ）： 79,228,162,514,264,337,593,543,950,336色（約792穣）
　地球1周の長さ： 約40,000km（4×10⁷m）

② クレヨンを並べた全長
7.92×10²⁸（色）×0.01（m）=7.92×10²⁶(m)

③ 地球の周回数に直す
7.92×10^²⁶（m）÷(4×10⁷)（m）= 19,807,040,628,566,084,398 周

何という数字!!
　約1,980京（けい）周するそうです。

「京ぃっ‼」
　3周ぐらいかと思ってたら……。
　スーパージェミーさんはまだ続けます。

④ 太陽までの距離（約1.5億km）ここにクレヨンを並べると。
　太陽まで 2,600兆回以上往復できます。

⑤ 銀河系の直径：約10万光年……（オイオイ）
　なんと、このクレヨンは天の川銀河の端から端までを約83万回往復できる長さになります。

これが現実でした……。

　ちょっと待ってください。ここにあるパソコンはそんな数の計算を 1フレームごとに計算していたのですか？

　実はつい先日、"32bpc" で、『1280×720』という小サイズでありながら 30秒の 3D動画のレンダリングに 6時間もかかっていて遅い！って怒っていたのですが、今の計算結果を知ってしまったら、土下座して謝罪したい気持ちでいっぱいになりました。

　でも、こんな宇宙規模の変態計算にもかかわらず、大変なことに気づくのですが、またまた。時間が来てしまいました。
　この続きは、また今度……。

　『変態を考える』は、まだ続くのぢゃ。（TωT）ﾌﾞﾋｰｯ

（タイトルが変わっとる……）

２０２６年１月２１日（水）１１℃（午後４時４０分）

人生、色とりどり……(1)

進む戻る

【まえがき】

「またなんか変なことを言い出した……」

　いや、そう言わずに、ひとまず落ち着いてください。
　人生が何色？　か、なんてことはどうでもいいんです。バラ色でも "どどめ" 色でも一向にかまいません。
　今回はパソコンの発色数に関する話です。
　なぜ、いまさらそんなことを書き出したのかというと、最近 "32bpc" で映像処理することに凝りだしたからです。
　『bpc』という単位は『Bit Per Channel』の略で、各色成分が何階調出せるかという意味になります。日本語では『色深度』ともいわれます。

　今度は「各色の成分ってなんだ？」てなりますよね。

　パソコンの画面になぜ写真を映すことができるのか、いまさら説明の必要はないと思いますが、光の三原色を利用して液晶ディスプレイを光らせています。光の三原色というのは『赤（Red）』『緑（Green）』『青（Blue）』です。一般的には英語の頭文字を取って『RGB』と書きます。

　液晶ディスプレイが一枚の発光板だと仮定して、『RGB』が個別に出せるとしたら、その板は『RGB』の組み合わせで、『赤・緑・青・黄・水色・紫・白』の 7色と、消えているときの『黒』も合わせて、8色が出せることになります。

　すごいですね。これがあれば人生 "虹色" ですよ。
　ま、虹は "7色ではない" と突っ込んでくる方もいると思いますので、あまりこだわるのはよして。

　これでは単に板状のフルカラーLEDとしてしか役に立たないので……あ、EL発光板ってどうなったんでしょう。昔、黄色の EL発光板を PICで点滅させて喜んでいた頃が懐かしいです……って、すぐ脱線するのがよくないですね。だからここを読むとくたびれるって、クレームが殺到するんです。

　反省……(;^ω^A

――で、1色の板では液晶であっても表示器にはならないので、この光る部分をものすごい数の粒にしたらどうなるか、そうですね……。横に1920個、縦に1080個ぐらい。全部で『207万3600』個の光の点が完成です。

「なんちゅう、中途半端な数字や」
　ですね。だいたいデジタルに登場する数値には変な数字が多いんです。『1KB（キロバイト）』バイトだって、実際は『1024』バイトだし。なんだこれ、ですね。

　なぜ、『1920×1080』という中途半端な数字になったのか、調べてみました。
　すると、二つの理由が絡み合っていることが判明しました。

　まず一つ目。
　昔の四角いテレビと、映画館の横長スクリーンの『ちょうど真ん中』を計算したら『16:9』になったという、妥協の産物。

　そして二つ目。
『16：9』でいくならこれがいい、と手を挙げたのがデジタルエンジニア。

『1920と1080』なら、『16：9』になるし、『1920』は 2進数に直すと『0111 1000 0000』。128の倍数で、かつ "2のn乗" で割り切りやすい、デジタルメモリーにとってもキリの良い数字なんです。幾何学的な美しさに、デジタル的な合理性を重ね合わせているからこれがいい……となったそうです。

　なんとなく眉毛の上あたりが "ピクピク" しますが、長くなるのでここはスルーしておきましょう。
　とにかく、これからのパソコンは 1920×1080ぐらいあったら大きくて『16：9』だからこれがいい。と決まったのですが、その話は "点が多いほうが細かいものが現せる" 、つまり解像度の問題です。じゃあ、何色出すとなります。

　人間の目が感知できる色数は『数百万』色ほどだそうです。略して 100万色のクレヨンですね、買ったら高そう。
　先ほど、画面を約 200万個の点に分けました。この点、1個に 100万色使えたらそりゃもう天然色満点ですが、そうは問屋が卸してくれません。1個で 8色出すとしても『RGB』の、3つのスイッチ（3ビット）が必要になりますので、

　200万個×3ビット＝600万ビット
　バイトに直すと 600万÷8＝750KB（キロバイト）。

　そこのあなた。「なんだ、1MBもないじゃないか」と思ったでしょ。

　かつて一世を風靡した PC8001のVRAM（グラフィックメモリー）は、たったの 3KB（アドレスは0xF300～0xFFB7）ほどしかありませんでした。それを1画面で 250倍の 750KBっ！
「お前は石油王かっ！」ってどやされますよ。

　8色でそれですから 100万色なんて、そんなのは夢の夢の、またまた夢の先の幻の話です。
　ちなみにやっと出てきました。画面最小の点、1個に『RGB』のスイッチを 3個使って 8色出すこの最低限の機能。このことを専門用語で "1bpc" と書きます。色は『RGB』で対になっているからこれが最小です。

　その最小の制御でさえ、PC8001では実現できなかったのです。ドット単位での発色は不可能で、今でも残る悪夢 "1行120バイトの怪……もとい、アトリビュート方式という『色の予約席』システム" です。

　オレンジ色を出したいのに、パレットにない。この意味わかりますか？
　オレンジ色は『赤』とそれより少し弱い『緑』を混ぜる必要があります。でも "1bpc" は、点けるか、消すしかできませんので、『赤』と『緑』を点けて『黄』色にするか、後は　あきらめるしかない……。

「あきらめるって、あほな……」
　もっと恐ろしいことをお伝えしましょう。

　カラーグラフィック可能、と謳ってますが、1ドットに対して 8色だとはいっていません。8×8ドットの『キャラクタ』単位でしか色を指定できなかったんです。今のパソコンが 1ピクセル単位で制御するのに対し、PC-8001の "1bpc" は、"1 Bit Per Character" なんです。でっかいハンコみたいなものを並べるようでした。そのハンコ大のピクセル（と書いていいのか……）でなら 8色が出ました。

　それでも白と黒だけの世界しか知らなかった当時のエンジニアは、カラーという言葉に夢を持っていたので、あきらめませんでした。赤と黄色の四角いハンコを市松模様に並べたものを遠くのほうから目を細めて見つめ、『……うん、オレンジに見える！』って自分に言い聞かせていた、あの執念、今思えばすごいですよね。脳内で補完してやっと『オレンジ色』ですから、すごい時代だったのです。

ジェミーさんが描いたレトロパソコン

"gemni" はジェミーさんのハンドルネームだそうです

しかし神様は見捨てませんでした。次に登場したのが、我らが救世主。マンハッタンスタイルの『X68000XVI』さま。
　なんとこのマシン、1ピクセルに 16ビットも割り当てられました。

　1チャンネル（RGBのどれか 1色）につき 5ビット＋輝度1ビット。さっきの専門用語でいえば "5bpc" 相当ですが、出せる色は 2の5乗=32が RGBで、 32×32×32= 32,768に輝度1ビットがあるのでその倍、65,536色！
　当時の最高機種だった PC98でさえまだ "16色の壁" にぶち当たっていたのに、画面のどこにでも、1ドット単位で好きな色が置けるこの世界。それはまさに『王者の風格』でした。

　実写のようなグラデーションが、目の前のブラウン管に映し出された瞬間の震えるような感動。あの時、ワタシは「もうこれ以上の進化はいらない」と本気で思ったものでした。

35年という年月が流れても "いいものは、いい"（このX68Kは私物です）

　――案の定、"32bpc" までたどり着けませんでした。

　まだまだ続くのぢゃ。（TωT）ﾌﾞﾋｰｯ

２０２６年１月１３日（火）１１.５℃（午前１４時２０分）

そろそろやばい…….

進む戻る

仕事場のパソコンには外付けのHDDが3台ぶら下がっているのですが、そのうちの1台が最近頻繁にエラーを吐き出すようになってきて、このあいだは過去に作った動画を見ていると突然画像が停止。でも音声だけは流れていて、何とかつじつまを合わせようと映像が飛び飛びに追いつくのですが、そのうちぱたりと止まってしまい、音声だけが流れるという異常事態に。

　はたと思いつきましたね。これはそろそろヤバい前兆だと。余命わずかの末期的な症状ではないかと、保存してある最古のファイルの作成日時を見ると "2016年" で、更新日時はさらに半年ほど過去。
　この HDDはバックアップ用としか使っていませんので、このファイルは最終更新日時から半年後に、ほかの HDDから移動してきたのが "2016年" ということになります。

　それから 10年……。

　まだ動いてはいますが、いつ逝くか、まるで時限爆弾です。そこで、重要ファイルだけを新規参入して 2年ほどの若い HDD（ワタシは駆動初日の日時をハードディスクの名前に追加しています）へ引っ越しをさせました。

　世間一般での常識では HDDの寿命は 4年ぐらいといわれています。なので、10年は長寿だったといってもいいかもしれませんが、まあ、ワタシの脳みその一部が保管されているような HDDですので、その扱いは丁寧でした。
　まず、バックアップの必要が無いときは電源を入れない。むやみに細切れなアクセスはしない。無駄なアクセスを回避するようにデフラグも定期的に行っていました。
　ようするに無理させずにそっと使ってきたから 10年という年月に耐えられたのかもしれませんね。

　ハードディスクの内部では、磁気円盤（プラッタ）が高速回転しています。この円盤の上には、レコード盤のような同心円状の "トラック" と呼ばれる道みたいなものがあって、そのトラックをさらに細かく区切った "セクター" と呼ばれる最小単位の小さな部屋が並んでいます。

　ただ、セクター単位では細かすぎて管理が大変ですので、OSではそれをいくつかひとまとめにした "クラスタ" というグループを単位にしてデータを扱っています。そこへ磁気ヘッドが素早く飛んで行ってデータを読み書きするという仕組みはご存じだと思いますが、この磁気ヘッドと円盤の回転のコンビネーションで HDDの速度とメカニカルな部分の寿命が変化するといっても、間違ってはいないと思います。

　唐突ですが。
　HDDの中身は細切れのウドンが漂っている。

「あー。こいつ、ついにおかしくなりやがったな……」

　ご心配なく。ワタシの脳みそは今日も快適に活動しております。
　この細切れの "ウドン" がクラスタと呼ばれるもので、すべてに通し番号が付いています。そして管理台帳なるものが、磁気円盤の決まった場所（通常はパーティションの先頭付近）に、Master File Table（MFT）として書き込まれています。

　この台帳には、次に食べるべき "ウドン" の番号が記録されていて、たとえウドンがぐちゃぐちゃにかき混ぜられようとも、番号どおりに読んでいけば、内容が復元されるような仕組みになっています。
　しかし、その番号が遠く離れた "ウドン" になるとそこまで磁気ヘッドが飛んでいくのにわずかなりとも時間が掛かります。だからなるべく細切れ "ウドン" は順番に並んでいた方が効率はいいし、メカニカルな動きも少なくて済むので、故障率も下がります。

　しかし、これを考えた人は天才ですよね。
　例えば、ファイルは不変ではなく常に一部が削除されたり追加されたり、そのたびに一つのファイルの長さが変化します。そうなると、順番通りに並んでいた。細切れ "ウドン" がバラバラに離れてあちこちに散らばってしまいますが、番号順にアクセスすればデータは読み書きできるんです。

　ただ、あまりばらけると先ほど書きました、無駄なアクセスや時間が発生しますので、一旦、ばらけた "ウドン" をもう一度整列させる作業があると便利です。それが "デフラグ" です。

　まだ寿命がきて使えなくなったところまでは至ってませんが、すべての重要データを新しい "約束の地（新 HDD）" へと脱出させたあとは、この 10年戦い抜いた老兵に、安らかな、かつ絶対的な眠りについてもらう "聖なる封印" を施してあげるのが、ワタシの努めでもありますね。

　壊れたから、ぽいっとゴミの日に……。なんて恐ろしい。ワタシの脳の一部（脳で拵えたデータ）が入っていたんですから、誰かに拾われて悪用されたら大ごと（おおげさ～）です。

　というか、うかつに扱うのは厳禁です。最低でも、全セクターに対して、『00』や『FF』、あるいはランダムな数値を書き込んで完全消去するのが、個人情報漏洩を防ぐ意味でも行うべきです。

　その方法です。（一歩間違うと致命的などえらいことになりますので、個人の責任において実行してください）
① コマンドプロンプトを管理者として実行。
② C:\Windows\System32>　と出ていることを確認。
③ format F: /fs:NTFS /p:1　と入力。
　 p:1は、全領域を『00』で埋めたあと、さらにもう 1回、『00』以外の数値で念入りに上書きされます。
　 pオプションが無ければ『00』で埋めるだけ。

《注意》
上記の『F:』は例です。実際は消去するドライブ番号になりますが、もし間違えたら、使用中の重要な HDDを即死させることになります。ここは細心の注意が必要ですので、エクスプローラーで、消去したい HDDが本当に正しいか、何度も確認してください。

④ "y" と入力して enterキーを押すと開始されます。
⑤ かなり時間が掛かるはずですが、終了したら「exit」と入力し、Enterキーを押してコマンドプロンプトを閉じて終わり。

　ワタシの場合は、もっと徹底しています。
　何しろ苦労して作ったノウハウが詰まっていた伝説のHDDですから、二度と悪用されないよう地中深くの聖域に納めるべく、まず、ドリルという名の聖剣で迷宮の入口ともなっている磁気円盤（プラッタ）のど真ん中を貫きます。これでどんな魔法使い（復元ソフト）も中に入ることはできません。

　さらに、アクリルカッターで内部のコントロール基板を走っているパターンを切り刻みます。魔力の供給路を断ち、完全に沈黙させるのです。フラットパッケージの ICだって容赦なく "べろりんちょ" です。
　最後の仕上げに数日間、聖水（ただの水道水・雨水も可能）に浸けます。これで封印は完成！

"お疲れ様。君の中にあったワタシの記憶は、ちゃんと次の世代（HDD）に引き継いだぞ" と、10年間の感謝を込めて、日本酒で別れの宴です。

「何で、ここだけ日本酒やねん！」

　それは単にワタシが日本酒党だからです。

　うははははは。　　 (￣ω￣;) ｱﾎﾔ～

２０２６年１月６日（火）１２.５℃（午前１０時４０分）

2026年。明けましておめでとうございます…….

戻る

といいつつも……。

　元旦の朝から 38度近い発熱で、早朝の仕事ができず、朝 8時にやっと起き出し、ビールと日本酒で乾杯を済ませたあと、ちょっとテレビを見てから、再び寝床に戻り、昼過ぎに目覚めて、またビールをコップ一杯ひっかけてテレビを見ながら寝込むという、普通の正月と変わらないじゃないか、と思われそうですが、ワタシにしてはだいぶ違っています。

　まず、早朝の仕事……。

　別に朝刊を配っているのでも、お豆腐屋さんの裏方でもありません。時間に関係なく常にパソコンに向かっているのは、"RPGの魔王城の前で平然と道具屋を営む親父" と同じです。そこが定位置なのです。

正月でもやってんのかよ！

　という突っ込みありがとうございます。

　――やってますが……なにか？

　今年は農閑期（←ここ笑うとこ）で、ずいぶんと暇でしたが、ここ数年分の過去ログを覗いてみてください。ほとんど正月から仕事が終わらないと愚痴を書いているか、正月もとっくに過ぎたころに『明けましておめでとう』と間抜けな冬眠明けのカエルみたいなことを書いてますから。熱を出して一日中パソコンに灯がともらなかったことは 365日に一度だけです。

　あまり自慢できる話ではありませんでした……。

　とにかくまともなことを正月から書かないのは、このサイトでいえば "正月の伝統芸能" のようなものですから。

ということで。今年もよろしくお願い申し上げます。
　　 (￣‥￣) ｹﾞｺｯ

お品書き…

パースガイド作成ツール（その 5/6）[むむむの XPresso]後編

パースガイド作成ツール（その 4/6）[思わずうなる XPresso] 前編

パースガイド作成ツール（その 3/6）[組み立て] 編

パースガイド作成ツール（その 2/6）[部品作り] 編

パースガイド作成ツール（その 1/6）[3Dに必須のパースマップを作る]

運び屋ヌル登場……

Cinema 4D Liteと AEとの連携（ちょっとレベルアップ）

3D作業の負担を少しでも軽くするには（省エネならぬ省データ対策）

これもいわゆる一つの次元的思考

クソゲーメーカーが贈る 【リブート・オブ・ワンダーランド！】

春の足音はすぐそこに

消失した秋の思い出

怖いぞ AI依存症（その２/２）

怖いぞ AI依存症（その１/２）

怖いぞ SNS依存症

すごいぞ IOWN

人生、色とりどり……(3) 最終回

人生、色とりどり……(2)

人生、色とりどり……(1)

そろそろやばい…….

2026年。明けましておめでとうございます…….

　パースガイド作成ツール（その 5/6）[むむむの XPresso]後編

　パースガイド作成ツール（その 4/6）[思わずうなる XPresso] 前編

　パースガイド作成ツール（その 3/6）[組み立て] 編

　パースガイド作成ツール（その 2/6）[部品作り] 編

　パースガイド作成ツール（その 1/6）[3Dに必須のパースマップを作る]

　運び屋ヌル登場……

　Cinema 4D Liteと AEとの連携（ちょっとレベルアップ）

　3D作業の負担を少しでも軽くするには（省エネならぬ省データ対策）

　これもいわゆる一つの次元的思考

　クソゲーメーカーが贈る【リブート・オブ・ワンダーランド！】

　春の足音はすぐそこに

　消失した秋の思い出

　怖いぞ AI依存症（その２/２）

　怖いぞ AI依存症（その１/２）

　怖いぞ SNS依存症

　すごいぞ IOWN