2023年1月12日木曜日

インボイス制度開始。消費税免税事業者が課税事業者になった場合。

2023年も年が明けて、個人事業主の皆さんはそろそろ確定申告の準備を始めた頃であろう。
個人事業主の方は同時に2023年10月に開始されるインボイス制度もうっすらと気になり始めていると思われる。

確定申告をe-Tax確定申告作成コーナーで作成している方だと、作成するメニューの中に「消費税」の項目があるので、試しに2022年分データを元に消費税を試算された方もおられるのではないだろうか。

私も試算してみたが、その額に腰を抜かしてしまった^^
インボイス制度に合わせて課税事業者になる場合は、2023年10月からになるので、初年度は3ヶ月分ですむが、それでも「こんなに行くのか」と驚かれるかも知れない。
そして次の年からはフルに一年分になるため、単純計算2023年分の約4倍くらいになるのである。。。

インボイス制度をよくよく考えてみると当然かもしれないが、かなり簡単に言うと要は売り上げの10%分は一時的に預かっていただけなので、その分を課税事業者として国&地方自治体に納め直さなければならない。といったところだろう。
(仕入れがある事業をされている方は、上記から仕入れ等に含まれる消費税分を差し引く。正確には課税売上に係る消費税額から課税仕入れ等に係る消費税額を差し引いた額というのかな?)
(あと一応、言うまでもないかも知れないが軽減税率対象の売上・仕入れ物品であれば8%。以下同様。)

売り上げが1,000万円未満でこれまで免税事業者だったが、インボイス制度で課税事業者になることを選んだ場合は、「新しく税金が発生した」と思われるかもしれないが、あくまでもこれまでは免税の恩恵にあやかってこれた、ともいえよう。

免税分を「あて」にしてこられた方は、考え方を改めて、売り上げの10%(マイナス仕入れ等の額の10%分)は「後から収める分なので手をつけてはいけない」と思い直さなければならない。

※しかし「免税」と言うことも考え直すと、中小企業救済の意味合いもあったかもしれないので、インボイス制度開始に伴って「免税」対象から外れてしまう人を一時的でも段階的でも救済する制度は特にないのだろうか?(なんだか「あてにしてた方が悪い」と言われてるような気もする^^ 浮かれさせておいて階段を外すような、というか。。^^)

ーーー
さらにそもそも話になると、所得税も前年一年分の「所得」に対して、儲かった場合は税金取りますよ、と言うものであって「後から課税しますよ」方式である。
※現代の金融・経済システムでは全てをリアルタイムで行うことはできないので仕方がない。ちなみに私はこの問題点を含め、現代経済の諸問題を解決するリアルタイム経済を考察済みである^^よかったら下記参照。

このネオ・アナログ経済が実現すれば、今回の命題であるインボイス制度(消費税)とか所得税とかの問題も一気に解消できる、と言うかそう言う話が出てくる隙がなくなるのだが、まぁそれは次世代に期待するしかなさそうである。。

ーーー
要点としては「後から課税しますよ」方式ではどうしても生じてしまう問題であって、殊に消費税は税率もそれなりに高くて、こういった制度見直し時に問題点が嫌でも浮き彫りになって表面に現れてしまう、といったところであろうか。

しかし一方で世の中には「現金主義」と言うか単式帳簿というか、「もうもらったカネなんだから後から税金を取るとかいうな!なんでその時に取っておかなかったんだ!」的な人もいる訳で、そこまで考えると国とかグローバルな経済(日本国もそれに操られてはいやしまいか?^^;)は、全員にクレジット方式というか複式帳簿的な生活・考え方を強要しようしているのではないだろうか?とさえ思えてしまうのである。

もちろんクレジット方式の方が断然カネは回しやすくなるのだが、必ず最後は「実体」に行き着く訳で、実体とは誰かのその日の現金だったり、将来の「取り分」(見込み)だったりする訳である。
果たしてどこまでクレジットを膨らませたいのだろう?(そしてそこまで膨らまさせて一体何をしたいのだろう?)

ーーー
最後は脱線したが、今回のインボイス制度は国(というか財務官僚?^^;本当のカネの力😅)はこの免税分に本腰を入れて切り込んだようにも見受けられる。
よく言えば「バランスをとる」ということかも知れないが、最近は働き方が変わって先例も多く出てきて結構多くの人が個人事業主になってきて増えてきて、そういった人たちが免税とか「特権」的(に見える)なもので「おいしい思い」をするのを牽制する意味合いもあるのだろうか?
(簡単に言うと「取りこぼし分が巨大になってきたので、穴を塞ぐ」と言うことだけかも知れないが。。)

意図はいくらでも推測(邪推?)はできるが、制度として決まった以上は、一個人事業主としてはこれまでの免税をありがたく思い、これからは課税事業者になりますね、といったところだろうか。
ただ一点だけ、消費税の10%と言う額が額なだけに、免税という浮かれる仕組みを用意しておきながら、みんなが登り切ったのを見据えて階段を外すようなことは今後はして欲しくない、とだけ思った😅 (これを何年越しとかで意図を悟られずに計画・準備・実施しているのだから官僚とは確かに頭が良いものである。。)

ーーー
更に付け加えておくと、そもそも消費税は「本質的なのか?」と思った。消費するモノ・言うなれば消費活動に税金がかかるということだろう。
現在の仕組みでは消費するモノに税金が乗っかってしまっているので、今回のインボイス制度導入による課税免除という優遇処置が解消されてしまう問題とか、会計処理時に税込み経理方式にするのか、税抜き経理方式にするのかとか、仮払い消費税という勘定科目をつくって対応したりとか、8%分と10%分を分けたりとか、ものすごく複雑な仕組みになってしまっているのである。
(以前にどこかでも書いたが、こういった企業側の負担まで含めて経済のトータルで本当に考えているのか?といったところ。頭が良いのなら、なぜそこまでちゃんと考えないのかいつも不思議である。一言で言うと「地に足が付いてるか」の問題ということだろうが。)

日本だけこの消費税という複雑怪奇な仕組みを運用しているのであれば「日本は何やってるんだ?」と思うだけで済むのであるが、やはり世界的にもVAT(Value Added Tax。付加価値税と訳すらしい)があるわけで、世界中の会計システムでこの複雑な仕組みを運用しているのかと思うと、若干意外な気もしてくる。
日本はご存知の通り律儀なので、仕組みとして決まったことはきっちりと正確に運用していくわけであるが、失礼ながら日本にも大雑把な人もいたり、世界中にも大雑把な人はいるわけで、それら全てを「企業努力」に依存してVATの仕組みを張り巡らせたわけであるから、やはりカネの力とは恐ろしいものだ^^

