• UnityRecorder で録画した MP4動画が、何故赤味がかるのか何となく分かった話

    2020-10-28 08:32
    ※本稿にはしきりと YUV だの YCbCr だの、ColorMatrix だの BT.709 だの、MP4 に関する専門用語が飛び交いますが、本人はよく分かっておりません。理解不足や書き間違いが幾つもございますでしょう。この件に真剣に取り組みだしたのは約2年前の話、しかも一旦放棄してほとんど忘れ、勉強再開したのはおとといの話です。したがってさもありなん。ご了承ください。
    ※結論だけ知りたい方は、各項の太字を追っていって下さい。

    ■現象と問題点


     Unity で作った 3D グラフィックスの出力結果を、動画として保存したい。
     オフィシャルに用意されている Unity Recorder を使ってみたのだが、MP4 動画にすると、どうも赤みがかる。それも、ちょっとやそっとじゃない。
     (※本稿を書いてる最中、録画すると縦に少し伸びるのも発見してしまった・・・もういや!w)

    UnityEditor の GameView をデスクトップキャプチャしたもの。この色で出て欲しい
    (ブロマガ容量の制約により、やむなく PNG→JPG に変換し劣化してます。あしからず)

    RenderTexture にレンダリングし、UnityRecorder で MP4 に保存。赤い
    VLC media player で再生し、デスクトップキャプチャしたもの(同上)

     下の画像は、Windows7+Unity 2018.3.7f1 に、PackageManager から UnityRecorder 2.2.0-preview.4 を入れて撮ったもの。なお、Unity2020+2.3.0-preview で取り急ぎ試したところ、状況は変わっていない模様。

     こちらの再生環境に問題があるわけではなさそうだ、ということも分かっている。Windows Media Player でも同様になるし、FFMPEG でフレーム切り出しなどしても同じ結果になる。
     Android 端末の MX Player や、MirageSolo (Androidベースの VR端末)でも同じような色合いになるので、俺の PC 固有の問題でもない。(あくまで、再生側としては)

     この件に言及している人は見つけられなかった。日本語サイトでは「ちょっと使ってみました」ぐらいの情報しかない。
     「赤味がかる」というのを英語でなんと言うのか分からないので、英語サイトは調べ切れなかった。「録画できない」とか「落ちる」というのは見つかる。メモリ不足などで、俺もそういうことはある。でも欲しい情報はそれじゃない。

     ただひとり、この方は「SD解像度で色がおかしくなる」という報告と分析をしている。HD解像度の方は問題無いようなので、そうすると俺環の問題である可能性が高くなる。
     つまり、UnityRecorder そのものというより、UnityRecorder が依存している、俺の PC にインストール済の何かがおかしいというあたりに絞られてくる。SDで保存する場合におかしくなるのも、同じ部分に原因があるのかもしれない。

     この件には、大分前に既に遭遇していた当時はひとまず下記の解決策1・2で手をうったし、現状でも1がベストな解決方法だと思う

    ■解決策1:PNG/JPEG連番画像出力からの FFMPEG

     UnityRecorer には PNG or JPEG の連番画像を作る機能もあり、そちらの色合いは問題ない。それを FFMPEG にくわせてやりさえすれば、満足いく動画が作れる。画質も、MP4 を直接作るよりキレイだったりする。PNG はもちろん JPEG の場合でも。(これを行なうためのFFMPEG のコマンドは、過去のエントリを参照

    ■解決策2:WEBM出力


     UnityRecorer の出力を WEBM 形式にすると、色合いは正常になる。画質は低いが、プレビューするには十分だ。ただし、当方の環境では管理ソフトでサムネイルが表示できないなど、別の問題が発生してしまう。

    ■解決策3:FFMPEGで 無理やり補正


     最近になって、なんかフツフツと気に食わなくなってきたので、ほかの解決策を模索してみた。だって、MP4 で直接出力するほうがディスク容量をくわないし、一次出力時に時間がかからないしで、楽なんだもの。

     UnityRecorder がエンコード時に使った、もしくは FFMPEG がデコード時に選択した RGB←→YUV の ColorMatrix がおかしいのであろうから、FFMPEG で ColorMatrix を任意に選択し、強制的に補正してみる。例えば、以下のように。
    ffmpeg -y -i UnityRecorderResult.mp4 -vf colormatrix=bt709:bt470 -x264-params colormatrix=bt709 -c:a copy output.mp4
     これで、1)FFMPEG のデフォルト動作どおり BT.709 として RGB に変換し、2)BT470 の ColorMatrix で YUV にし、3)「これは BT.709 です!」と偽って mp4 に書き込む。・・・という動作になる。多分。
     これをやったからって到底正しい色になるわけじゃないのだが、ちょびっとは赤みが取れる。これでいいかぁ・・・と思いかけたけど、諦めきれない。

     だって本当は、bt709:bt470 じゃなくて、hogehoge:bt709 という形で直すべきなのだ。hogehoge とは何なのか、すなわち、UnityRecorder による動画保存時、どんな ColorMatrix で RGB→YUV 変換がなされているのか。というのが本稿の趣旨でございます。

     これをつきとめたからって、結局連番画像から作るのがベストなことには変わりなさそうだけども、気に食わないことは解決したい。それが楽しくてやっている。

    ■経緯その1・MP4ファイルの中身を探る

     問題の MP4 ファイルを FFMPEG や MediaInfo、バイナリエディタなどで解析してみる。すると、以下のようなことが分かった。

      ・YUV データのエンコード形式は yuv420p である
      ・エンコーダは "Microsoft H.264 Encoder V1.0 for Windows" である
       (じゃあこいつ周りがおかいしんじゃねぇか・・・・?)

     こんなもんである。あとは、1280x720 だの 30FPS だの、言われんでもわかっとることしか出てこない。ColorMatrix 云々はすべて、表示されない、または "Unknown" となってしまう

     えぇー、でも本当にそうかぁ?

     結局自分で確かめなければ気がすまなくなり、H.264 の規格書(ISO/IEC 14496-10)や、解説サイトを幾つもめぐり、勉強した。
     一番大事なのは、後述する規格書でいうところの matrix_coefficients のはずだ。
    matrix_coefficients describes the matrix coefficients used in deriving luma and chroma signals from the green, blue, and red primaries, as specified in Table E-5.
     これは moov/trak/mdia/minf/stbl/stsd/avc1 下の、avcC 中に記載のある Sequence parameter set (SPS)の中の、VUI parameters の中で指定されているはずだと思うのだが、本件のファイルの場合は video_signal_type_present_flag が 0 であるゆえ、すなわち指定が無い。
    When the matrix_coefficients syntax element is not present, the value of matrix_coefficients shall be inferred to be equal to 2 (unspecified).
     っちゅーこって、かくして、ColorMatrix を作るための KR, KB は不明なまま終わったのであった。長らく時間をかけて、FFMPEG/MediaInfo が正しいということを確認しただけになってしまった。

     徒労には終わったが、使った各種資料は大変有用なのでリンクを張っておきます。興味ある方はどうぞ。

     何でしょうコレは。規格書草案? 上記はこの PDF の p.356 近辺の話です。
     http://ip.hhi.de/imagecom_G1/assets/pdfs/h264_iso-iec_14496-10.pdf

     MP4用バイナリビューア
     https://github.com/suzutsuki0220/Mp4Reader

     各box (主に moov 下) の読み方
     https://www.cimarronsystems.com/wp-content/uploads/2017/04/Elements-of-the-H.264-VideoAAC-Audio-MP4-Movie-v2_0.pdf
     
     avcC の読み方などはここも参考になります
     https://mntone.hateblo.jp/entry/2013/09/03/180431

     パーザ実装例
     https://cobalt.googlesource.com/cobalt/+/COBALT_4/src/media/filters/shell_avc_parser.cc

     ゴロム符号化。これがわかんないと SPS とか読めない
     https://ja.wikipedia.org/wiki/%E3%82%B4%E3%83%AD%E3%83%A0%E7%AC%A6%E5%8F%B7
     https://en.wikipedia.org/wiki/Exponential-Golomb_coding

    ■経緯その2・yuvデータを取り出す

     ならば結果から逆算して、自分で ColorMatrix を再現してみようではないか
     VLC や FFMPEG が出力した、結果としておかしい RGB色ばかりをあてにしていたのでは心許ない。MP4ファイルに記録された、直接の YUV値も知りたい。FFMPEG で以下のようにすれば取れる。
    ffmpeg -i UnityRecorderResult.mp4 -c:v rawvideo -pix_fmt yuv420p output.yuv
     これは実際には、MP4内の YUV値を一旦 bt709 か何かで RGB に変換して、もっかい YUV に変換しなおしたもんなんだろうと思うのだが、まあ、それでも良かろう。何でも、試してみなきゃはじまらない。

     出力された .yuv ファイルがいかなるバイトストリームなのか、にわかには分からなかったので、デコーダを作成しがてら探ってみた。

     ファイル先頭からフレーム毎に順に出現し、各フレームは Y, U, V の各プレーンの順に出現する。プレーンは左上を原点として X 方向のスキャンを繰り返す形式。1280x720の動画の場合は、Yプレーンについては 1280バイトを 720回繰り返す。U,V は、yuv420p の場合は縦横 1/2 の縮尺となっており、640 バイトを 360回繰り返す。読み込んだ U, V プレーンは補完なしでアップコンバートすればよい。

    こんな図を書いてる暇があったら解説サイトを探した方が早い気がする
    記事書くときだってリンク張りゃ済むし

     っつーことで、ビューワができた。単一フレーム読み込むだけだけど。Java で、しかも1pixel 毎にシークするから、馬鹿みたいに遅いけど。できたはできた。

    ホントだこりゃ赤い

     FFMPEG や VLC の動作結果と同様になることを期待し、BT.709 の ColorMatrix を使ってみた。案の定、こちらも、赤みがかかる。動作確認完了だ。

    ■経緯その3・yuvデータをつぶさに見る

     Uniちゃん動画だと分かりにくいので、Unity で真っ赤 (0xFF0000) な画像を表示し続け、それを録画したVLCで再生したものをキャプチャして確かめてみると、真っ赤ではなく 0xE60000 になる

    真っ赤だなー(違うよ) 真っ赤だなー(0xE6だよ)

     FFMPEG で .yuv に変換し YUV値を探ってみると、それぞれ10進数で、41, 110, 240 となった
     バイトストリーム中の画素データは 0~255 フルレンジの場合と、そうでない場合がある。MPEGの YUV は、通常は後者だということなので、以下の変換式にあてはめた上で、実数値になおしてみた。
    Y : 41 → Y = (41 - 16) / (235 - 16) = 0.11415525114
    U : 110 → Cb = (110 - 128) / (240 - 16) = -0.08035714285
    V : 240 → Cr = (240 - 128) / (240 - 16) = 0.5
     Y = 0.114。(ここで心が大いにざわめく。0.114 ってよく見るぞ・・・)

     何だかもう既に原因が分かりかけているが、ともかくとして、これを ITU-R BT.709 の ColorMatrix に入れてみる。下記変換式のうち、一番下のものだ。

    出典:Wikipedia
    R : 0.9015552511
    G : -0.1048539274
    B : -0.0349554631
     となった。負だってだけならまだしも、-0.1 とかになったりするもんかね? と思いつつも、得られた RGB値を 16進数に置き換えてみると、0xE60000 となる。うむ。VLC の表示と合っている。

     さて、ここからが問題の核心だ。

     大元の画像は (R, G, B) = (1, 0, 0) なんだから、上記の変換式のいずれかを使えば、Y は 0.299 や 0.2126 だのにならないとおかしいのだ。たとえ記録データの値域がフルレンジだとしたって、41/255 = 0.16078431372 だ。合わん。
     つまり RGB→YUV 行列の左肩ってのは KR のことでしょう?
    UnityRecorder が未知の ColorMatrix を使っていたとしたって、0.114 だなんて、いくらなんでもおかしいそんなの見たこと無い。

     ・・・あるわ。PAL だの BT.601 だのの変換式にあるぞ。しかも KB じゃないか、これは。


     さては、KR と KB を取り違えたんじゃないか?!

     ためしに、自作デコーダの ColorMatrix をいじくってみよう。
     BT.601 に倣い、KR = 0.299、KB = 0.114、ならぬ、KB = 0.299、KR = 0.114 で試してみる(行列のほかの値はここにあるような数式で出せます)。

    うぁ、かあいい

     ほれ見ろ、ちゃんとした色で出たじゃねぇか!

    比較用画像はこちら。左が BT.709 での色変換、右が「間違えたBT.601」での色変換

    別のアプローチでの検証。Shader Graph で各種動作をシミュレートし、
    実際の動画再生時のキャプチャ画像との差分を取って確認

    ■結論のようなもの

     というわけで、以下のようなことが分かりました。

    原因:

     UnityRecorder、もしくは Microsoft H.264 Encoder V1.0、あるいはそれらが依拠する、俺の PC内にインストールされたなんらかのプログラムの実装においては、BT.601 の規定による ColorMatrix が使われている。(今回の例のように、1280x720であってもです)

     ただし、計算においては KR、KB が逆転してしまっている。
     なお、B と R を逆にした状態で YUV に変換し、U と V を逆にした状態でエンコードした場合も同じ結果になるようだが、はたしてどっちがどのくらいありえるのだろうか? 俺としては、単に何かのプログラムのどっかのソースで書き間違えただけだと思うのだが・・・。

     これを、VLC media player や FFMPEG が、デフォルト動作として(720pの動画であるので)BT.709 の ColorMatrix で正しくデコードしたため、全体的に赤みがかってしまうことになる。

    有効な対策:
     ありません。

     というのは乱暴なので、もうちょっと考えてみましょう。

     UnityRecorder の設定変更は? できません。Microsoft H.264 Encoder への設定は? そもそも何者だかよく分かりません、情報が少なくて・・・。この辺のアプローチは俺にはまったくできまへん。

     俺の PC に何か変なものがインストールされている? 何かを除去すれば解決するかもしれない。そう言えば ffdshow が入ってるけど、これは基本的にデコード用でしょう? VFW ってのがエンコードもやるみたいだけど、動いている間はタスクトレイにアイコンが出るはず。UnityRecorder の動作時にはうんともすんとも言いません。他には思い当たりませんなぁ・・・。
     ただ、前述のリンク先の方は、HD動画では正常に動作している。Windows7 だからだめとか、SDK が古い・おかしいとか、そういうことかもしれない。

     FFMPEG で修正できる? ちょっと無理そう。だって、BT.601 で、かつ誤ってデコードしなければならないんだぜ。できるかぁ? そんなの。既存の ColorMatrix から選ぶのはできるけど、カスタムなものを指定するようなオプションは無いんじゃないかな。
     MP4 ファイルの中身をいじくって、カスタムな ColorMatrix を設定する? 多分できない。前述のリンクの規格書草案? の Table E-5 : Matrix coefficients を見る限りでは、こちらも限られた選択肢から選ぶしかない。
     あとは FFMPEG のソース改変くらいだな。まあできなくはないけど、コンパイル環境から用意せな・・・最後にそんなのやったのって、Fedora セットアップした 10年前だよ。面倒だよ~。

     あとは、ポストエフェクトであらかじめ逆算するような方法か。つまり、あらかじめ BT.709 で YUV に変換し、さらに、間違った BT.601 で RGB に変換したものを、最終レンダリングとする。んでそれを録画する。
     ちょっとやってみたんだけど、あんまり上手くいかない。
     本来やらないはずのおかしな変換をしているものだから、途中で、0.0~1.0 を超える値になってしまう。でもおそらく、UnityRecorder はエンコーダに渡す前に clamp してしまう。それが結局、元の色の再現を不可能にしてしまっているようだ。

    ポストエフェクトで、正しい RGB→YUV、間違った YUV→RGB をやる。
    結果、ちょっと緑味がかるが、何か弱い

    完成した動画を見ると・・・まぁ・・・うーん
    もうちょっと黄色いのが正しいんだよなぁ

     つーわけで、はい、連番画像がベストです。おしまい。

     苦痛だったけど、解放された。だから残った印象としては「楽しかった」んだけど、本当にこの人生は「幸せ」なんだろうか。んーまあいいか。Uniちゃんかわいいし。
  • 広告
  • ファーミングシミュレーター19、なかなか面白いけど二度とやらなそう

    2020-10-17 22:24
    何故ならチュートリアルで詰んだから。
     いや、それならまだいいかもしれない。あれ?と思ったらすぐやり直せばいいだけだから。
    俺が遭遇したケースでは、チュートリアルで詰んだのに、6時間もの間、それに気づかなかったから。まかり間違えば数十時間はまりにはまって、それで詰んでかも知れない。危ないとこやで。
     でも土曜が消えたなぁ。ゲームって、本っ当、馬鹿馬鹿しいよね。でもやっちゃうんだ、馬鹿だから。

    ■チュートリアルと罠・1

     車に乗ってないときは、FPS視点。畑の傍らに突っ立った状態で始まり、指定されたポイントに歩いていくところから始まる。
     俺のカメラ視点操作は、普段Yリバースなので、オプションで変更。
     ここで罠!
     オプション画面は、以下のように行・列状に並んでいるが、安易に左右の項目に移動しようとしてはならない。項目変更は上下操作のみ。最下行で下を押すと、右の列に移動する、という形式。左右操作をすると、オレンジ部分の入力になり、オプション内容が変わってしまう。



     左上項目の「ヘルプウィンドウ」をオフにしてしまうと、操作説明が一切でなくなってしまう。俺は右方のカメラ操作の項目に移りたくて、ついここを触ってしまっていたらしい。しばらく操作がわからず戸惑った。
     こんな風に並べるなら、「上下左右で項目選択、○ボタンでモーダルダイアログ出して、上下 or 左右で設定変更して、○ボタンで確定」でいいのに。それができなきゃ上下にのみ項目並べりゃいいのになぁ。たまにこういう、画面構成と操作方法がちぐはぐな作品がある。

    ■チュートリアルと罠・2

     □ボタンで車両に乗車。各車両は、必ずしも何かの専用というわけではなく、アタッチメントによって能力が変わる(Mud Runner のシステムと似てる)。車両に乗っているときに、○ボタンでアタッチメントの付け外しをする。
     ここで罠!
     耕運機等の場合、リアに機械(耕す奴、種を植える奴など)、フロントにバランス調整用のウェイトをつけるスタイルになる。
     ウェイトを誤って外し、さらに車両で蹴飛ばして転がしてしまうと、金輪際装着できない。しつこくしつこく車両で転がし続け、向きを直すことができれば装着できるが、どうしてもだめなら敷地外へでも蹴り飛ばそう。

    しかも、チュートリアルの場面では未装着状態で始まるため、
    前後両方を○ボタンで装着してから作業開始しなければならない。
    さもないと・・・


    突き転ばして角度が変わると装着できなくなり、石ころと同じになってしまう。
    プレイヤーが拾い上げることもできない。
    ただし、「ガレージに戻す」的なリセット操作は、実はあるかもね?

    ■チュートリアルと罠・3

     L1+何かのボタンで、機械の何かが動作する。大体において「スイッチを入れる」をしたあと「降ろす」をすれば、準備OK。あとは畑をまっすぐ走ればよい。走ったところが耕されたりする。正しく作業できていれば、見た目が変わる。早い話が、「車ブラシで畑領域を丁寧に塗り潰す」操作をしていく。
     ×ボタンを押して、作業員に交代することができる。そうすると、作業中の機械がオート運転になる。畑全部を自動で塗り潰すまで、作業を続けてくれる。同時に作業できるのは2名まで。
     ここで罠!
     畑を耕す作業中に折り返すとき、畑の外を耕すと機器の損耗につながるのかも?と思い、 機器を浮かすようにしてみた。その際には L1+×を押すのだが、そういうことをすると「×=作業員交代の操作」と誤判断されるくさい。存在しないはずの作業員について「作業が終了しました!」というメッセージが出る。
     ただ、このメッセージが出ても作業員達はちゃんと仕事を続けており、「そっちは中断してこっちやってくれよ」的な指示にならないようなので大丈夫そうだが、いかんせん不安で、いちいち確認しなきゃならない。
     左右ボタンで他の作業員の状況を見れるのだが、「作業員を見る」のではなくあくまで「車両を見る」操作なので、たった2名の作業員の状況を見るために、初期所有の5台の状況を順送りにしていく必要がある。所有する車両が何台も増えたあとだと、すんごいメンドウそうだ。従業員も増やせるかも知れない。そうなるとますますめんどう。
     自ら作業している際は、L1+×なんぞ押さず、黙って畑の外を耕したり、畑の外に種を植えたりするほうが精神衛生上いいみたい。

    ■チュートリアルを終えて(終わってない罠)

     収穫、耕し(熟語で何ていうんだろう)、種蒔き、まで終えて、次は敷地外への運搬と売却に移るのだと思うのだが・・・
     ここで今回最大の罠!
     俺がプレイしたときは、「ガイドツアー」(チュートリアル)の表示はプッツリと途切れてしまった。あるいは、それとは気づかず○ボタンで飛ばしてしまったのかもしれない。
     次に何をしたらいいのかまったく分からなくなった。
     しょうがないので、すべての畑を耕し、すべての畑に種を蒔き、そしていよいよ何もすることが無いので、メニューを見て、他の畑の収穫作業のクエストを受けてみた。
     ここでいよいよ詰んだらしい。しかし俺はそんなこととは露知らず、このゲームがだんだん楽しくなってしまったのだった。

    ■面白さの話

     要するに、分業の面白さである。

     自分の畑にせよクエストで受けた他人の畑にせよ、まずは車両にアタッチメントをつけ、現地に向かい、作業に手をつけ、即座に作業員に交代する。
     現有する残りの車両およびアタッチメントで作業可能な畑を探し、また同じことをする。これで、作業員2名がそれぞれ稼いでくれる。

     そうしたら、プレイヤーは自分にしかできないことをやる。例えば、収穫した作物をトラックに積んだら、「エレベーター(訳はあってるのかな?)」「レストラン」「大牧場」など、売却できるところに運んで荷降ろす。クエストの場合は指定された売却箇所に持っていくことになるが、自分の畑の作物は、相場表を見て、一番高く買ってくれそうなところを選べばよい。(※俺が気づかなかっただけで、これもオートでやってくれるかもしれない)

     作業員+車両という貴重なリソースをできる限り休ませることなく最大限活用することができれば、より稼げるわけだ。

     前に数百時間はまった The Long Dark では「俺と焚き火の分担作業」がとっても大事だったし、こないだまで、ほぼ毎日3~8時間ぐらいづつ Satisfactory で遊んでいたのだが、あれも同じような感覚だった。同種の Factorio でももちろんこれが大事だった。
     「ああ、また分業の楽しいゲームを見つけたぞ」とニヤニヤしながら没頭していった。

    ■面白くなさの話

     しかしねぇ、そうなるとプレイヤーの主たる業務は、農作業じゃなくて、車両配送と運搬になるんだな、これが。
     
    まあ、運ぶものが無いときは自分もどこかで農作業すればいいんだけど、少なくとも俺が見た範囲では、この作品の農作業は「几帳面な動き」を淡々と行い、「畑の端で車両の切り返しを手早くする」だけのゲーム性なのよ。ちゅーかそれはゲーム性というか競技性だね。
     反面一番嬉しいのって、上手く操作できたときじゃなくて、持ってった作物を売って、右上の財産パラメータが上がるとき。
     ゲームタイトルは農業。でも主にやるのは配送・運搬。操作として好きなのは畑での農作業時じゃなくて、公道での運搬時。そして一番嬉しいのはアクション操作ではなく経営シミュレーション要素。

     色んな楽しいものが詰まっているけど、なんかちぐはぐで、互いに連関していかない。こういう作品に出会うと、「個別にそれぞれ特化したゲームをやるべきじゃないの?」と思ってしまう。
     ついつい「車だったらウォッチドッグス1でカーチェイスしたほうが楽しいんじゃねぇか?」「運搬・配送ねぇ、自分でやるなら Mud Runner のほうがいいな」「あるいは誰かにやらせたいなぁ・・・つーか Satisfactory でボーキサイト自動運送システム組んで遊ぶか?」「農業・分業ねぇ。DQビルダーズ2でモンゾーラの村拡張するか?」などつらつらと・・・。 

     プレイ開始後2~3時間、それに気づき始めたあたりで、もう楽しさの限界が見えてきてしまった。ただ、それでもまだそこからしばらく、「効率のよい仕事の分担」について突き詰めようと考えていた。
     例えば、自分の畑を耕している最中、収穫用の機材が余っているのに、他人の畑のクエスト一覧は「耕す」ばっかり。そんなら、耕すアタッチメントをもうひとつ購入すればよい。ようし、稼ごう、買おう、そして対応できる仕事を増やそう、・・・あ、楽しそう。
     あるいは、他の仕事に手を出してみるか。肥料撒き、枯草積みなど、いろんな仕事や車両、
    アタッチメントがあるらしいのだが、とりあえず元手の一番かからなそうな運び屋を選んでみた。

    ■詰んでいたことが発覚

     運び屋の経緯は省く。フォークリフトを使う必要が生じ、しかし買う金が無いので、レンタカー。作業後に返却しようとした、そのとき。事件は起こった。いや、起こっていたのだ。

    「ガイド付きツアーを終わらせてください」
    (※売却と返却は同じ画面で行なうので、この場合も「売却」と出るらしい)

     えっ。チュートリアル、まだ続いてたんか。
     しかしマップ上にも画面上にも、もうかれこれ6時間以上、そんな表示は見てないぞ。

     通常この手のゲームの場合、クエスト欄にチュートリアル用の特別クエストがあったりするもんだが、本作にはそんなのないっぽい。また、左上にやらなければならないことが出る作品もあるが、そんなのも無い。
     チュートリアルの最中にレンタルができるなら、返却もさせぇよ。返却がだめならレンタルさすなよ。つーかチュートリアルの最中にクエストが受けれるのも変じゃないか?

     そこではたと思い当たった。最初のクエストで受注した「収穫作物の配送」、そういや配送先に緑色の印があった。あれはクエストの目的地ではなく、チュートリアルの目的地だったのでわ。
     チュートリアルと通常クエの両方に「配送完了によるフラグ処理」があり、それがバッティングしてしまい、通常クエで上書きされ消滅したのでわ。
     つまりおそらく6時間前、通常クエを受けた時点で、チュートリアル完遂不能になっていたのだ。たぶん。

     もはや終了せざるを得なくなった。だってそうだろう、これから先、色んな仕事を請けようと思って何か車両をレンタルしたら、それ以降永遠に借り続けなければならない。そんなの効率悪いに決まってる。だから、がむしゃらにお金を稼ぐか借りるかして購入しなければならない。ええそれも苦しいなぁ。未経験の仕事は、軽くお試しで請けたりしたいよ。
     そして、これはまだ氷山の一角だ。この状態でこの先、他の件で「まず終わらせてください」と言われない保障なんてないんだ。

     そしてさらに・・・チュートリアルを省くなどして通常プレイを続けてみたところで、また同じように「何かで詰む」可能性がある。コンピュータソフトウェアというのはそういうものだ。 その疑念が生じたら、おしまい。

     今回の6時間は、まぁまぁ楽しかった。次にやりなおしても、多分また、数時間楽しめると思う。でも、別のゲームをやっても同じかそれ以上楽しいのは知ってるので、多分、やらないかな。
  • ShaderGraph でコントラストを調整する方法3種

    2020-09-22 17:31
    本記事内での Shader 作成環境:Unity2020.1.6f1、HDRP 8.2
    (サンプル画像は Unity2018.3.7.f1、HDRP4.10.0-preview で作成)

    ■しょーもない理由


     Uniちゃん達は、MOD のファイルをそのまま使うと、どうにもお目目が薄い。sRGB にわざとチェック入れたり、Specular 設定してみたり、いろいろごまかしていたのだが、どうにも納得できない。今度はコントラストを調整してみることにした。
     レンダリング結果をフィルターにかけるのではなく、単に Diffuse テクスチャを調整するだけなんだから、フォトレタッチソフトで加工すればいいだけのことなのだが、変更前後のリソースがプロジェクト内外に点在するのが嫌なので、シェーダーで解決することにした。

     リソースの個数が増えるのがいやで GPUコストをかける・・・本末転倒!

    ■方法その1:Shader Graph の Contrast ノードを使う
     


     マニュアルによれば、パラメータが 1.5 の場合は以下のように変換されるらしい。

     お手軽。軽コスト。でも俺の欲しいのとは違った。たしかに虹彩の色は鮮やかになるんだけどさ、なんかカッスカスになっちゃう。

    濃いけど薄い

    ■方法その2:シグモイド曲線を使った Sub-Graph を作成する

     単純なトーンカーブでいいんだよなぁ。x = 0.5 を中心として動かさず、点対照で、S字状のカーブにしたい。そんな曲線無いんかな、と思って探したら、シグモイド関数を使えばいいとわかった。三角関数でも似たようなのができそうだけど、パラメータ調整できるようにするにはどうすれば一番いいか、思いつかなかった。


     上記はひとまず -6 ≦ x ≦ 6 範囲を 0 ≦ x ≦ 1 に収まるようスケーリングしたもの。さらに上下にもスケーリングしなければいけないし、パラメータ調整も可能にしたいのだが、面倒くさくなってきた。

     ここまでは手探りでやってたんだけど、たまたま、実践しようとされている方のページを発見。⑥項末尾の数式をパクらせていただいて、Shader Graph に起こした。盗みだ盗み。

    誉れはシグモイド曲線で死にました

     ごちゃごちゃしてるけど、こんな程度で重くはならない。


     これこれ。この感じ。これで満足できた。

     パラメータ 6。ちょっと濃すぎたかも知れん


    パラメータ 4。こんなもんかな?

     ちなみに、Sub-Graph の結果プレビューを2Dにしたいんだが、何かできないっぽいな。

    ■方法その3:カスタム曲線を使う Sub-Graph を作成する

     ものすごくバカバカしいので、早足で。テキストソースも載せません。
     まず、以下のような EditorWindow を実装。

    未完成。あちこち雑なので、真似しても危ないですよ

     すると、指定した RenderTexture にトーンカーブ情報を書き込むエディタが作れる。


     256x2 の RenderTexture を指定して save するとこうなる。
     

     R, G, B 各チャンネルの輝度を u にしてこのテクスチャからサンプリングすれば、トーンカーブ適用後の輝度が得られる。それをば Sub-Graph として作成。
     

     で、各チャンネルを変換して Combine。



     できた! これもいいね! プロジェクトにリソース増えるから使わないけどな!