2025年12月21日日曜日

Laravelのシーダー実行時に created_at, updated_at も更新する方法

検索でヒットするのは、
・普通にinsert文にcreated_at, updated_atを追加しましょう。
・factoryを使えば自動で付与されます。
と言ったところ。

テストデータであれば後者で良いだろうが、マスターデータの場合は前者を使うことになるがデータの一つ一つにcreated_at, updated_atを付けていくのは無駄を感じる。

よって、以下のように最後にcreated_at, updated_atだけ更新するのが簡単&効率的でコード上も無駄がない。
database/seeders/XxxSeeder.php
DB::table('xxxs')->insert([
    ["type"=>1, "name"=>"項目1"],
    ["type"=>2, "name"=>"項目2"],    ...
]);
$now = now();
DB::table('xxxs')->update(["created_at"=>$now, "updated_at"=>$now]);

※「created_at, updated_atには必ず値を入れておきたい」と言うことになってくるかと思うので、テーブル作成時(マイグレーション時)にDB側で Not Null & デフォルト値 設定をしても良い。
 しかし残念ながら
database/migrations/20xx_xx_xx_xxxxxx_create_xxxs_table.php
$table->timestamps();;
は、デフォルト値設定ができないため、timestamps()を消してtimestamp型で自力で作らなければならない。



2025年11月19日水曜日

フォントの拡張

絵文字まで含めてフォントを考える。

絵文字はどうしても正方形に収めるという、無意識の制約が発生してしまうのであるが、もしかしたらそう言った制約も不要では?というアイデアである。
大きなタワーとか、大きな橋とか、色々。

フォントや絵文字である以上、アイコニックにして「一発で誰でも【それ】と視認できる」ようにすることが命題のため、正方形に入り切らない場合は縮尺を変えたり、はみ出した部分は見切ってしまってたりする。

しかし、そう言った切り捨ててしまってた箇所も情報としては持ってていいのでは?というアイデアである。

また、絵文字の大元(オリジナル)はあっても良いが、それを「どう見せるか」(最終系)はある程度幅があっても良いのでは?というアイデアでもある。

具体的には、大元(オリジナル)となる情報(画像)がベースにあって、それをどのアングルからとか縦の縮尺とか横の縮尺はどれくらいでとか画角を決めて最終系にすれば良い。
これによって、これまでは単純に正方形からはみ出した部分は切り落としてただけであるが、そう言った入りきらない情報まで救い出すことが可能となる。

またこれは、2D (平面) に限らずに 3D (立体) や 4D (3D動画) にも拡張可能となる。
現在の絵文字時点でも、ほとんどの絵文字はオリジナルは3Dであるが、絵画のプロはプロの技巧でアイコニックに3Dを2Dに変換して描いている、とも言える。
この辺をもう少し真面目に(本気に)取り組みましょうという話である。

究極を言えばオリジナルは全て3D (4D)で良いはずである。
それをどのように2Dの最終系にアイコニックにアウトプットするかは、縮尺やポストプロセスの処理とも言える。(それこそAIで学習可能な領域。絵画師の商売が上がったりになってしまうかもしれないが^^;(ここに限った話ではないことはご承知の通り))

「アイコニックに視認しやすいように」という命題を差し置いて、フローだけ抜き出せば、
・オリジナル情報
・ポストプロセス(縮尺や効果(フレアとか)や色合い等の調整)
・最終画角(カメラ)
と言った感じになるだろう。(ものすごく単純化して書いた)
この辺はプロの現場のアニメーション制作フローや、3Dゲーム・アニメのフローと同様のことである。それぞれにプロが活躍してる通り。

これを真面目にフォントと絵文字にも適用しましょう(とりあえずやってみましょう)というアイデアである。
かなり先進的なアイデア・仕組み・機構なのであるが、公表することで特許関係の利権は誰も取れなくなるため、それよりも公表して共有することでオープンソースで広まった方が良いと思ったため、勿体無いがここに公表する。


ーーーーー
ここまで考えると、実は本来の「文字としてのフォント」も全く同じことが逆適用可能であることが分かってくる。

無論ほとんどのフォントは大元(オリジナル)は3Dである必要はないかもしれないが、敢えて3Dをオリジナルにしておくことで得られるものもあるだろう、ということ。
ここまでいくと「文字の発祥」的な考古学とか、または「なぜこのデザインになった」的な人類の美術史とかデザインの起源的な分野になってくると思うが、実は文字も3D的な考察によって得られるものがあるはずである。(また新たな分野を発掘してしまった^^)
ある程度まで文字が確立された以降は自然と2D的なものという共通認識が出来上がって、現存している文字のおそらく80%とか90%とか99%は2Dなのだろう。(誰も文字が実は3Dでは?と発想する人さえいないだろう。)
文字が確立する前とか、そもそも【文字】と言う概念を勝手に作ってああだこうだ言ってること自体が烏滸がましいことであって、本来はもっと自由なものであった。
おそらく文字の概念ができる前の人からしたら、「勝手に2次元に縛り付けるな!」と怒ることであろう^^;
2Dと言う共通化(及び当然【文字】と言う共通化)を手に入れた反面、文字以前の3D的な概念を捨ててしまったのである。
※この考え方もあらゆる分野に応能可能。我々は技術を手にする一方で見えなくなってしまった点はものすごくたくさんある。淘汰的観点からは「そっちを削ったほうがこっちは実際上うまくいく」と言うものであって、実際には極小解に囚われているだけかもしれない。
技術の発展によって、「実は現在の極小解よりもより安定した解が見つかった!」と言ってパラダイムシフトが起こるものである。
これまでは生身の我々を用いて実生活を通してそういったシフトを行ってきたわけではあるが、これからはここに書いた通り「極小解と思ってたけど違うんじゃない?」と言うムーブメントによって、本当に驚くほどたくさんの広い領域でパラダイムシフトが発生するのである。