もちろんVATの仕組みが、将来的に他の仕組みにも応答できたり、他の仕組みのベースになり得るとかであれば、将来を見据えたシステム開発でなんとか納得もできるが、最初に書いた通りVATとは「本質的なのか?」ということ。
もちろんキャッシュでのやり取りは第三者からは直接的には追えないので、モノに税を上乗せしておくという発想になるのだろうが、本質は「消費行動への課税」のはずである。
片やグローバル的にクレジットを推進しているわけであるが、その点とベクトルがずれている、と見受けられる。(鋭すぎ?)
クレジットを推進しているのであれば別に所得税と同様に後から足し引きした合計金額から税金を計算すれば良いだけであろう。
どうもトータルでものを考えずに局所的・短絡的に「取れる所から取ろう」という頭でいると、こういった壮大な無駄な仕組みを生んでしまうのである。というのはちょっと辛辣すぎる、切れ味の良すぎる図星すぎる指摘となるだろうか?😅

ーーー
消費者視点で見てみても、理屈上は同じであって買い物をする度に10%上乗せして支払うか、または一年分の消費額の10%を計算して払うかであり、その額はもちろん一致する。
現在の消費税10%で考えると一年分の消費税は当然結構な額になるわけであるが、買い物のたびに払った場合でも合計すれば同じ金額である。
消費者に「消費税を作ったので一年分を毎年一回払ってね」というとものすごいブーイングの嵐にあって法案が通らないので、もしも角が立たないようにするがためにモノ1つ1つに税を上乗せする現在の仕組みにしたのであればそれはそれで消費者を見下しているとも見受けられるのである😅 (一年分トータルだとだめだけど、モノ一つ一つに個別であれば、なぜか消費者は納得させられてしまうという構図。。)

ーーー
もうちょっと実際上の話にしてみると、残念ながら日本はグローバルに「追随」する国なので、(暗にグローバルからの圧力があるのかもしれないが)VATと同じ考え方に「するしかなかった」とでも言えようか。
繰り返しになるが日本ではかなり「正確に」世の中が回っていて、会計で言えば大半が(辻褄合わせをせずに)一円のズレもなく運用されているはずである。その点を考慮すれば日本では別に一年分トータル方式も成立すると思うが、おそらくそういった「消費行動に対する課税という本質的な」観点からは何も考えていなかったのではないだろうか?
これは完全に邪推になってしまうが、日本にルールさえ渡せば日本は完璧な仕組みと完璧な運用を勝手に実現してくれるので、先例となるシステムを「作らされている」と思えなくもないのである😅 (おそらくそんなことを頭の片隅で考えた人は、実はかなりの人がいると思われる。。)
さらに実際上の話にすると、もしも日本が本気を出して相互信頼が成り立っている環境を前提に、一年分トータル方式の消費行動税を作ったとしたら、それを作ろうとしている意図をグローバルが察知した瞬間に計画を白紙に戻すように暗に明に圧力をかけられて、日本は大人しく従うしかないという構図が思い浮かぶのである。。 (これも多くの人がとっくの昔から思っていることだろう。)

2023年1月6日金曜日

UNIXコマンド 任意のリターンコード(終了コード)を返すコマンド: rrc

シェルスクリプトなどで、子プロセスのリターンコード(終了コード, return code, exit code)によって処理を振り分けている場合、子プロセスに意図したリターンコードを返してもらいたい時がある。

その時は、「rrc」(return return code)コマンドが便利



簡単に使い方を書いておく。
例1:
$ rrc
引数なしで実行した場合はリターンコードは 0。リターンコードは「$?」変数で確認可能。
$ echo $?
0

例2:
$ rrc 1
$ echo $?
1
引数に返して欲しいリターンコードの数字を指定すれば、それを返してくれる。
注意点としては、rrcの内部的には「atoi()」関数を使用しているので、数字以外の文字を指定した場合や、最大値/最小値を超える数値を指定した場合は、atoi()の仕様に準拠することになる。

例3:
$ rrc -1
$ echo $?
-1

$ rrc 1024
$ echo $?
1024
rrcコマンド自体は、-1とか1024とかもリターンコードとして返してくれるが、UNIX的にはexit codeは0〜255となっている。

正確には親プロセスで exit(3) Library Function (及びそれに含まれるマクロなど)を使用して子プロセスを待機する場合は、exit codeは0〜255となる。
具体的には、WEXITSTATUSマクロでリターンコードを取得すると0〜255となる。
wait.h

...
#define WEXITSTATUS(x)  ((_W_INT(x) >> 8) & 0x000000ff)
...
0x000000ff つまり 255 でマスクされていることが分かる。

rrcコマンドとしては、-1や1024なども返すことは可能だが、実際それがどういったシチュエーションで使用されるかも考慮が必要なので、注意が必要である。

rrcコマンドとしては、そういった0〜255以外の想定外のリターンコードも返すことができるという自由度を持たせているということである。

ちなみに、シェルスクリプトでも任意のリターンコードを返すのも簡単に書けるが、こちらは勝手に0〜255にマスクされる点が異なる。
$ bash -c "exit -1"
$ echo $?
255

$ bash -c "exit 1024"
$ echo $?
0

ということで、子プロセスのリターンコードをテストしたい時にはrrcコマンドは何かと重宝するだろう。

2023年1月3日火曜日

Meta Quest 2 (Oculus Quest 2) Tracking Lost時にホーム画面まで表示するやり方および何となくエラーの見当をつける方法(画像&動画あり)

Meta Quest 2 (Oculus Quest 2)でTracking Lost(トラッキングが失われました)状態になり、Meta公式ページの対応やネット情報を一通りやっても解消しない場合に、どうにかホーム画面まで表示するやり方。

※※※ Warning(注意)※※※
この記事はMeta公式文書で参照可能な範囲は参照してますが、それでは不十分な箇所はネット情報を参照しています。
また、Bluetoothマウス・キーボードはMeta的には「Experimental Features(実験的機能)」とのことで、通常は正常起動しているHMD上の設定画面の「Bluetooth Pairing(ブルートゥース・ペアリング)」から接続するものです。
ソフトウェア的なことですので、どこの画面でBluetooth Pairingしても問題ないかと思いますが、あくまでも自己責任の元でご判断ください。
Bluetooth Pairingに限らず、本記事の内容は自己責任でご判断いただければと思います🙇‍♂️

ただし、本記事ではHMDやコントローラを分解などによって内部アクセスしている訳ではなく、公式アプリのみを使用して「表面上」見ることができること・操作できることを、できる限りやっているということです。

故障した場合は、自己判断せずMeta公式に書いてあるとおりMetaサポートに連絡しましょう!!!

一応お決まりかもしれませんが、記載しておきます。
本記事を読まれて何かしらの対応を行われたことに関しては、私は一切の責任は負いません🙇‍♂️ (負える訳がありませんが念のため。古今東西世の中は怖いですからね。。)
※※※※※※※※※※※※※※※※※※※

