日々適当

こんな感じで三つのオブジェクトObjA, ObjB, ObjCが同じ階層にいます。そいで、これらをParentコマンドでBの子供にCをAの子供にBを設定します。設定した結果が下。

この時注目したいのは位置情報が階層構造を作る前と変化ないこと。だからワールドの座標系で表示されているかと思いきや、一番親のObjAを動かしてもObjB、ObjCの情報に変化は生じません。ここの数値は何もしないと親子関係を作った時のワールド座標って事みたいです。なので（個人的には）これは全く役に立たない情報に思えます。だからObjB、ObjCのRelationsの中のParent TypeをObjectにしてやると親の座標系の数値に変わるのでそう設定したいのですけど、それに変更した瞬間、ObjBとObjCの位置は、親子関係を作った時のワールド座標の数値をローカル座標系の数値として取り扱いやがります。つまり、位置が吹っ飛ぶ。

これを回避するためのスクリプトを考えるわけですが、スケールが絡まなければ大変にシンプルで、子供を選択して以下のスクリプトを実行するだけで良いようです。

import bpy
childObj = bpy.context.selected_objects[0]
matrixWorld = childObj.matrix_world
childObj.parent_type = "OBJECT"
childObj.matrix_world = matrixWorld

ワールド座標系内での変換を保持しておいて、Parent TypeをObjectに変更した後にその値に戻してやる、って考え方。関連するオブジェクトのスケールが1ならこれで問題なく動作するようです。こいつを簡単に呼び出せるようにしておけば、当面の用は足りるかね。

ちなみに matrix_world でワールド座標系のマトリクスを扱ってますけど、ローカル座標系のそれは matrix_local でよろしいそうです。

なを、座標変換では変換行列を乗算する事が多いわけですけど、Python 3.5以降ではそれは@演算子なのだそうで、3.7.7が動いているらしいBlender 2.91.0では当然それが使えて、 matrixWorld@matrixWorld.inversed() とかやるとワールドの原点に行ってくれたりします。変換部分を勉強すればこの辺の知識が役に立ってくるはずなのだけど、とりあえず知識がないのものでスケール問題に対処できません。困ったものです。

やや旧聞に属する話題ですけどプリウスαが終わるみたいです。公式ページでもそう案内しているわけで個人的にはちょっと残念に思っている次第。
まぁそれはプリウスαオーナーだったし結構気に入っていたからなのですけど、このプリウスαの何が良かったのかというと後部座席の広さがとても良いなと思っていたわけです。
現行機の数字ですけど全長4645mm、全幅1775mm、ホイールベースが2780mmです。うちにあったモデルは内装こそチープだったけど、本当にゆったりした広さで感心したものでした。車高をちょっと低くしてもらいそれ以外のサイズ感を保って現在の技術に置き換えられた新型を期待していたんですけどねぇ（屋根の高さはちょっと高すぎると思ってた）

プリウスαの役目が終了しその役目を次に譲るものの一つがカローラツーリングだと思われますが、こちら、全長4495mm、全幅1745mm、ホイールベース2640mmです。ホイールベースは10cm以上短く、世間の評価としても後席は狭いです。ちなみにコンパクトカーに分類されるカローラスポーツは全長4375mm、全幅1790mm、ホイールベース2640mmです。つまり、カローラツーリングは居住性という観点からはスポーツと大差ないし、実際に乗っている人たちもそんな感想を持つようですね。
そして現在自分が乗っているオーリスですけど、全長4330mm、全幅1760mm、ホイールベース2600mmでして、まぁまぁ広さはスポーツにしようがツーリングにしようが大差ない。
ところで日本のカローラは日本独自のボディデザインになってて、ヨーロッパモデルのカローラツーリングスポーツとはデザインが異なってます。ヨーロッパモデルは全長4670mm、全幅1805mm、ホイールベース2700mmで日本モデルより大きいです。なぜに日本モデルはホイールベースまで縮めたとちょっと恨めしく思うところです。

ってことで、ヨーロッパモデルをオーリスツーリングって名前で売りませんかね？全幅がちょっと広くなって個人的には使いづらくなる事が予想されるけど、そこは我慢するので。

車といえば、Appleが来年にも発売するなんて噂が出てきました（発表だけかな？）。エンジン車と比べ電気自動車は従来の自動車メーカー以外の参入が簡単になるなんて言われておりましたが、個人的にはこれは少し眉唾だと思ってて、エンジン以外の部分にも自動車メーカーのノウハウは完成度の高いものを作ろうとするとき非常に大きく効いてくるだろうから、Appleがハードウェアの部分をどこまで仕上げてくるのかにはあまり期待していません。まぁでも楽しみではあるので、買う買わないの選択肢の外で発売を楽しみにしております。（多分価格も購買対象にはなりえないだろうねぇ。）

やや旧聞に属する話題だけど、