ーーーーー
色々と考察は尽きないが、技術屋的な視点では、単純に全てを同じ仕組みで統一できるので美しいですよね?というだけはあるが。

壮大な計画にはなってきたが、ここにその一端を記す。

ーーーーー
応用としては、上記で「アイコニックにすることは差し置いて」と書いた通りであるが、ポストプロセスを置き換えれば、目的に応じて自由自在にアウトプットは調整可能である。
「絵文字にふさわしい」アウトプットをお望みであれば、絵文字の「答え」を学習させてポストプロセスを作成すれば良い。(まず最初に作る仕組みはこれになるだろう。)
企業やお店やゲームなどの「テーマ」に沿ったものがお望みであれば、テーマさえ学習さえすれば、絵文字まで含めて一瞬でテーマに沿ったフォントと絵文字が出来上がる。
(このアイデアのすごいところは「奥行き」まで含めてポストプロセスでテーマに沿った調整が可能な点。)
「それ以外に何があるんだ?」とちょっと考えるが、もはやフォントや絵文字の概念にとらわれる必要さえ無くなってくるのである。

このアイデア・仕組み・機構の可能性は無限大であるため、ここに特許関係も無効化しておいたため、世界の知恵と技術で大いに活用・発展させていただければと思う。

ーーーーー
また、本来のフォントに舞い戻ってきても、可変幅フォント(プロポーショナルフォント)は実は上記で言うところの第三工程の最終画角の動的変更処理であることが分かる。
前後の文字もパラメータにすれば前後関係で動的に調整が可能になる。
これは大いに絵文字にも応用が可能。

更に3D化及びデザイン的な点に踏み込めば、これまではフォントデザイナーさんのセンスに頼っていた点が、3D的な「意味を持った」数値として、人間の知覚として最も安定・安心・納得する調整が可能になってくる。
(そしてこの考え方は、従来の2D的なフォントの文字感調整にもフィードバックが可能。「3D的にこうだったたため、2Dとしてこれがしっくりきていたんだ!」と再認識が生じる訳である。)

※もしかすると、いきなり3Dで実装するのは大変なので最初は従来の2Dフォントにおいて、ここに挙げた超・動的かつプログラム可能で数値に裏打ちされた「人間にしっくりくる」フォントシステムが作られるのかも、と思った。


2024年12月15日日曜日

画面サイズ確認

 現在の画面サイズを確認できます。

※Javascriptの機能で取得できる値ですので、実際の画面サイズとは異なる場合があります。

No.項目幅 (Width)高さ (Height)備考
1screenスクリーンサイズ
2screen availスクリーンの有効幅
3devicePixelRatioOSの表示スケール
4スクリーン解像度表示スケールから逆算したスクリーン解像度

使用しているJavascript変数
1. screen
    window.screen.width
    window.screen.height

2. screen avail
    window.screen.availWidth
    window.screen.availHeight
    画面のウェブコンテンツに利用することができる範囲のサイズ。
    タスクバー(Windows)やDock(Mac)などを除いた範囲。

3. devicePixelRatio
    window.devicePixelRatio
    解像度と物理ピクセルの解像度の比。OSで設定してる値。
    Windows: 設定 → システム → ディスプレイ → 拡大縮小とレイアウト
        例: 150%にした場合、devicePixelRatioは 1.5 となる。
    Mac: System Settings → Displays → Advanced... → Show resolutions as list で解像度一覧が表示される。
    Android (Android 13の場合): 設定App → 画面設定 → 表示サイズとテキスト → 表示サイズ
   adb でAndroid端末に接続すればより細かい設定が可能。

4. スクリーン解像度
    表示スケールから逆算したスクリーン解像度。
    つまり、1.screen × 3. devicePixelRatio
 ※ Macの場合は、「Super Samples」機能で、物理的なスクリーン解像度よりも大きな値になる場合がある。
 devicePixelRatio = 「Super Samples」による仮想的なスクリーン解像度 / OSで選択中の解像度

参考: MDN Web Docs

2023年11月19日日曜日

【Unreal Engine 5.2】macOS で新しいバージョンの Unreal Engine に更新されなかった

macOSでUnreal Engine 5.3.0 を入れて使っていた。
数ヶ月前に UE 5.3.1 や UE 5.3.2 がリリースされたというニュースは見ていたが、私の Epic Games Launcher では通知が来ておらず、「あれ?Windowsだけが対象なのかな?(UE 5.0, 5.1, 5.2 では、そんなことなかったけど。。)」と思っていた。