【前提条件】
・Meta公式ページの対応は一通り試していること。
・ネット情報でできそうなことは試していること。(上記Warning(注意)記載済みですが念のために追記しますと、サイトによっては保証範囲外のことも含まれますので、そこまで含めて自己判断でお願いします。)
・つまり、本体(以下HMD(Head Mount Display))のカメラ4つを綺麗にすることや、コントローラの電池を取って待機して入れ直したりとか、Guardian(ガーディアン)の履歴をクリアとかを試したがダメだった状態。
・Tracking Lostになった場合かつコントローラも動いてない(あと画面が顔追従しなくなった)場合は、Tracking LostダイアログのContinue(次へ)ボタンも押しようがなく落胆している状態。
※細かく書くと、3秒くらいは顔追従しないが一瞬(0.5秒くらい)だけ追従する状態。そこで頑張って視線つまり白い点(ポインタ)をボタンに持っていって、コントローラのボタンを連打するけど、残念ながら画面上のボタンが押せなくて悲嘆に暮れている状態。
・スマホの「Meta Quest」App(Meta Questアプリ)でHMDとリンク済みだとなお可。

【必要なもの】
・HMD
・Oculus Quest 2 コントローラー
・スマホの「Meta Quest」App(私が試した時のバージョン:193.1.0.15.104)
・Bluetoothマウス
・Bluetoothキーボード
・Metaの開発者アカウント※Meta Quest 2でFacebookアカウントでログインしたと思うが、それを開発者アカウントに登録する必要がある。この記事では説明は割愛。各種サイトをご覧ください。
・PCの「Meta Quest Developer Hub」(私が試した時のバージョン:3.1.1)

【手順】
HMDがTracking Lostになってコントローラも動かない場合は、マウスを繋ぐことで一部操作可能となる。
マウス接続手順としては、
・スマホ「Meta Quest」起動 → 接続済みのHMDに接続 → ヘッドセットの設定
 
→ コントローラ

→ 新しいコントローラーをペアリング 

→ ゲームパッドをペアリング

→ Bluetoothスキャンが始まる

・BluetoothマウスをONにして、新規デバイス接続状態にする(操作方法はマウス次第。大抵はマウスに付いているBluetoothボタンを長押し)
・スマホ「Meta Quest」側にBluetoothマウスが表示されたらそれをタップ


→ 「何らかのエラーが発生しました。もう一度実行してください。」が表示されるが、実際はペアリングできている。おそらく「Meta Quest 2コントローラとしては機能してませんよ」という内容なのだろうと推測。



これでHMD側でマウス操作ができるようになるはず。ラッキーであればこれでマウスで「Continue」ボタンを押して、GuardianをOFFにしたりして「使える」状態にまではできるのではないだろうか?
ただしTracking Lostが出ている以上はHMDに何かしらの異常が起きているわけであって、以前と同じような状態でゲームができるか?ということとは話が別なので注意していただければと思う。この記事はあくまで「頑張ってホーム画面まで表示するやり方」である。
「エラーの見当をつけたい」という方はもう少し読み進めていただければと思う。

2022年11月21日月曜日

【Unreal Engine 5.1 on macOS 】UE5.0と比べて影が濃くなった現象と回避方法 Lumen on macOS

【環境】
MacBook Pro (2021年モデル M1 Pro, 14-inch, 16GB Memory) macOS Ventura 13.1
Unreal Engine 5.1.0 正式版(Preview版では無いの意味)
※2023.2.8 Unreal Engine 5.1.1 でも試してみました。末尾参照。
※2023.3.23 また、Unreal Engine 5.2.0 Preview 1 にて本事象が解消されました!
※2023.5.12 Unreal Engine 5.2.0 正式版リリースされ、問題ありませんでした!

【症状】
Unreal Engine 5.1.0がリリースされたので使ってみた。
Unreal Engine 5.0.xと比べて全体的に動作も爽快になって素晴らしい!と思っていたが、そういえばなんとなく影が暗くなった気がする。

よってThirdPersonプロジェクトで比較してみた。

まずUE5.0.3の場合:


次にUE5.1.0の場合:


UE5.0.3では右端の壁の影の格子線がうっすらと見えるが、UE5.1.0では真っ黒である。

壁に寄って、マネキンも置いてみる。

【UE5.0.3】

【UE5.1.0】


UE5.1.0では影が完全に漆黒である。


【回避策】
根本解決では無いと思うが、PostProcessVolumeのパラメータを変えることで、真っ黒現象は回避可能だった。

設定対象:レベル上の Lighting → PostProcessVolume
設定内容:Global Illumination → Lumen Global Illumination → Final Gather Quality をデフォルトの 1.0 から最小値(0.25)にする。



【UE5.1.0 対応後】
UE5.0.3の見た目とほぼ同じになった。

なお、以下の値を境界にして、真っ黒↔︎見えるが切り替わる。(これがいわゆる「マジックナンバー」? Unreal Engineとしては初めて見つけました✌️)
・0.472657以上:影が真っ暗
・0.472656以下:影が真っ暗ではなくなる

また、不思議なことにマネキンの関節部分だけが、真っ黒から白に変わるのである。
メッシュ内部の何か(Material)の要因も関係しているということだろうか?


なお、エディタ上では漆黒問題は回避できたが、シーケンサーの Movie Scene Capture (Legacy) や Movie Render Queueで動画出力した場合には、やはり残念ながら影が真っ黒になってしまう。。
シーケンサーで使用するカメラ側のFinal Gather Qualityを0.472656以下にしてもダメだった。


【考察】
Unreal EngineをUE5.1.0から使い始める人は、この影が真っ暗なThirdPersonプロジェクトとかから触る訳で、「なんじゃこれは?Unreal Engineってすごいと聞いてたけどこんなに見づらいの?」とか思われないか、Epic Games社が心配である^^
(むしろ問題のなかったUE5.0から使い始めた私がラッキーだったのか???)

今回触った設定値にもLumenとある通り、Lumenバージョンアップ周りの影響か、またはMacならではの現象なのだろうか?

リリースノートも以下の通りである。(新機能紹介のトップバッターですね。)
Lumen、Nanite、および仮想シャドウ マップの更新

次世代コンソールや次世代対応 PC で 60 fps で動作するゲームや体験に対応するための 
Lumen ダイナミック グローバル イルミネーションおよび反射システム、Nanite 仮想化
マイクロポリゴン ジオメトリ システム、仮想シャドウ マップ (VSM) の基盤を確立することで、
高速の対戦ゲームや詳細度の高いシミュレーションをレイテンシーなく動作させることができるように
なりました。

私は初心者すぎて、一体どの技術が影響しているのか見当もつかないのだが、以下のようなフォーラムでも議論されている通り、最近でもやはりMac上でLumenが動くだの動かないだのの話は続いているようである。
※トピックはいくつもあるのだが、Epicからの公式返答がどこを見ても見当たらない^^この件については明言を避けることに内部的になっているのだろうか?^^
→上記1つ目のフォーラムにて、Epicスタッフの方から返答がありましたね!末尾参照。

※なお、タイトルに「Lumen on MacOS」と記載したのはDeveloper Forumを眺めていると同じようなトピックが多かったから。原因の可能性であるかも知れないが、明確に原因という意味で書いたわけではない。
ただし、公式ページにもLumenグローバルイルミネーション部分に、実は同じような比較画像付きで説明があった。
比較画像でもLumen GIがOFFの場合は、影部分が漆黒になっていることがわかる。