EIZO、モニターの接続台数やカラーフォーマットの階調飛びなどApple M1チップ搭載のMacとPCモニターで確認された制約事項と互換性情報を公開。[AAPL Ch.]

というお話が気になりました。モニター台数はそもそもAppleが仕様として発表していることだからいいとして、カラーフォーマット、カラープロファイルに制限があるようです。

YUVリミテッドレンジで映像出力されるため階調がフルレンジと比べると少なく階調が飛ぶことがあるという症状。元々MacのHDMI出力がそーいう仕様だけど、M1はHDMIに限らずそーなるということです。（モニタの入力とモニタへの出力の設定があっているならほとんどの場合問題になることはないはずですが）

確かに、自宅 Mac mini M1 2020 で確認してみると、接続したディスプレイにはYPbPrで入力されていると表示されますし、YUVで出力されているということなのでしょう。フルかリミテッドかはディスプレイのパネル情報からはわかりませんが、黒が浮いているとかは感じないので、大丈夫かな。Displayportってフルかリミテッドかって情報も送ってるのかね？

ちなみに同じモニタにつなげている Mac mini 2018 だとRGBで入力されていると表示され、YPbPrにすると色がおかしくなります。こっちはRGBで出力されているわけっすね。
そーいえば、システムレポートのグラフィックス/ディスプレイの項目でフレームバッファの深度ってパラメータがM1 Mac miniには表示されてません。ここに何ビットカラーって値が出てくるわけですけど、AppleはM1については表示しない設定をしているのかな。隠したい情報ってことなのでしょうか？

そんな意味で、まだまだ「プロ」向けにはリリースできる段階ではないと考えているのかもしれず、それゆえの11月後半に「Intel Macを今後も出荷する予定」と語ったのかなと思わされました。Mac Pro, iMac Pro, グレーのMac mini, MacBook Pro あたりから Intel CPUを積んだ新モデルが出てくるのかね？

ラトックシステムから出ているBluetoothで情報を送ってくれるワットチェッカーを購入しました。

Bluetoothワットチェッカー RS-BTWATTCH2 [RATOC]

目的は別にあるんだけど、とりあえずUPSの根元に挟んで計測してみたですよ。

ちなみにそれを挟み込む際にUPSの電源コネクタをコンセントから外したのですけど、UPSに繋がっていた機器は無事に動作し続けました。うっかりだったのはディスプレイを繋ぐのを忘れてて、ディスプレイ経由で繋がっていたHDDが不正に取り外されてしまったことでしょうか。そのHDDも通電させたら無事動いているようなので、まぁいいです。

さて、このUPSにはMac mini 2018（with eGPU (Vega 56)）とMac mini M1 2020が繋がってます。特に何もしていない時、140〜150W程の消費電力になっているようです。（お互い起動していて、ディスプレも稼働してて5発のHDDが入るケースも繋がってます）

この状態でCompressorでH264変換した時、Mac mini 2018では220Wほどまで上昇しました（160W〜220Wの範囲ぐらい）。一方、Mac mini M1 2020でエンコード中は振り幅が大きく、143Wあたりから200W強程の範囲で推移しましたが、多くの時間は150Wあたりでウロウロしてましたかね。

複数機会が動いている根本での計測で、Mac mini 2018の方ではバックグラウンドで色々動いているからその影響も大きいのでしょうが、M1の方が省電力ってのは改めて確認できたように思います。（もっとも、Mac mini本体というよりeGPUや外付けHDDの商品電力が大きいのだろうなぁとは思う…）

こちらのワットチェッカー。ずっと動かしていたらずっと結果を溜め込んでくれるみたいで、

こんな感じでグラフにして表示してくれます。夜間電源入れっぱなしで放置するとこんな感じで電力消費しているんすな、ってことが視認できて面白いですね。

<追記>iPadでデータ見ようとペアリングし直すために電源ボタン長押ししたら押し方間違えたのかそーいう仕様なのか接続してた機械の電源が落ちました。ペアリングは接続機器の電源を落としから行いましょう。</追記>

先日のAmazonのブラックフライデー＆サイバーマンデーにて、CyberPowerのUPS CPJ1200[Amazon]が安売りされていたので、ついに購入しました。（普段だいたい2.7万弱で売られているところ、20830円と6千円ほどお得に買えた。もっともAmazon以外では常時その価格で売っているお店もあるみたい。）

メインマシン周りである、Mac mini, eGPU, HDDを繋ぐために購入を考えてて、最近そこにMac mini M1 2020が加わりました。元々APCのを導入しようかなと思っていたのですが、より安いお値段で高出力のものを買えるということで、まぁ、業務で使うクリティカルなものじゃないし？ってことで選んだ次第。

CPJ1200[CtberPower] はラインインタラクティブな給電方式を採用してて容量は720Wということで比較的大きめで、数字的には安心感があります。停電になったときにどのような挙動を示しマシンにどんな影響が出るかは実際にそうなったときに判断しましょう（テストしてみようとはあまり思っていない…）