作業では「My Projects」からプロジェクトを起動して作業するだけで、問題なく使えていたためあまり気にせずにいた。
しかしThird Person Projectで試したいことがあって、「Engine Versions」側から「Launch」をクリックすると、「Queued」と表示され、いくら待っても起動できなかった。
Epic Games LauncherとかOS再起動とかしてもダメだった。

ネットを検索しても UE 5.3.1, 5.3.2 が macOS 対象外という情報はやはり出てこない。
何か私の環境がおかしいと思い、以下を実施したところちゃんと UE 5.3.2 も出てきてインストールできました。
・Epic Games Launcher で一旦 UE 5.3.0 をアンインストール 
(Launch ボタンの右の🔽 → Remove)
・Epic Games Launcher 再起動


画面サンプル。本来は赤枠の箇所辺りに⚠️New Version of Engine Available みたいな表示が出るはず。

(考察)
そういえば UE 5.3.0 を使ってる時に、マーケットプレイスで取得したもの(Launcher 上だと「VAULT」)でバージョンアップの通知が来ており、探してみたが一体どれなのか見つからないことがあった。2 〜 3 回見直したが結局見つけられなかった。(数が多いと探すのが大変… この辺改善できないでしょうか?😅)

なんかその辺からおかしかったのかもしれない。
(何かのダウンロード不正が知らぬ間に起きており、そのせいでキューが詰まってた感じですかね?)

かなりレアケースだと思いますが、同じような症状の方の一助になれば幸いです。


2023年9月5日火曜日

macOSで日本語入力する際に気になること

かなり細かい話だが、macOSで日本語入力していて、いつも気になってしまう点がある。

それは、は行を入力する場合で、「h」をタイプすると小文字の
hが画面表示され、母音入力待ち状態になる訳だが、
「Iビーム」つまりカーソル位置を表す「|」縦棒と重なって
hが大文字のHに見えてしまうのである。

勿論一瞬なのではあるが、どうしても視覚が認識してしまうのであるから
しょうがない^^;

なので「おやっ!?知らず知らずの内に、キャップスロックを入れてしまったかな?」
と毎回不安になってしまうのである。

おそらく共感してくれる方もおられるだろうと思う。
(他のOSはどうなってるんだろう?またたったこれだけのために
 改善とかしてくれるものなのだろうか?)

※もしもこれを「読むこと」によって、これまで気になって無かったにも関わらず
気になり出してしまうこともあるかもしれないため、ご注意ください。
逆に言うと、これまでは無意識の違和感だったものが、これによって理由が
明確になった、とも言えるかもしれません。

※Windowsで確認したところ、Iビームが長かったり太かったりしており、入力文字とIビームは区別できるため気にならなかった。
macOSの場合はどうも入力文字とIビームが、線の太さや大きさが似通ってしまっているため、本稿の通りの視認上の問題が出てきてしまっているようである。

物書きさんとかデザイン関係の方だとこの辺の視認的な感覚も一般の人よりは研ぎ澄まされているので、余計に気になるのではないだろうか?
そしてmacOSはデザイン分野とかアート分野にシェアが広いようなイメージがあると思うので、尚更この点について些細なことではあるが「大丈夫かな?」と心配になった次第である^^;

(それとも本稿の問題点はそこまで気にする人はほとんどいないのだろうか?…
 まぁ慣れと言えば慣れの問題かもしれないが、まっさらな状態で気付いた「おやっ!?」という点は人の感覚の発現なので何かしら微かな違和感が潜んでいるはずで、そういう点は大切かと思いました。(アート分野の方であればなおさらその辺の感覚は大切にされてるはずでは!?))

-----
Macの日本語変換について。
スマート変換で入力してると、最初は意図した通りの変換が表示されてるのだが、変換を確定せずに入力を進めていくと先頭の方の変換がずれることがある。
変換修正するために矢印キーで先頭に戻ろうとすると、なぜか該当部分の単語(文節?)が増殖してしまい、毎回泣きそうになる。。。ユーザ離れしないためにも早急に修正を望む。

あと変換精度も色々言われてるのでここでは深く突っ込まないが、「にじ」と打って変換しても「二次」が候補にすら出てこなくて、これまた泣きそうになった。
心を無にしてShift + 左キーを押して「二」と「次」で一字ずつ変換してます✌️




2023年8月15日火曜日

macOSでのウィンドウ切り替え操作について

Macで作業していて、YouTubeの解説動画を見ながら作業をしたいことがある。

解説動画の文字が小さい場合はフルスクリーンにして見るのだが、解説動画の通り操作するため動画を一時停止してコマンド+タブ(⌘ + →| )で、作業用アプリケーションに切り替える。

ここまでは良いのだが、解説動画の続きを見ようとして再度コマンド+タブを押すと、フルスクリーンにしたYouTube画面には戻ってくれず、別のアプリケーションに切り替わってしまう。
これを実に何百回も性懲りも無く繰り返してしまうのである。。。😢
(多分同じお悩みをお持ちの方は、実は相当数の方がおられるのではないかと感じる。)