また、Lumen Global Illuminationの「Final Gather Quality」とは、Lumen のグローバル イルミネーションの品質を向上させ、レンダリングされるノイズを低減する値っぽい。色々サンプルを見ると、値が大きいほどノイズ除去効果があるようだ。
今回の事象は、値を上げて品質を上げたつもりが、むしろ影が漆黒になってしまう、といった感じだろうか。
精度をあげることで反射とかを計算しすぎて、ある臨界点を超えて明るさよりも影の力がまさってしまっているのだろうか?
UE5.0 で問題なかった頃は、影部分もうっすら見えていたので、明るさ>暗さ だったが、UE5.1 でFinal Gather Qualityの値を上げて品質向上させると、なぜか 明るさ<暗さ になっているとも言える。しかしいくら品質を良くしようが悪くしようが、明るさ>暗さ の不等式が逆転することはありえないはず。。
上記は単なる直感的な説明になり、また、繰り返しになるが、MacOS環境上でもUE5.0では問題なかったので、MacOS環境上でUEを動作させた場合のLumenがらみの何かの「噛み合わせ」の問題と思いたい。

※そもそもWindowsでは問題ないか気になるところです。(試して比較できればいいのですが。。)
※キーワードだけでも、Lumen, PostProcess, Global Illumination (GI), 仮想シャドウマップ(VSM)とかがあって、さらにプラットフォームとしてのMacOSが絡んでくる訳ですね^^
MacOSもちょうどMontereyからVenturaへのバージョンがあったりと。。(VenturaではゲームAPIのMetal 3が話題でしたね。BioHazard Villageが移植されたりしました!ただしMetal 3が今回の問題と関係あるかどうかは私の知識では不明です。そもそもUEのMetalに対する取り組みとかロードマップとかも私はまだ知識が追いついておりません。。(あくまでもiOS用にビルドするためだけに使う、という姿勢?))

私としては、早く改善版が出てくれるか、解決策がフォーラムで議論されるかを待つばかりである。(UE5.0.xでは問題なかった訳であるし、個人的にはUnreal Engineのデフォルトパラメータが噛み合ってない系の話であって欲しい。。)

※なお、私が知らない間にエンジン全体に関する設定を変えてしまっていて、そのせいではいけないと思ったため、UE5.0.3及びUE5.1.0はアンインストールした上で再インストールして試してます。(1日がかりの作業だった。とは言っても約16GB×2つのダウンロードを待つだけでしたが。。)

※ちょっとだけUEについて知見を得たので書いておくと、やはりNaniteとLumenとかPostProcess, GI, VSM, ... は密接に関わってるようで、やはりMac+Naniteの問題の影響なのだろうか?
こちらにも書いたが、MacではNatiteは対応されていないし対応予定もないので、Macは置いてけぼりにされるのだろうか。。。?😢
それとも下記はあくまでも、「Mac上のグラフィックス API (Metal) にはUnreal Engineのエンジンの根本的なところから対応することはないけど、動く範囲では動かせる」と言った意味合いなのだろうか?
UE5で(もしかするともっと前から?)ノンゲーム(映像制作とかアニメとか)分野でも「最終アウトプットに近い状態で制作が進められるので、制作フローが根本的に変わる」とかあったと思い、映像分野(アート分野)に強いMacに対するUEの対応方向は気になるところである。
There is no Mac OS support for Nanite, nor is any likely in the future due to 
graphics API limitations.

(Google翻訳) Nanite に対する Mac OS のサポートはありません。また、グラフィックス API の制限により、
今後もサポートされる可能性はありません。

NANITE FOR EDUCATORS AND STUDENTS より抜粋


(余談)実はもう一つの問題があって、Megascanから追加したメッシュが何故かある日突然、表面の見た目が真っ白になってしまった現象があり、現在未解決である。
一応、一時的な回避策としては、画面右上のSettings → Preview Rendering Level をAndroid Vulkanとかにすれば、モバイル上の見た目を再現してくれて表面画像も描画されるのだが、根本解決ではない。
ちょっと余談で書くにはボリュームが大きくなってしまうので、こちらも解決したら別記事を書く予定です!

→こちらの問題もUE5.2.0にて解消されておりました!
 (こういったエンジン側の問題(?)となると、もう原因は追えませんね。。)

ーーー
2023.2.8 追記
Unreal Engine 5.1.1 がリリースされました!
早速、新規ThirdPersonプロジェクトを作成して確認してみましたが、残念ながら影漆黒問題はそのままでした。。。

でも、Point LightとRect Lightは効くようになったんですね。
UE-157521	Point and Rect Lights on Mac do not cast or project any light
最初に書きましたが、またそもそも話になりますが、もしかして「現実に近づけた結果UE5.1.xの影描画になったので、UE5.1.xの方が正しい。UE5.0.xの方が現実とずれていた。UE5.1.xからは使う人が自分で少なくとも何らかのライティング(Lighting)設定することが前提!」ということなのでしょうか?(Windows版と比較できないことが痛い。。)

Point and Rect Lights on Mac ということで、Mac上の問題として認識されている訳で、それであれば、Point LightとかRect Lightとかの話以前に、影漆黒問題も認識されてると思うのだが、何せ公式見解(回答)がないので推測するしかない状況なのである。。

ーーー
ちなみに、UE5.1.1 でPoint LightとRect Lightは効くようになった訳だが、UE5.1.0で漆黒問題の調査時にPoint Light・Rect Lightも試してたが、どうりで効果がなかった訳だ^^
Point LightとRect Lightの問題だけ取り上げても「一体何が正解か?」がわからなくなってしまった感がある。(改めて、UEを期待を持って使おうとしてるユーザさんに対してEpicさん大丈夫だろうか?^^)
Point LightとRect Lightとか、結構基本的な機能な訳で、テスト・動作確認もしてたのかな?的な話になり、一体UE5.1.xからはベータ版リリースになったのだろうか?とユーザに思われないか、とても心配である。。

ーーー
こちらに別の回避策が投稿されてました。
Lumenは諦めて、Global Illumination (GI) Method をScreen Space (Beta) にする、という回避策ですね。
これであればシーケンサーからの動画出力も漆黒問題はありませんので、シーケンサーで動画作成されてる方は、根本解決されるまではこちらの回避策の方が現実的かも知れません。
ただし、「絵作り」(Postprocessとか)を実施済みの場合は、GIをLumenからScreen Spaceにすると見た目に結構な影響があるため、もう一度絵作りのやり直しは必要になってきそうですが。。

さらに、こちらにスタッフの方から内部的な回答もありましたね!!!
恐縮ながらGoogle翻訳させて頂きます。
M1 および M2 アーキテクチャは現在、HW で 64 ビット アトミックをサポートしていないため、
現時点では Nanite と Lumen with RayTracing を実装できません。
レイ トレーシングなしのルーメンは動作するはずですが、特定の問題が発生している場合は、
バグ レポート システムからお知らせください。