ちなみに、本来はMac mini 2018側にCPJ1200からのUSBケーブルを繋ぐべきなのですが、USBポートが埋まっている関係上、とりあえずMac mini M1 2020の方につないてみております。
macOS標準でUPSは認識して最低限の動作をするようになっているために、接続するとシステム環境設定→省エネルギーにUPSタブが追加され、問題が起こった時の挙動を設定することができます。これは素晴らしいのですが、ちゃんと動作するかはまた別問題で、でも前述した通りあまりテストする気にならないので、とりあえず確認作業は放置です。

Mac mini 2018側のUSBポート接続機器を整理して、そっちにUPSを繋ぐまでは近日中に行いましょう。

ところでUPSに2台のMacを繋いでいることになるわけですが、USBは片方としか通信できないわけで、停電した時、両方の電源を落とせるようにはできないのかな？（オムロンとかAPCのは専用ユーティリティを介して可能みたいだけど。CyberPowerも配布しているソフトの少なくともBusiness Editionってのなら対応しているらしい。）

<追記>2021年8月23日 ついに停電に遭遇しました。無事、稼働中のMac miniと繋いでいたeGPU、外付けHDDはそのまま動作。ただし、うっかりとしていたのはディスプレイとKVMを繋ぎ忘れていたことで、操作ができなくなりましたですよ。家の中のLANも死ぬのでリモートでの操作もできなくなりますしね。実際に遭遇しないと不備に気づかないものです。</追記>

Blender 2.91.0が登場し、スプラッシュスクリーンに表示される画像のシーンが配布されてます。
Art Gallery[Blender Cloud]

このシーン、レンダラにEeveeを使っててビューポートである程度の結果を確認できるのですが、eGPUとしてVega 56を繋いだMac mini 2018とMac mini M1 2020では表示結果が違うのが気になるところです。

上がMac mini 2018、下がMac mini M1 2020。

ちなみにMac mini 2018の方は、落としてきたファイルを開くと、最初下草が生えていませんでした。草はパーティクルで生やしていたのですが、そのモディファイヤが有効になっていない状態で読み込まれた模様。オンオフしたら表示されるようになりました。

もっとも、どちらも最終的なレンダリングイメージとは結果が違うんですけどね。もちろん、ちゃんとレンダリングすれば、どちらもほぼ同じ結果が得られます（下図）。

ちなみにレンダリング時間はMac mini 2018 with eGPU(Vega 56)が13秒弱だったのに対しMac mini M1 2020は21秒強でした。GPUパワーは圧倒的に足らない、って印象ですね。
それはビューポートをぐりぐり回すときにも感じられて、M1の方にはどうしても重いって印象を持ってしまう速度でした。
これはGPUを使ったレンダリングだからM1が不利なのかなと思いましたけど、（Mac版はGPUを使用できないために）CPUを使うレンダラであるCyclesを利用するシーン[Blender Cloud]でもMac mini M1 2020に比べてMac mini 2018の方が83%短い時間で計算を終えました。Cyclesの方は或いはメモリ不足のため遅くなったってことはあり得ますかね。

まあM1の方のBlenderはRosettaで動いているわけで、M1にしてみれば不当な評価という事になってしまいましょうか？ 逆に言えば、Rosettaを介してでさえこの速度差程度におさまるのだから、M1すごいとも言えますか？

余談ながら、演算中はeGPUのファンが結構回るわけで、静かさという意味ではMac mini M1 2020が圧勝です。

M1チップ搭載Mac上で仮想化したARM版Windows 10の動作映像 | [気になる、記になる…]

MSがライセンスさえ出せばWindowsをM1 Macで動作させる道は開けそうだし、ARM版Windowsではx86アプリの動作をサポートしているようなので（Softimageを起動させるのは無理かもだけど）まぁまぁ使い物になるんじゃないかって期待できるわけです。
またLinuxもWindowsと同様 QEMU上で動作させることに成功したって報告が上がっているようで、

M1搭載Mac、Linuxも動作成功。Arm版Windowsも基本機能のほぼ全てが実現 [Engadget 日本版]

こっち方面の未来はまあまあ明るそうです。

個人的に問題だと思っているのは、バーチャルマシンでの動作をライセンス上開放されたLionからCatalinaまでのmacOSの対応についてです。M1 Macで動作させることは無理なんじゃないかって思うわけです。
現在、諸般の事情によりMavericksとSierraをParallels Desktop上で使っているのですが、そこで利用しているアプリはCatalinaでは動作が怪しいからそうしているわけです。代替のツールを探すべきなのでしょうが、如何せん面倒臭い。遅くてもいいので、macOS（Mac OS X）のバーチャルマシンでの動作が実現することを期待したいものです。