これは、Mac的には「操作スペース(英語:Spaces)」が異なっているため、コマンド+タブでは切り替えられないらしい。
「操作スペース」を切り替えるには、別のショートカット:コントロール+右矢印( ^ + → ) で切り替えるのがMacの流儀となっているらしい。
(ショットカット設定はシステム設定(System Settings) → キーボード(Keyboard) → キーボードショートカット(Keyboard Shortcuts...) → Mission Controlで確認できる。 (Move left a space / Move right a space ))
(また、Macbook Proなどトラックパットがある場合は、4本指スワイプでも切り替えられますね。)



※Windowsにも同じように、Windowsキー+タブで「デスクトップ」を切り替えられる機能がありますね。Windowsの場合もデスクトップが異なるとALT + Tab ではアプリケーションを切り替えられることは不可能ですね。


そこまでは分かったのだが、しかし、YouTubeをフルスクリーンにしただけで「別の操作スペースに移動された」ということは、一般ユーザーにはあまり直感的ではないと思うのだがどうだろうか?(その辺の直感性とかUXとかはむしろAppleが一番嫌うはずでは???)

ということで、もちろん議論に議論を重ねた上でのApple精神みたいなものに則った上での「答え」として世の中に出してはいるのだろうが、それでも多くのユーザの「直感」とは少しズレてる(失礼!)という点で書いておくこととする。

切り口を変えていうと、Appleがユーザに求める操作は、
・ユーザ自身で対象画面をフルスクリーンにしたかどうかを記憶しておくこと!
・フルスクリーン(別の操作スペース)に切り替える場合は、コントロール+→
 それ以外はコマンド+タブで画面を切り替えること!
ということを暗黙的に求めている、ともいえよう。

しかしユーザとしては作業に集中したいのに、いちいち「このYouTubeは細かい文字がないからフルスクリーンにはしてない、こっちは細部を見たいのでフルスクリーンにした」を覚えておかなければならず、コントロール+→ と コマンド+タブ を押し間違えると、ものすごく時間の浪費を感じるのである。

ということで、いろいろ書いてしまったが、言いたいこととしては、崇高なApple精神を曲げてもらう必要は全くないのだが、初期状態ではなくても良いので、回避策を公式に用意しておいてもらいたいと思ったばかりである🙇‍♂️

※そこまで考えるとAppleが考える方針と照らし合わせると、「フルスクリーンにしただけで別のスペースになる」というのが果たして方針・定義通りなのか?という問題とも思えてくる。ユーザの同意とか明白な認識のもとに別スペースにしたかどうか?ということ。

2023年8月12日土曜日

【Unreal Engine 5.2】PCG(Procedural Content Generation)がリリース

Unreal Engine 5.2でPCG(Procedural Content Generation)がリリースされました。

この機能はプロシージャルに、つまり数値だけ与えれば自動的にコンテンツ(メッシュとか)を生成してくれる機能です。

これを見て、私も同じことを既にブループリントで作ってたので、ついにEpic社も私の真似を始めたのだと思いました^^(絶対にそんなわけはないのだが。加えて既に多くの方が同じことをブループリントで作っていたことでしょう。。)

こちらが自作PCGを使って作成したビデオ👇 最後の増殖シーンで使ってます。


同じことをやりたい場合は、今後は公式のPCGを使えば良いので詳細は割愛するが、一応以下が作ったブループリント。


クリボー(あ、言っちゃった)をだんだん早くスポーンさせたかったので、スポーンスピードも変えれるという画期的機能も実装済みである!これも多分PCGで真似するだろう(あ、もうされてる!?)

もちろん、Line Traceを使って、地形に合わせた接地処理も行なっている!
※一部、木の途中に生えてしまったクリボーもいますが😅

また、ブループリントクラスをスポーンしてます!1人ずつのクリボーがブループリントとなっており、スポーンと同時にちょっとずつ大きく成長するスクリプトが組まれているため、大量のクリボーが一斉に生えてくるアニメーションが作成できました。
という点でも画期的!
※PCGでもStatic Mesh以外もスポーン可能???
→「Spawn Actor」で可能でした!!!


以上、何の役にも立たない読み物記事でした^^;

(紹介) タイプ音で入力内容を予測する機能

私のアイデアを書いてるブログに、キーボードのタイプ音で入力内容を予測する機能のアイデアを発表しておいたが、どなたかがついに実装されたらしいので、こちらのブログでも紹介しておくこととする。



2023年2月13日月曜日

Windowsエクスプローラーの検索でヒットしない

業務でWindowsを使っていて、エクスプローラで検索してもファイルがヒットせず、いらない時間を消費したため一言。

あるバージョンのファイルがあるかどうか検索したくて、 1.0.0とか 2.3.4 などのよく使われてるバージョン表記法で検索してみたのだが、ヒットしなかった。
そのため、ファイルは存在しないと思ったが、実際にはファイル名に検索したバージョン番号を含んだファイルが存在していた。。( textfile_2.3.4.txtとか)

原因はWindows OSのバージョンのどこからか、単語ベースでの検索になったためらしい。。
確かに「昔はこんなことはなかったはずだ」と感じた通りである。(というか私がWindows 10とかWindows 11の検索挙動が違ってることに気づくのが遅すぎだが^^;)