今後の M3 アーキテクチャがこれをサポートすることを期待していますが、これらの機能をさらに
実装する方法をコミットする前に、まだ様子を見るのを待っています.

どうやらM1/M2チップでは、「64 bit atomics」をサポートしていないため、Nanite と Lumen with RayTracingが対応されてないようです。
何かしらやりようはあるのかも知れませんが、少なくともM3チップのアーキテクチャが判明してからとなりそうです。
(結果としてM3チップで上記機能サポートされ一件落着するのか、またはM3チップ上で機能サポートされず、UEも未サポートが続くのか、はたまた、UE側が「しょうがないか」とか言って次善策で対応してくれるのかは、蓋を開けてみないと分からない。。)

とりあえず、MacOS上ではしかるべき理由があってNanite & Lumen (の全機能まで)はサポートされていないということが分かってよかったです。
また、着地点がお互いにベストな結果になることを期待したいと思います!

ーーー
ソフトウェア開発をされた方であれば分かると思うが、今回の件で言うと、UE5.0.xからUE5.1.xへのバージョンアップによって漆黒問題が発生した訳だが、バグだからといって簡単に「引っ込める(バージョンを戻す)」ことができる箇所と、そうでない箇所がある。

UE5.0.xからUE5.1.xに切り替えて、エディタ全体の動作が爽快になって驚かれた方もたくさんいるかと思うが、それはやはり全体にわたる修正とか、アーキテクチャに関わる修正な訳であって、「漆黒問題が発生したから、ここだけバージョン戻せ」とはいかない訳である。
(もしも戻したら、そこのソースコードはUE5.0.x→UE5.1.xで作業した分がまるまる無駄になるということ。)
無駄にならない・させないために、次期バージョンアップで実現したいこと(ビジョン)から入って、細かい設計まで慎重に行う訳である。
(もしもそこがミスっていては、確かに残念な結果になってしまうのであるが、ここまでユーザの支持を得ながら成長されてきて、場を重ねてきた猛者の方々が方針を打ち出しているはずなので、流石にそこまで大きな過ちはないと思う。)

よって漆黒問題はいわば二次的・副次的な結果生じた問題であって、解決するには現状路線を進んで行って解決するか、または大幅に方針転換して(それこそこの問題のためだけに)対応するか、のどちらかになるのだが、上記の通り後者はまずあり得ないだろう。

いちUEユーザとしては、MacOS + UE 環境がお互いにベストな着地点に到達してもらうことを願うばかりである。

ただ、本記事の記載動機でもあるが、MacOS + UE5.0.xから使い始めて漆黒問題もなかったことを知ってるだけに、UE5.1.xの間はLumenを諦めなければならないのがなかなか決心が付かない、と言いたいだけであった。

まあ今回スタッフの方からも原因の説明があった訳で、また私個人的にはMacOS + UEで映像制作をメインに使っているため、解決されるまではGI MethodをScreen Spaceにすることで対応しようと思う。
※あ、あとM3チップ + UEで解決されたとしても、M1/M2 Macはどうなるか次第ですね^^M1/M2 Macもどこをどう通るか分かりませんが、うまいこと対応されるといいですね!または、このためだけに買い替えるか!?(というか、このためだけに買い替える余裕があるのであれば、MacBookは10,20,30,...万はするのでWindows + RTX30xxとかにした方が良さそう?^^これもUEとかゲーム分野に目覚めて本格的にやりたければですが。←Macで3D映像制作したい人マイナス1人^^こう言うところの「シェア」的な点でもMacはまだ弱いですかね?(こう言う意味まで含めてMac側もWin-Winの関係を作れるかですね!) まぁホットな話題といえばホットな話題でした。。)

ーーー
2023.3.23 Unreal Engine 5.2.0 Preview 1 が利用可能になりました!
早速ThirdPersonプロジェクトで試したところ、漆黒問題も直っておりました!!!🎉

シーケンサーの Movie Scene Capture (Legacy) や Movie Render Queueで動画出力しても問題ありませんでした。
対応ありがとうございました!
(Macで3D映像制作したい人がマイナス1人しなくて済みました😅)

ーーー
2023.5.12 Unreal Engine 5.2.0 正式版がリリースされ、漆黒問題も問題ありませんでした!
Movie Scene Capture (Legacy)、 Movie Render Queueも大丈夫でした。

リリースノートのBug Fixedや改善項目中には、本トピックの影漆黒問題に対する直接的なものは見つけられませんでしたが、リリースノート中に以下が挙げられており、この辺の話だったのでしょうか?
Hardware ray-tracing support for Lumen is not supported on macOS, 
which means Lumen will fall back to using a software-only ray-tracer. 
This means Lumen will produce lower-quality results (for example, 
reflections are less detailed and dynamic meshes are not visible in them) 
on Apple Silicon compared with devices that have hardware ray tracing support.
Unreal Engine 5.2 Release Notes | Unreal Engine 5.2 Documentation より抜粋

ハードウェア・レイトレーシングからソフトウェア・レイトレーシングに「戻す」(fall back) するとありますね。

UE5.1.x での回避策として、Final Gather Quality ≦ 0.472656 を境に、漆黒⇔そうでないが、綺麗にOFF/ON状態になっており、これがH/W Ray-TracingかS/W Ray-Tracingの境界線だったのでしょうか?
Final Gather Quality ≧ 0.472657 ではクオリティを上げるためにH/W Ray-Tracing処理になるが、Apple Silicon MacのGPUとの相性?とかの問題で、うまく処理されずに、結果的に影部分が漆黒状態になっていたとか?

そしてこの問題点はすぐには解決できないとかで、UE5.2.0 では(諦めて)全てS/W Ray-Tracingに「戻した」(fall back)ということだろうか?

ということで、本事象はどうやら UE5.1.x だけ特有の問題だったっぽい。
直ってくれれば問題ないわけで、この点について対応していただいて本当に助かりました!

ちなみに最後に、この内容はEpic Games DEV COMMUNITYフォーラムにも投稿させていただきました。

2022年10月16日日曜日

【Unreal Engine 5.0 on macOS 】シーケンサーで、FKControlRigのAdditiveにするとMesh(Actor)が消えて編集できない

シーケンサー(Level Sequence)で、アニメーションを作る時に、
SkeletalMeshのFKControlRigでアニメーションを作りたい場合がある。
Unreal Engineのリファレンスには、既存アニメーションをベースにして、
FKControlRigの動きを追加できる機能として、FKControlRigを「Additive」にするやり方が
載っている(※1)のだが、macOSだからなのか分からないが、うまくいかなかった。
実際の作業手順的には以下のようになる。
・シーケンサー(Level Sequence)を開く
・SkeletalMeshをシーケンサーに追加
・追加したSkeletalMesh(Actor)でベースになるアニメーションを設定
・追加したSkeletalMesh(Actor)に対して、FKControlRigを追加
 →SkeletalMesh(Actor)はFKControlRigに従って、デフォルトポーズ(Aポーズ)になる。
・FKControlRigを右クリック→Additiveを選択(ONにする)
 →SkeletalMesh(Actor)が消える。
  見えないだけかな?と思い、シーケンスの再生や動画出力してみてもやはり見えないままだった。


【環境】
MacBook Pro M1 (2021年モデル) macOS Monterey 12.6 / Ventura 13.0 Beta
Unreal Engine 5.0.3

【解決策1】
この前発表された、まだ正式版ではないが、Unreal Engine 5.1.0 Preview版では、本事象が直っていた!!!
macOS+Unreal Engineでゲーム制作よりも映像制作がメインの方は、このAdditiveが使えるか使えないかは結構クリティカルな問題だと思うので、とりあえずUE 5.1.0 Preview版を使うのもアリかと思う。

※P.S. 2022.11.16 Unreal Engine 5.1.0 が正式版になりました! Additiveも正常動作しております。これでMac環境 + Additive 問題も一件落着ですね。よかったよかった✌️
(細かい点ではシーケンサーからの動画出力を「Movie Scene Capture(Legacy)」にするとAdditiveが効いてくれない。「Movie Render Queue」にすれば問題ない。(これは本当に焦った^^映像制作時に、途中経過版はとりあえず「Movie Scene Capture(Legacy)」で確認して、最終出力時に「Movie Render Queue」を使うというやり方をしている人もいるかと思うので要注意))

全体的にも動作が爽快になっている感じがします。素晴らしい!
あ、でも色味の問題が新たに発生。。詳細はこちら「UE5.0と比べて影が濃くなった」を参照。

※なお、 Unreal Engine 5.1.0 Preview 1 だと、SkeletalMeshやPhysicsAssetを配置するとメッシュ表面に影がチラついて以下のメッセージが表示された。
your scene contains a skydome mesh with a sky material 
but it does not cover that part of the screen
また、ゲームをRunしてみて停止後に以下の警告が出ていた。
StaticMeshComponent0 has to be 'Movable' if you'd like to AddImpulseAtLocation.
ちょっと調べたら、SkeletalMeshやPhysicsAsset配下のStaticMeshのMobilityをMovableにすれば良さそうだが、StaticMeshのDetailsには該当プロパティは表示されていないので、どうすればいいのだろう?と思った。

しばらくしたら、Unreal Engine 5.1.0 Preview 2 が出ていて、そちらで試したら上記現象は解消されていました👍(深追いしなくてよかった😅 公式もアナウンスしてますがPreview版なので本格プロジェクト用で使おうとせず、このあたりは一歩引いて接しましょう。。最初に書いた「とりあえずUE 5.1.0 Preview版を使うのもアリかと思う」ということと矛盾しますが。。)

ーーー
ついでに書いておくと、macOSでUnreal Engine 5.0.x を使ってると、起動時に以下の警告が毎回出ていて鬱陶しかったが、これも Unreal Engine 5.1.0 で直っていた!
5.0.xのエラー1個目は、内容通りシステム設定のFirewall設定の許可項目にUnrealEditor.appアプリケーションを追加したがダメだった。
Do you want the application "UnrealEditor.app" to accept incoming network connections?
2個目のエラーは、Unreal Engine内部のメッセージなので深く調査はしていない。
UE 5.1.0 で解消されたので、もうこれ以上は深追いしないし、しなくて済む!!
'MegascansPlugin' is Incompatible








【解決策2】
解決策というか、別のやり方。
Unreal Engine 5.0.xの場合は、Additiveを諦めてベースとなるアニメーションをControlRigにして、生成されたControlRigをいじくって自分のやりたかったアニメーションに編集するやり方。
・ベースになるアニメーションを追加
※もちろんアニメーションの組み合わせ(Weightによる自然なアニメの切り替わりや、アニメの重ね合わせなど)で済むのであればそれに越したことはない。つまりベースのアニメは組み合わせでほとんど作っておく。
・ベースのアニメができたら、シーケンサーのSkeletalMesh(Actor)を右クリック ※バックアップは取っておきましょう(以下同様)
→Edit With FK Control Rigを選択。ダイアログが表示されるのでCreateを選択
→ベースとなったAnimationの方はグレーアウトされ、FKControlRigに全コマのキーが生成される。
→FKContorlRigを頑張っていじくって、ご自身のやりたかったアニメーションに加工していく。

解決策2の問題点としては、Edit With FK Control Rig後に「やはりここに別のアニメーションを追加したい」とか「出来上がったものに、続きのアニメーションを追加したい」といった時がめんどくさい。
一応その手順は、
・シーケンサーのSkeletalMesh(Actor)を右クリック
→Bake Animation Sequence。ダイアログが表示されるので名前をつけて保存する。
→シーケンサーのSkeletalMesh(Actor)のFKControlRigを削除。
 Animationに前ステップで保存したAnimation Sequenceを選択。
となるかと思う。

補足として、そもそもアニメーション業界やゲーム業界の実態は私は知らないので、ここに書いた内容はそれら「主流」のやり方とはマッチしていないかもしれない点、ご注意いただければと思います^^
(ゲーム業界といっても、各種シーンのアニメーションばかり作っておられる部署もあったりする?デザイナやモデリングを専属としている方も「いるんだろうな」くらいの知識です^^;)
(プラットフォーム的にもやはり主流はWindows?そしてWindows版であればUnreal Engine 5.0.xでもAdditiveは正常機能してる?一応GoogleとかEpic Games DEV Communityも英語文献含めてmacOS + Sequence + FKControlRig + Additiveとかで検索したが、それらしいトピックは見つからなかった。(UE5が出始めだったから?UE5.1.xで直ったので「まぁいいか」くらいの感覚))

こちらにも書いたが、MacではNaniteはサポートされていないし、される予定もないらしい。
業界的にはMacはデザインとかビデオ編集とかアニメーションに強みがあると思っていたが、「ゲームデザイン」「ゲームアニメーション」とかゲームがらみでUnreal Engineが本格的に使われてはいないのだろうか?分業で、Naniteに関係する箇所以外だけやってるとか?
Naniteはあくまでリアルタイム編集がやりやすくなるだけだから、アニメーション現場とかでNaniteが使えないMacでも問題ないということ?
人によってはWindowsとMacを行ったり来たりしながら作ってるとか?


2022年8月2日火曜日

重複排除記憶装置および動画骨組み形成圧縮機構

圧縮方法の基本的な考えとして、テキストファイルであればアルファベットの出現率が高い方から短い符号を割り当てて行って辞書化(キー・バリュー)して圧縮する方法がある。
これは1文字(1バイト)ずつ見て行く方式であるが、英語であれば英語の、日本語であれば日本語での文字のつながりの特徴・パターンがある訳で、そこまで考慮すればより効率の良い圧縮ができるであろうことは自明である。(というか実装されてるはず。)
(1ファイル中で全部英語とか、全部日本語とかであれば良さそうだが、複数言語が入り乱れているとオーバーヘッドが発生しそうである。また文法とか単語がルールに則っている間は良いが、突然(敢えて)変な言い方をしたり、敢えてスペルミスをした文章を載せる場合は、そこだけ「生(raw)情報 」としてエスケープしたりと、こちらもオーバーヘッドがかなり発生しそう。と言うことで実装はかなり大変そうである。)