よって、単語とみなされない文字列で部分一致検索をしたい人はコマンドプロンプトなりPower Shellなりを使えと言うことなのだろうか?
(頑張って良い方に考えるならば、この部分はMSは放棄したので、どうぞサードパーティが自由に検索機能を作ってください!と言う大風呂敷を広げたと言うことだろうか?(しかし放棄は良くないかな。。))
また、多分Windows XPとかWindows 7の頃は単純部分一致検索もできてたはずで、それに親しんできた人についても、下手をすると「過去の人は知りません」的な態度に受け止められてしまう。

もしかして私の方がずれていて、世の中的に、世界中のOS的に「単語ベース検索」一本化が進んでいるのかと不安になって、念のためにMacで同じ検索をしてみたが、Macだと親切に「Name Contains "x.x.x"」のように部分一致検索のオプションも候補表示される。

ーーー
既述「Windows の新規作成ショートカットの遍歴」にも書いたが、MSはどうもこのようなすごいのだか、すごくないのだか分からないやらかしをやってくれるのである^^(慣れっこにとっては「やれやれまたか」とか飽きられ(諦められて)いるのだろうか?)

頭良すぎて、現実でやってることがずれすぎていると言うか^^。。(現実とずれてしまう時点で、本当に頭が良いとは言えないのだろうが)

Windows 8のスタートメニューの話と同様、今回の検索機能についても、MS内部でも「流石にそれはマズいんじゃ。。」と思っている人は必ずいるはずだが、MSではなぜかそういった声は届かないらしい。
「番号の一部で検索とか一般コンシュマーがすることは100%あり得ず、そんなことをするのはエンジニアだけであって、エンジニアはどうぞご自身のスキルを発揮して部分検索でもなんでもすればいいではないか!」とか逆ギレして済まそうとしているのであろうか?^^

何というか、何か物事の黎明期には紆余曲折がありがちであるが、これほど黎明期を、紆余曲折を体現した組織もある意味すごいと思った次第である。周りからやらかすことを期待されて、まんまとやらかす側のプレイヤーとなることを自ら甘んじて享受しているということなのだろうか?(しかし易きに流れては成長はあるまい。まぁ現実を見ればそんなことは分かっているのだろうけど)
もしくは自ら喜んでコンピュータ黎明期の骨董になろうとしているのだろうか?

ーーー
ということで、いらない時間を使ってしまったため一言書いてしまったが、こういった声も裏を返せばエールなのであって、どうぞ曲がらず頑張っていただきたいものである。
(冒頭に書いた通り、私は気づくのが遅すぎたが、世の中には激しいお方もいらっしゃるわけで、おそらくボロクソ言われているのではないかと心配になってしまう^^よくそれらに精神的に耐えられるなぁと感心したりもする^^)

しかし、「マズいと思ってることもマズいまま世に出してしまう」ことや「現場の一般ユーザ目線の基準とか【正常な感覚】を持てていない」ということは、一言で言えば「意思決定がうまくできてない」ということなので根は深そうである。

それこそWindows OSで世を席巻し、Internet Explorer独自仕様 (IE特別対応。何億人のエンジニアが泣かされたことか^^)とかOfficeマジック(Excelマジック、Wordマジックなど)とかのように「こっちが親でユーザが子なのだから、いちいち細かい要望を聞いてられるか!(エンジニアが困ってようが知ったことか!)」的な態度が祟っているとも言えるわけで、MSとして本気でユーザ目線に戻るのか、それとも過去の栄光にしがみついてあぐらをかき続けるのか(そして沈むことも気付かず、気づいた時には海の底とか^^)、そろそろ本気で気づかなければならない頃だろう。

そして、私が言うまでもないが、そのマズさはMS自身が一番知っているはずである。いやと言うほど気づいているのだろうが、それでもなかなか「やらかし」が止められない点に相当の根の深さを窺い知ることが出来るのである。

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日木曜日

小説になるマンガ

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

2022年5月24日火曜日

Unreal Engine 5でAndroidパッケージ作成 on MacBook Pro M1

MacBook Pro M1上のUnreal Engine 5でAndroid用パッケージ(apk)を作成する環境を構築した。
その時に発生したエラーと対処法について。
※最後に詳細を書いてますが、エラー②についてはWindowsユーザの方も参考になるかも知れません。

【環境】
MacBook Pro M1 Pro (2021年モデル) macOS Monterey
Unreal Engine 5.0.1
Android Studio Chipmunk | 2021.2.1 ※Android Studio Bumblebeeでも同じだと思う。

【経緯及びエラー内容】
Unreal Engineの以下のページを参照すると、「Android Studio version 4.0」とか古いAndroid Studioしか正式には対応してなさそう。

実際には、最新の「Android Studio Chipmunk」でもできたのだが、
正式手順ではないため、あくまでも自己責任でお願いします。

環境的には、Android Studio Chipmunkインストール済みの環境で、FlutterでAndroidアプリ開発を行なって、アプリをGoogle Play Storeにリリースまでしている環境。つまりそれまではUnreal Engineは入れてなかった環境にUnreal Engine 5 を入れた状態。(なのでAndroid Studio version 4.0とか古いものは入れたくなかった。)

よって、上記リンクで言うところの
1.Android Studio をインストールする
2. Android Studio を設定する (初回ユーザーの場合)
※2.10 Android SDK Command-line Tools についてもインストール済みだった。
はスキップして、
3. Setting Up Android NDK
から実行。
なお、mac上のSetupAndroid スクリプトの場所は以下。
/Users/Shared/Epic Games/UE_5.0/Engine/Extras/Android/SetupAndroid.command