今回のアイデアとしてはまず、テキストファイルであってもバイナリデータとみなして、パターンをとらえて圧縮するようにする。
そして、それを記憶装置全体に適用する、と言う物である。

解消されるポイントとしては、
・ファイル種別によってヘッダとか「決まりきった」書き方の箇所とかの重複した無駄な容量を節約できる。
・人によって同じようなファイルが集まる傾向がある(はず)なので、重複した無駄な容量を節約できる。(その人の作業で発生するバックアップファイルとかは少なくとも存在するだろう)
・つまり記憶装置全体としては使用者の特性にあった圧縮ができる。
といったところ。(話を分かりやすく単純化しているが、実際はどこまでも応用可能である。)

そういった情報を集めていけば、「現時点における、この組織の特性」が抽出できるので、以降はそのパラメータ決め打ちで圧縮していけば良い。
あわよくばクラウド全体・全世界に拡張できる。

問題点としては、
・パターン抽出の「枠の大きさ」はどれくらいが適切か。また「入れ子」も許容するのか。
・この方式はある時点の記憶装置全体の状態を基にパターン抽出する発想のため、変化に弱い。つまり書き込みがある場合には向いていない。
といったところか。

まず「枠の大きさ」「入れ子」についてだが、簡単に言うと最小公倍数で括り出した方が良いのか、最大公約数で括り出した方が良いのか、と言うこと。
最小公倍数で括ると言うのは、最初に書いた例だと英字であればアルファベットのeが一番出現率が高いので一番小さいサイズの符号に置き換えて、次は…と言った感じである。
そして入れ子というのは、一回符号化して出来上がったデータを再度パターン抽出して、今度は例えば2バイトの枠に広げて同じパターンを発生頻度の高い順に小さいサイズの符号に置き換えていく、ということ。
1回目の符号化であれば、符号化したものが1バイトを超えてしまっては圧縮にならない。
2回目の符号化であれば、符号化したものが2バイトを超えてしまっては圧縮にならない。
また、符号化したものが1回目のものなのか2回目のものなのか識別できる必要がある。
これを3回、4回と入れ子にしていけば圧縮率は高くなるかもしれないが、その分読み出す時の復号化の処理に負荷がかかることになる。
(1マシンで考えると大いなる無駄だろうが、クラウドで考えれば「復号化サーバ」がいて、全ての符号化辞書情報をメモリ上のキャッシュとして確保できるのであれば、このサーバにサーバに復号化だけ任せれば良いが、でもやはり処理要求が多すぎてI/Oは追いつかなそう。)

ということで、枠が小さすぎると細かくなりすぎて復号化が大変になるし、枠が大きいと復号化は簡単だけどあまり圧縮の意味がないため、どの程度の枠が圧縮率・読み出し速度のバランスとして最適なのかは実際のデータを基に計測する必要がある。

−−−−−−−−−−
アイデアの発端としては、もう編集されることがない決定文書とかアーカイブファイルとか動画とか、I/Oで言うと「読み取り」しかされないファイルは最大限容量を節約して良いのでは?と思った点。現在のストレージ技術では、全く同じファイルとかかなり似通ったファイルでも律儀にディスクスペースを使うしかないため、そこのブレークスルーになれば良いかと思った。

また、現在のクラウドストレージサービスでは「容量無制限」サービスは存在しないが、それは、そんなことをすれば絶対に誰かがディスクを「食い尽くす」人が出てくるだろうし、そう言う人を防ぎようがないからであろう。
しかし、このアイデアが実現すれば、そういった輩がどれだけ同じ巨大ファイルをストレージに書き込もうとしようが、それは全て同じ「符号」になるだけなので、「あぁ意味ないな」と悟ればそんな無意味なことをする人もいなくなるだろう。
そして「容量無制限」サービスも出てくるであろう。
※このアイデアを本気で実現すれば、もしかすると「ファイル容量」と言う考え方も根本的に変わってきそうである。

更にいっておくと、先ほどのストレージを食い尽くそうとする人の例では、同じ巨大ファイルで無駄にネットワークの帯域を使う必要もないことに気づくだろう。最初にハッシュ値などを確認してサーバから「アーカイブ済みですよ」応答があれば、クライアントは何も送らな行くて良い。
といったようにネットワークにもとても優しくなる。
(一部だけ符号化済みの場合は「xバイト目〜xバイト目まで送ってね」と返す、などなど。とは言っても「ファイル全体のハッシュ値」では差分は分からないため、この辺は要検討)

−−−−−−−−−−
なお、記憶装置(ストレージ)についてのアイデアであるが、アクセス権限やセキュリティについては、更に細かい検討が必要である。(アクセス権をちょっと考えると、符号化した方の情報にも、情報の元となったファイル&アクセス権の辞書が必要になりそう?)
このアイデアの特性が「書き込みに向いてない(リアルタイムの変更に弱い)」と言うことから、コンシュマー向けにはあまりならなそうである。
しかしビッグデータを抱える企業としては、ストレージの大改善になるアイデアであろう。
(復号化サーバとして考えれば、アクセス権はサーバとクライアント間だけの問題であるので、符号化データのアクセス権もシビアに考えなくて良さそうである。ただ、もしもこの装置をPCとかコンシュマー向けにも使いたい、となった場合には本機能の拡張版としてアクセス権対応版が必要になるだろう。)

ビッグデータとして例えば動画配信サービスであれば、似たような動画や時として「全く」同じ動画が多数あるはずで、それらを全て括り出せればものすごい容量の節約になるだろう。
動画圧縮技術次第だが、現在の方式では動画圧縮したものをストレージに格納しているはずで、圧縮動画から似た映像・同じ映像を括り出せれば良いのだが、それが不可である場合は一旦非圧縮データに展開してから映像を括り出さないといけないかもしれない。
しかし非圧縮データに展開して増える容量よりも、括り出しによって節約される容量の方が遥かに大きいだろう。
(また括り出し後に、今度は括り出し可能な圧縮方式で圧縮すれば良い。)

そもそも動画圧縮技術は、「隣接したピクセルは似通った色であることが多いはずだ」「隣接した時間では前後のフレームは連続的に移動しているはずだ(今の技術では加速度とかまで使ってる?)」と言ったアイデアで不可逆変換が主流であろう。

不可逆データ前提であるならば、括り出し時も「曖昧さ」パラメータによって、どれくらい似通っていれば同じ符号として置き換えて良いか調整ができそうである。曖昧さ:0 なら完全一致じゃないと許容しない。曖昧さを大きくするにつれて、似通った映像でも許可するが復号化した時にちょっと不自然になる、と言った感じだろう。

あと更に応用だが、動画であれば映像内部の一部の領域(静止画)についても同じアイデアが適用できそうである。つまり動画中で似通った・全く同じ静止画があるならばそこを括り出せる、と言うものである。(フレームに飾られた絵画とか)。ただしこちらは、たとえ全く同じ静止画であっても次のフレームではちょっと角度が変わったり、影がかかったりと、むしろ括り出し処理の方が難しそうである。
(余談だが動画も究極を言えば、元となった4次元データがあれば一番正確に再現できるのである。(当たり前か^^)。つまり上記で言ったフレームに飾られた絵画も角度が変わったり影が差したりと言ったことも、「絵画」データは1枚でよくて変化するのは絵画を入れているフレームの角度が変わったり、外部から影が差したりしているだけで、3Dで計算すれば良いだけの話、と言うこと。)
余談で書いたが、これも良いアイデアなので記録として残しておくこととする。
アップロードされた動画から3次元データを作成して、それを骨組みとすることで角度変化や影の差し具合などは「演算化」してしまうことによって圧縮する技術である。

なんと言うか、そこまで考えると、動画作成時に3D情報があるのであれば、わざわざ3D情報を削除することもないように思えてくる。(なんでせっかくの大切な情報をあえて削ってるの?と言うこと)。将来的には動画には3D情報もくっつけるのが主流になりそうである。

(画像認識技術でも、行き着くところは「欠落しているのは3D情報だな」と「悟った」人はたくさんいると思うのだが、画像に3D情報が付いているのが当たり前になれば「これまでの悩みは何だったの?」となるだろう。しかしこういった積み重ねれこそが技術革新なのであろう。)
(「ゲームエンジンのように画像全体をレンダリングをすると言うこと?」と思われるかもしれないが、そうではない。そんなことをしたら読み出し処理が追いつかない。
静止画や動画とレンダリングの最適解があるはずで、このアイデアをベースに最適解を探っていきましょう、と言うことである。(圧縮率、品質、エンコード負荷、デコード負荷などの総合的な最適解。圧縮技術の側面から3Dゲームエンジンを見ると、「テクスチャは容易には変わらない」と言う前提で圧縮していると解釈できたりする。テクスチャで解決できないもの、例えば髪の毛であっても最近は物凄い精度の良いモデルもあるわけで、これは言わば擬似的な近似値であり、髪の毛全てをシミュレーションしている訳ではないが、見る側としては実物と遜色のないものとして見えるため、または見えるように技術進歩してきた訳である。動画圧縮の前提として不可逆変換を前提にしている場合、つまりそれは各フレームの画像は「近似値」になっている訳であるから、本アイデアでも極端な話をすると3D化する時に髪の毛も「髪の毛近似モデル」に置き換えてしまってもいいのかもしれない。細かいパラメータは当然あると思うが。そもそも3D情報もゲームエンジンで作った場合であれば正確な情報だろうが、現実世界を撮った動画から3D情報を生成した場合は、その時点で近似値であるわけで、「近似値で良いのか?」と言う問いに対しては「では【正確な値】とは何か?」と問い直すことができるのである。それこそ映像の世界でも本当にただのレンズをそのまま撮ったのでは歪みとかぼやけとか手ぶれとか色々あるわけで、各種培われた「補正」が入っている訳である。補正をしてしまった時点でそれは既に「近似値」といえよう。物理学的な話になってきたが、実際に【正確な値】を計測することはとても大変なのである。また、もしも【正確な値】が取れたとしても、それを実際に人が「自然に」見えるようにするためには、今度は逆の手順が必要で、復元した情報を映像化する時に再度歪みとかぼやけとか手ぶれとかを結局は補正しなければならないのである。(ご存知の通り人が見る「色」の特性一つとっても奥が深い。プロから見ると「何だこの色使いは。というか何も補正してないのか?」と思われたりするのだが、では色を補正した画像は「本物」なのだろうか?)
ちょうど「本物か嘘か」と言うポイントが出てきたため、ちょっと書いておくと、
・本物を土台にして「近似」したもの
・本物のデータの一部または全てを、近似(補正)したり、モデルまたはシミュレーション(架空)データで置き換えたもの
を考えた場合、前者は本物または本物ベースのもの、
後者は嘘、そこまで明確に言わなくとも架空データで本物を模擬したもの、
と言えるだろう。
動画を楽しむ分には、そんなのどちらでも良いのかもしれないが、どの分野にも「完璧な正確性」を求めたり、求められたりする領域がある訳で、やはりどこかで真面目に議論しなければならないことである。例えば写真やビデオが証拠になったりする訳だが、担当者が気を利かせて色補正をしてしまったら、それは「本物」として扱っていいのか?と言うこと。先ほども書いたが、そもそも現代の最先端カメラでは写真を撮る時点で映像のプロによって培われた各種の補正が入ってしまっている訳で、そもそも「本物」として扱ってはいけないのではないか?と言う話になってくるのである。カメラについてはメーカーがどこで型番が何で、と言う情報で写真の特性も分かるため合わせ技で現代では「正確な」証拠として取り扱っている、と言うだけのことであろう。
しかし補正が入っていると言うことは、ある情報は強化され、ある情報は弱まったり省略されていると言うことなので、その特性を悪い方に活用されると極端な話「見えていたはずのものも見えない」写真や「見えてないはずのものが見える」写真も作れるはずである。そして現代ではそれさえも「正確な」証拠になってしまうのである!と言うこと。現代では「実際のカメラでそんな映像が撮れることは確率的には著しく低いため、取るに足らない」と割り切っているだけなのである。
上記はシビアするぎる話だが技術と共に成長していかなければならない問題である。
もう少し話を緩めると、例えば広告・虚偽広告が挙げられる。例えば本物の映像を近似値で補正するのはいいけど、シミュレーションデータに置き換えた場合、それは許されるのか?といった問題。どちらかというと倫理的な問題であろう。この辺は勿論経済の力学に沿って、Googleとかが先手を打って倫理観とかをまとめていくのであろう。(先手を打ってというか、大きいだけに何でも最初に槍玉に上げられる、と言ったほうが正確だろうか。))

3D情報ベースで書いたが、成果物ベースからもう一度見直せば、最終的な2D画像に直接関係しない3D情報は無論省略可能である。ただしこれくらい進化すれば、最終成果物として1本の動画だけにするのは勿体無い気がする。既に360°動画もあるわけだが、本アイデアは2D動画ベースなので、ちょっと違ってて、例えば2D動画なんだけどちょっとだけ視線を変えられたり、3Dカメラで撮影しなくても3D映像化ができる、とかであろうか。)

−−−−−−−−−−
ちなみに動画配信については以前に「ホログラムストリーミング」を発表済みである。

2022年7月28日木曜日

小説になるマンガ

最初はマンガなんだけど、説明文がどんどん長くなっていき、
気づいたら小説になってしまうマンガ。というアイデア。
本の枠だけ漫画になっているアイデアもアリ。
または漫画の中の人が漫画を読んでて、いつの間にかそっちがメインになるアイデアもアリ。
(くだらないけど、面白いのでアイデアとして残しておく)