【エラー①】
SetupAndroid.command  67行目あたりで、JAVA_HOMEを設定しているが、これがAndroid Studio 4の古い設定(Java 1.8用)になっている。新しいAndroid StudioだとJava 11。
export JAVA_HOME="$STUDIO_PATH/Contents/jre/jdk/Contents/Home"

対策①: 新しいAndroid Studioの付属jdkを既にJAVA_HOME環境設定に設定済みの場合
つまりprintenvで以下の結果になる場合
> printenv |grep JAVA_HOME
JAVA_HOME=/Applications/Android Studio.app/Contents/jre/Contents/Home

この場合は、単純にSetupAndroid.commandのexport JAVA_HOMEをコメントアウトすれば良い。
export JAVA_HOME="$STUDIO_PATH/Contents/jre/jdk/Contents/Home"
# export JAVA_HOME="$STUDIO_PATH/Contents/jre/jdk/Contents/Home"

対策②: JAVA_HOME環境変数が未設定の場合
この場合は、SetupAndroid.commandのexport JAVA_HOMEのパスを修正すればよい。
export JAVA_HOME="$STUDIO_PATH/Contents/jre/jdk/Contents/Home"
↓
export JAVA_HOME="$STUDIO_PATH/Contents/jre/Contents/Home"

※なお、SetupAndroid.commandを実行すると、
SetupAndroid.command: line 20: rem: command not found
が出力され、実際にスクリプトを見てみると確かにrem、つまりDOSコマンドの「コメントアウト」キーワードが使用されている^^ しかしエラーで止まるわけでもなくスルーされるだけなので気にしなくて大丈夫(後でEpicに教えるだけ教えておこう^^ Unreal Engine 4.x の頃からこのままだっただろうし、ずっと放置されてきたのだろうから、Mac + Unreal Engine + Android開発はものすごくマイナーなのだと、逆に知ることができるのである^^)

P.S. 2022.10
Unreal Engine 5.1.0 (現時点ではPreview版) にて、上記remは修正されました!よかったよかった👍
rem hardcoded versions for compatibility with non-Turnkey manual running
↓
# hardcoded versions for compatibility with non-Turnkey manual running


【エラー②】
上記修正をして、再度SetupAndroid.commandを実行すると今度は以下のエラーが発生。
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema

色々調べたところ以下のようにSetupAndroid.commandを修正すればよかった。
(83行目あたり) 
(修正前)
SDKMANAGERPATH="$STUDIO_SDK_PATH/tools/bin"
if [ ! -d "$SDKMANAGERPATH" ]; then
        SDKMANAGERPATH="$STUDIO_SDK_PATH/cmdline-tools/latest/bin"
        if [ ! -d "$SDKMANAGERPATH" ]; then
                echo Unable to locate sdkmanager. Did you run Android Studio and install cmdline-tools after installing?
                ${PAUSE}
                exit 1
        fi
fi

↓
(修正後)
#SDKMANAGERPATH="$STUDIO_SDK_PATH/tools/bin"
#if [ ! -d "$SDKMANAGERPATH" ]; then
        SDKMANAGERPATH="$STUDIO_SDK_PATH/cmdline-tools/latest/bin"
        if [ ! -d "$SDKMANAGERPATH" ]; then
                echo Unable to locate sdkmanager. Did you run Android Studio and install cmdline-tools after installing?
                ${PAUSE}
                exit 1
        fi
#fi

つまり、使用するsdkmanagerが違っていた問題。(これもJava 8 → 11 問題か)
$STUDIO_SDK_PATH/tools/binの方をコメントアウトして、追加で入れたCommand Line Toolsの方を使うように修正すればエラー発生しなくなった。

ーーー
エラー①のJAVA_HOMEについては、Windows用とMac用とで、JAVA_HOME環境変数の判定処理が異なっている。
Windows用(SetupAndroid.bat): 最初にJAVA_HOME環境変数が定義されてるかチェック
Mac用(SetupAndroid.command): 最初に強制的にJAVA_HOME環境変数を定義(export)

ただし、エラー②については、Windows用とMac用とで同じ処理内容だったため、エラー②の問題についてはWindowsユーザの方も参考になるかも知れない。
ーーー

【エラー③】
これで再度Unreal Engine 5 でAndroidのパッケージ作成( Platforms → Android → Package Project)を行うと、最後のapk作成部分で以下のエラーが発生する。
…
Making .apk with Gradle...
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/6.1.1/userguide/gradle_daemon.html.
Daemon will be stopped at the end of the build stopping after processing

FAILURE: Build failed with an exception.

* Where:
Settings file '/プロジェクトフォルダ/Intermediate/Android/arm64/gradle/settings.gradle' line: 9

* What went wrong:
A problem occurred evaluating settings 'app'.
> AFSProject/gradle.properties (No such file or directory)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

対応方法としては、上記* Where: に書かれているsettings.gradleファイルをエディタで開き、以下の修正をしてファイルを保存する。
new File('xxx')
↓
file('xxx')

※「new F」を「f」に置換すると簡単。
settings.gradleファイルでは「new File('xxx')」を使ってる箇所が8箇所あるので、8箇所とも修正する。

※Unreal Engineしか知らない人からすると「Gradle」が突然出てきて「何だそれは?」と思われるかもしれないが、AndroidとかJavaとか開発してる人からすると日常的にお世話になっているシロモノ。AndroidとかJavaに詳しい人に聞いてみましょう。

エラー内容としては、gradleで「new File('xxx')」の書き方をすると、ビルドフォルダからの相対パスではなく、gradleデーモンのワーキングディレクトリからのパスと解釈されてしまうらしく、よって「AFSProject」という親フォルダが存在しないので、「gradle.properties」ファイルも作成できませんよ、というエラー。
なお、gradleデーモンのワーキングディレクトリ及び実際に作ろうとしてたファイルパスは私の環境では以下だった。
/Users/user_x/.gradle/daemon/6.1.1/AFSProject/gradle.properties
よってこれを「file('xxx')」関数にしてあげれば、ビルドフォルダからの相対パスとして正常処理できるようになる。
※ただしこれもgradleというか、Android Studioに紐づいたgradleのバージョンの問題かも知れない。(流石に一度も動かないスクリプトを上げるわけないと思うのでAndroid Studio 4ではうまく行くのだろう。でもgradleバージョンによってnew File()の起点が変わるのは結構破壊的変更なので、gradleの環境周りとかもっと深い話かも知れない。要はその辺の微妙なところがバージョンの違いでうまく噛み合っていないっぽい。)

P.S. Gradleリファレンスで以下を見つけた。

やはりnew File()だとCurrent Working Directory(CWD)からの相対パスになってるとのこと。そうすると、Android Studio 4 バージョンだった時の可能性としては以下があげられる。
可能性①: 以前のgradleバージョンではnew File()もfile()同様、ビルドフォルダからの相対パスになっていた。(つまりどこかでnew File()の破壊的変更があった。)
可能性②: gradleバージョン差異の影響で、change directory(cd)が処理されておらずCWDが変更されてなかった。(特にエラーも発生せずに)。またはgradleのchange directoryの解釈が変わったりしてCWDとしては変わっていなかった。
可能性③: やっぱりAndroid Studio 4でもこの箇所でエラーになる^^(つまり一度も動いてないスクリプトだった^^)

可能性は絞れたが、ここではそこまでは追わない。。



次の手順が注意が必要であるが、上記修正&保存をしたら、ターミナルを開いて自分でgradleを動かしてあげる必要がある。
理由:UE側でAndroidのパッケージ作成( Platforms → Android → Package Project)を行うと、修正したファイルが毎回上書き更新されてnew File('xxx')に戻ってしまうため。ちょっとだけ追ってみたところ、該当settings.gradleはUE側のスクリプトで生成しているようです。
> cd /プロジェクトフォルダ/Intermediate/Android/arm64/gradle/
> ./gradlew assembleDebug
「assembleDebug」はデバッグ用apkを作成するタスク(コマンド)。目的に合わせてタスクは変えて下さい。タスク一覧は「./gradlew :tasks」で確認可能。どのタスクを使うとかはAndroid Studioの話になってくるので、Android Studioリファレンスを参照して下さい。

これで無事にapkが作成できた!ただしapk出力パスはUnreal Engineで指定した場所ではなかったため注意。私の環境の場合は以下になっていた。
/プロジェクトフォルダ/Binaries/Android/test_app-arm64.apk
※apkの出力先が異なっているため、手動でgradlewを実行する時のパラメータが足りてないかも知れない。assembleDebugしか試してないが、Play Store用にApp Bundleを作成する場合は証明書が必要となるため、その辺のパラメータもUnreal Engine側で設定した値は正常に引き継がれないかも知れない。ということで、App Bundle作成時はもっと複雑な問題が出てくると思われる。gradlewの引数を含めた実行コマンドが不明なので何とも言えないが、Unreal Engine側で動的に渡している場合は、もう人の手で補えるレベルのものではないかも知れない。(最後に結論として書くが、素直にAndroid Studio version 4を別途入れた方が良いかも^^)

これで、Androidエミュレータとか実機Android端末をつないで、adbコマンドでインストールすれば実行可能!
> cd /プロジェクトフォルダ/Binaries/Android
> adb install test_app-arm64.apk
Performing Streamed Install
Success

※ちなみにUnreal Engineでデフォルト設定でAndroidアプリ作って動かした時に「No Google Play Store Key. No OBB found...」エラーが発生する問題があるのだが、それはまた別問題なので、各種Q/Aサイトをご参照ください。



私の場合は、Unreal Enginの以下の設定をして上記エラーが発生しなくなり、アプリ起動に成功した。
Project Settings
 Platforms
  Android
   Package game data inside .apk? : Yes/Checked
   Disable verify OBB on first start/update. : Yes/Checked
   Force small OBB files. : Yes/Checked

 Project
  Packaging
   Full Rebuild : Yes/Checked
上記変更後は、Unreal Engine側で再度Android Package Projectが必要。そうすると、settings.gradleは毎回上書きされてしまうため、再度settings.gradleでエラー発生するので、「new File()」を書き換えて、手動でgradle実行となる。

もう一つの注意点としては、「adb install」する前に対象Android端末からは一回アプリをアンインストールしておいた方が良い。
(私は最終的に色々試したapkで、上書きadb installだとダメだったが、アンインストール後に全く同じapkで「adb install」したら正常起動できた。なので、Unreal Engine側の設定で一体どの項目がクリティカルだったのかは不明。)

こちらが実際にAndroid端末で動作したテストアプリの画面キャプチャー。黄色いでかいキャラクターは世界的人気ゲーム「ROBLOX」の「NOOB(ヌーブ)」です^^一体何のゲームを作ろうとしてるのか?って感じですね。

という訳で、無事にMac + Unreal Engine 5.0 + Android Studio Chipmunk でAndroidアプリのパッケージ作成が出来たわけだが、こんなに煩雑なことをするのなら、素直にAndroid Studio version 4.0 を入れた方が手っ取り早そうである^^という結論に達した。
(おそらく)Unreal Engine側としても最新Android Studio対応はしてくれてる/念頭にはおいてくれてると思うので、最新Andorid Studio連携はそれを待っても良いかも知れない。(最初に載せたリンクも「Unreal 4.25 以降は」となっているが、まだUnreal Engine 5.0 専用のページはない。)

ーーー
P.S. 2022.10 再度リンク先ページを確認したところ「Unreal 4.25 以降は」の表記が消えていた。そして内容はAndroid Studio 4.0のままだった。つまりUnreal Engine 5.0 ではやはりAndroid Studio 4.0のまま据え置く結果になった模様。。「最新Andorid Studio連携を待ったほうが良いかも」と書いたがUE5では可能性が薄れ、当分先になりそうなので、諦めて公式リファレンス通りAndroid Studio 4.0 を使いましょう!^^
ーーー


「どうしてもAndroid Studio環境を汚したくない!」という方は参考にしていただければ幸いである。(Unreal Engine側でNDKとか入れるので影響は少なからずあるのだが。。)

あと何点か、Mac + Unreal のマイナスポイントを上げておく。
・そもそもWindows用にパッケージ作成できない(ですよね?ちょっと調べただけだけど。どうしてもDirect Xの壁があるからそりゃ無理なのかな?逆にWindows版Unrealだとios版が作れる?ので羨ましい。)
・Unreal Engineライブラリで使えるものが少ない。ほとんどWindows用ばかり。UE5リリース時に話題になってた映画Matrixの「Cityサンプル」も、Microsoftの音響システム「 Project Acoustics」 もWindows版だけとか。せっかく「いいな」と思ったものを見つけてもMacだと試せない。。MacではNatiteは対応されていないし対応予定もないので、Cityサンプルを試すのはやはり無理っぽい。
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 より抜粋
※Mac環境&UE5.1 で影が以前より濃くなる現象に直面した。根本解決ではないが、とりあえずの回避策を見つけたので、こちらを参照。

ーーー
そして、こちらもそもそも話だが、ゲームを「遊ぶ」側としてもEpic Games StoreのゲームはWindows版ばかりである。

ということで、本格的にゲーム開発する人は当然Windowsマシンで開発するのだろう。
「Windowsのゲームを本格的に開発したいので、Macを買いました」という人がいたら「なんでそうなるの?」となるだろう。
ゲーム + Mac + Unreal はモバイルゲーム開発とか、またはMacが好きでMac用ゲームを作りたいとかのパターンが考えられる。しかしこれも現時点での私個人の主観でしかないし、最近ではモバイルからPCへの逆パターンもあったり、MacからWindowsとかの流れもなきにしもあらずだと思う(少なくともJavaのEclipseとかか始まり、今ではAndroid Studio然りUnityやUnreal Engine然りというように「IDE」はWin&Mac両対応が当たり前になっている)ため、これもまた自己責任でこの辺の動向はウォッチしていって自分に合ったやり方・環境を見つけてくれればと思います。
(会社とか組織規模で考えれば、会社内にWindowsマシンもある訳で最終的なapk(aab)出力はWindows環境でやれば良い訳で、別にMacでapk(aab)出力を出力することにこだわることはないのかも知れない^^
と、そこまで話が遡ってしまうと、今回の話も、またUnreal EngingeがMac用にもAndroidパッケージ出力方法(手順)を作っている意味も無くなってしまうので、私も含めて「それしかない環境」でやっている人もいる訳で、また大きく言えばプラットフォームの(純粋な意味での)垣根を越えるという点に寄与しているという点において、意味はあるのであろう。※「純粋な意味での垣根を越える」とは、お互いにWin-Win関係になれる、という意味。
ちょっと湾曲的すぎて何を言ってるのかわけがわからないと思うので、簡単にいうと「クリエーターからするとEpicとAppleの訴訟なんて知ったこっちゃなくて、せっかく素晴らしい3DCGエンジンがあるのだから、グラフィックとかアート分野に強いMacでも使わせて欲しい!」と言ったところだろう。それこそFortniteとかちゃちい話(失礼!)ではなく、Win-Winになれると思うのだが。。
かと言って、実際問題としてこのように影響があるのだから、訴訟の話も無視するわけにはいかず、話はぐるぐる回るわけである。。)