という事で、こちらの商品、注文しちゃっておりました。

JPEGのみとRAW+JPEGの二つの保存形式を選べるこのカメラ。JPEGのみの設定で撮影するつ出力されてくる画像のサイズは6720x3360となり、これはTheta Vの5376x2688よりもだいぶ大きくなるわけですが、これをRAW+JPEGで撮影した時のRAWファイルにおいては7296x3648にまで拡大されます。

まぁこのサイズってのは魚眼レンズで撮影された二つの像をつなぎ合わせて長方形にした時のサイズなので、厳密にセンサーの画素の一つ一つが（大雑把に）ピクセルの一つ一つに該当するわけじゃないのですけど、出力されてくる画像のサイズとしてはそんな感じ。Vと比べるとかなり大きくなります。

この2枚はRAW+JPEGで撮影した時に出力された画像で、RAWの方はLightroom Classicでスティッチ処理をかけています。参考までに同ポジでTheta Vでも撮影してみました。それが下。

とても縮小しているものですから違いがわかりにくいので真ん中辺を切り抜いたものが以下となります。

これだと違いがわかりやすいのではないでしょうか。サイズが違うのはピクセル数ベースではなく範囲ベースで切り抜いたためで、同じものを撮ってもこれだけピクセル数が違いますという例ともなりますかね。Z1のJPEG出しはVに比べると明らかにディティールが増しています。レンズ性能もさながらセンサーサイズの拡大が効いているのでしょう。けれどもカメラ内でスティッチ処理をされており、処理を軽了解するためなのかフィルタ処理が強めにかかっているように見えます。で、RAWで出てきたものを適当に現像したものですとよりディティールが救えているように感じられますね。

ちなみにRAWで出力された画像は以下のような状態です。

それぞれのレンズで捉えた画像がそのまま記録されている。これをLightroom Classic用のリコーが出しているプラグインを使ってスティッチをしています（処理自体はほぼ自動です）。余談ながらLightroomはLightroomとLightroom Classicの二種類がAdobe Cloudから配布されています。LightroomのプラグインではなくLightroom Classicのプラグインであることには注意が必要ですね。Photoshop用とかAppleの写真.app用とかも出して欲しいです。

日が落ちてちょっと暗くなった環境での結果。RAWの像がぼやっとした印象になっているのは適当に現像したからなのだと思われますが、つまりはこれぐらいの素材になってくるとRAWの現像処理の腕の差が顕著に効いてきそうです。Adobe senseiによるディティールの強化は使っていないので、それを使えば素敵に仕上がりますかね？

以下flickrにあげた画像です。

Vで出力された画像をflickrにあげると、360度表示された時にちょっとがっかりする画質になるんですけど、かなりマシになっていますし、かなり素材として使えるデータを得られるようになってきたのではないでしょうか。

動画については4K 30pなのでそれほど期待はできないですかね。HDで鑑賞するにしても8Kぐらいは最低限必要なんじゃないかって思います（そんな意味でZ1の静止画が8K近いサイズなのはようやく使えるようになってきたと言えるのかもしれず…）。それでも、レンズ性能・センサー性能の向上でVよりかはマシになっているのでしょうか。

ちなみにFCPXで360°の状態で編集ができるのだけど、それをマスターとして書き出してCompressorでYouTubeにアップロードするのに実用的なサイズにエンコードすると画質はちょっと劣化します（上図で細かい情報が失われているのがよく見ると確認できる）。

さらについてでに、FCPXでマスターで書き出す時、eGPUをちゃんと使ってくれますな。Compressorはほとんど使ってくれませんが。

THETA Z1 19.05.25

ので、取り急ぎ昼飯ついでに一枚撮って来ました。

こっち↑じゃなくてこっち↓

とりあえず画質は雲泥の差？ってことは感じられました。上図左が新しく届いたもの。右が似たような位置で撮影した昨日までのリコーのフラッグシップ機です。JPEGで撮られたものなのでこれぐらいのサイズの差になってますけど、RAW出力した時はさらに大きさの差が広がりますが、大きさ云々以上に、情報量が段違いと感じられます。これがRAWになったらどうなるか。それをこの土日で確認できたらいいなぁ。

発売されました。
MacBook Pro 2018が登場したのは去年の7月ですから1年を待たずにモデルチェンジをした事になります。2018モデルは第8世代のCPUだったのが今回のは第9世代も搭載している。もっとも13インチモデルは第8世代に止まっているから、わずかなクロックアップが行われた程度と言えますか。
一方で15インチモデルは第9世代の最大8コアのプロセッサを搭載しています。Core i9-9880Hや9880HKでしょうか。一番下のモデルは6コアのCore i7ですけど、これは第8世代？9世代？。
GPUに変化はなく、その他仕様も変化はありません。
唯一、キーボードが改善された、となっています。
という事で、印象としてはキーボードを変更したいがためのアップデートなんじゃないかなぁってのがあります。

MacBook Pro (2019)や交換用の第3世代バタフライ・キーボードにはキーが入力されない/多重入力される問題を大幅に削減する新素材が採用されたキーボードが使われているもよう。 [AAPL Ch.]

不思議なのは、キーボード修理プログラムをAppleは実施しており、その対象に2018モデルも加わったのはわかるとして、なんと今日発表されたばかりの2019も含んでいるって事なんですよね。

MacBook、MacBook Air、MacBook Pro キーボード修理プログラム[Apple サポート]

素材を変更してトラブルの発生率は下げられるかもしれないけど、構造上、このトラブルはもう避けられないとAppleは腹を括ったのでしょうか。
であるなら、抜本的対策をしたモデルの開発をしているやもしれず、それはフルモデルチェンジに相当するのでしょうが、果たしていつ出て来ましょう。

まぁともあれです。昨年の2018モデルにRadeon Pro Vegaモデルを追加した時もそうですけど、新しいより強力なパーツが登場したら、さらりとそれに乗せかえていくというのは良い傾向なので、それはガンガンやっていただけたらと思います。近い将来、Mac miniにも8コア積んだものを出すとかね。一番いけないのはMac Proのように長い間停滞し続ける事だと思いますんで、よろしくお願いいたします。

そう言えば、MacBook Proの登場に先駆けて、AppleStoreでのLGの4Kディスプレイの販売が新モデルに置き換わって再開されましたな。LG UltraFine 4K Display ですけど、23.7インチで3840x2160の解像度を持つという、現在の4Kディスプレイの中でも数少ないサイズ感の貴重なモデルと言えます。もっとも、先代のLG UltraFine 4K Display は21.5インチというさらに貴重なサイズの上、4096x2304っていう唯一無二感がありましたがね。

ちなみに個人的にDellの24インチ4Kディスプレイを使っていますけど、2560x1440相当の表示にして使っている時、非常に使いやすいサイズ感に感じています。21.5インチで同じ解像度相当にして使用するとちょっと文字が小さく感じられそうですし、だからサイズアップの上、解像度を下げた結果、現実的なものになったのかもしれません。

それから先代はUSB-Cが1つだったのですけど、今度のはThunderbolt 3が2つになっているのは良いです。MacBook Pro 2019の15インチモデルは4Kディスプレイを4台繋げられますけど、このディスプレイをデイジーチェーンで4台とかいけるのでしょうか？（AppleStoreの写真ではそんな感じで2台繋いでるように見えますが） その上で、USB-C端子（USB 3.1 Gen1）が3つ付いているのも素敵です。

という事で、実は今回のMacBook Proの発表よりこのディスプレイの方が惹かれるものがあるのでした(^^)

さて、その上でMac Proと一緒に登場すると噂されているAppleの6Kx3Kのディスプレイはどんな物になりましょうか。楽しみに待ちたいと思います。

本当にこれでいいかは知らん。

Photoshopでスクリプトを書いた物を他の人にも使えるようにする時、どこに置くのが適当なのでしょうか。ということでネットを漁りました。
なになに、Scrptsフォルダに置け、と。

C:\Program Files\Adobe\Adobe Photoshop XX\Presets\Scripts\
/Applications/Adobe Photoshop XX/Presets/Scripts/

おぉなるほど、スクリプトメニューに表示されるようになるのね。フォルダを掘ってその中に入れてもメニューに入れてくれる模様。もちろん、スクリプトフォルダにJavascriptファイルを移動したらPhotshopの再起動はする必要があります。

これでアクションに登録して、atnファイルとスクリプトを配布することができる、でいいのかな？

もっとも、これでスクリプトの実行が組み込まれたアクションを配布して、他のマシンで動くスクリプトと動かないスクリプトができるんですよね。動かないのもアクションに登録し直せば当然動くのだけど、これはなんでなんでしょ。

以下余談。

実行したらファイルを別名保存するようにしたいのですけど、同じデスクトップに保存するにしても、MacかWindowsかで保存する場所の表記が変わってきます。つまり、プラットホームの判別を行わなければならない。
OSのバージョン表示は #.os で出来るようで、これで文字列が帰ってきます。Macなら Macintosh OS 10.14.5/64 とか。Windows 10 Proで実行したら Windows とだけ帰ってきました。

これでプラットホームの判別ができたから、Windowsでは環境変数からデスクトップのパスを取得して…って思ったのだけど、例えばホームディレクトリのデスクトップにフォルダを掘りたい場合、POSIX表記でWindowsでもいけました。つまり、MacもWindowsもデスクトップフォルダの指定は ~/Desktop でよく、

var folderName = 'sample'
var saveFolderPath = '~/Desktop/' + folderName;
var saveFolder = new Folder( saveFolderPath );
if ( ! saveFolder.exists ) saveFolder.create();

ってやると、sampleフォルダがPhotoshopから作られました。これでいけるなら環境変数から取得する方法は調べなくても良さそうです。

ということで、4/20に事故に巻き込まれてその日に修理に出した車が、ようやく直ってきました。

後ろのバンパーと扉とその周辺パーツを交換等しての修理となりました。請求は全部お相手の保険会社に行くようですけど、これだけで見積もり上44万円かかっています。（ディーラーに頼んだので、町の自動車整備工場とかに頼めばもうちょっと安くなるかもですね）

以上の修理に（間にGWを挟んだこともあり）27日かかりました。修理完了の連絡をもらって翌日に取りにいったために、代車のレンタカーを28日間借りことになったわけですな。レンタカー代としては18万ほどかかりそうです。これもお相手の保険会社に請求されるようです。

それに加えて病院行ったりそのために会社を休んだならその分の賃金を請求したり等々、交通事故を起こすと色々面倒な上に単純に金銭面で大きな負担が生じますね。お相手の方が保険にちゃんと入っていてくれて（それが当たり前とはいえ）よかったなとは思いました。

で、代車はアクアだったのですけど、やはり燃費がいいです。今日自分の車の給油をしたのですけど、互いの燃費の比較写真が以下。

上がアクアで下がうちの車（前の給油から今回の給油までの間の値）。倍違います。月額5千円で年間6万円程度ガソリンに費やしているとしたら、年間3万円ほどお得ということになります。まぁ、ハイブリッド車にしたとして、同クラスのガソリン車の価格は例えばカローラスポーツなら二十数万から三十万強お高いようなので、月額5千円程度の乗車量だと全然元は取れなさそうですがね（まして同じクラスの車だった時、ガソリンとハイブリッドの燃費の差が倍も行くかというと微妙かもしれんし）。でも数字のインパクトはすごかった…

余談ながらうちの車については、今回の給油までの間、わりと市街地を走ることが多かったので、そうじゃない時と比べると燃費は悪いです。一番いいときは17kmオーバー行きます(^^;

そんなわけで車が元どおりかなって確認の意味でちょろっと高速乗って走ってきました。うん、元どおり。元どおりどころか、（たぶん以前なんとなく言っておいたことを修理の人がおぼえておいてくれたのか）カタカタ音が車内になる事がそういえば無かったような気がします。フレーム内を通した電線がちゃんと固定されていなくって、そのケーブルが揺れて当たって音がなっているという症状だと予想していましたけど、ちゃんと固定してくれたってことでしょうか。今度はそれを気にして乗ってみますかね（来週だな）。

ともあれ、あとは体の違和感（軽いムチウチからくる症状だと思う）が無くなって、書類を相手の保険会社に出せば、一応全部終わるかなぁ。

ドライブしてこんなもんを買って帰ってきました。結構気に入っている煎餅なのですよ、これ。

劇場中編アニメーション「甲鉄城のカバネリ 海門決戦」公式サイト

甲鉄城のカバネリってタイトルをこのMacで初めて打ち込んだんだけど、普通に変換されることに驚いてみたり…

イベント上映という形で現在上映中のこの映画。尺が短めですけど、ギュッと詰まった面白い作品でした。

2016年にテレビ放送されたこちらの作品は数日前までまともにみたことがありませんでした。しかし映画の監督のインタビューを読むとなんだかとても良さげだったので観とかねばと思いまして、でもこの映画はテレビシリーズもしくは2016年末と2017年に劇場公開された総集編を押さえてから観ないといけないような気がしましてテレビシリーズ全12話鑑賞しました。これが大正解でしたですよ。たぶん本編観てないとわけがわからないと思うんで。

この作品がテレビ放送されている時、非常に評判が良いというか主に作画方面で語られているのを目にしていたのですけど、その番組タイトルから、まさかロードムービーとは露ほども思っておりませんでした。その帰路の途中というのがこの映画ってことなのですけど、そんな時系列の局所的なところで舞台や前提に関する説明がほとんどなく繰り広げられる作品でしたから、その前のテレビでの最終回までを押させておくのは必須と言えましょう。その上で劇場に観に行けて本当に良かったと思いました。

ところで映画エンディングの映像が随分とネットに出ているような印象があったのですけど、これは劇場公開と同時にAmazon Prime Videoとかでネット配信をされているのですね。Prime会員だとどうも無料で観れるようなので、またあとで楽しみたいと思います。

劇場中編アニメーション『甲鉄城のカバネリ 海門決戦』咲かせや咲かせPV

ちなみにこれを観に行くきっかけになったインタビューってのが

『甲鉄城のカバネリ』のヒロインはなぜこんなに可愛い？　大ヒット作・渾身の続編、荒木哲郎監督が模索する“理想のアニメの鍛え方” [【es】エンタメステーション]

でして、この冒頭で、テレビシリーズを楽しめたのなら安心して楽しめる内容になっていうることを匂わせています（「東映まんがまつり」って発言とかね）。その上で、Twitter上でいろいろと超絶動画が流れてきましてね。テレビシリーズ12話をこの映画を観に行くために観るというモチベーションになりました。と言っても1話を観はじめたらあとはもう一気にだった印象で、頑張って観るという意識は全く必要なかったです。まぁ頑張って観なければならないって作品だったら、途中で放り出して映画も観に行ってなかった可能性は高いでしょう。

ってなわけで、大変に気に入りました。

iPhone Xを購入してからずっとApple純正のシリコンケースを使っておりました。その前のiPhone 6s Plusで使っていたケースが気に入っていたのだけど、iPhone Xを手に入れた当時はまだ発売されていなかったので、ちょっと割高ではあるけど、純正品にした次第。

で、購入してから1年半近く過ぎまして、壊れました。

こんな感じでコーナーがペロッと薄くめくれてしまいます。この場所がポケットから取り出す時に掴む部分なもので、これだけ剥がれていると力をかけた時にめくれた部分がずれて力がうまくかからず落としそうになりますね。こんなふうに突如めくれ上がったのが昨日のことです。落とした衝撃でコーナーに傷が入っていたのですけど、そこは剥がれ落ちていて、で落としたのはだいぶ前だと思うので、個人的には前兆はまったくなかったって感覚です。ということで落としそうなことと流石にみっともないということでAmazonに注文。

iPhone 6s Plusで使っていた時に気に入っていたAndMeshのケースを取り寄せました。今となっては旧機種用ということもあり、1944円とちょっとお安く買うことができた上に、昨日の今日届いたのでとても喜ばしい。

ということで新品の乾いた感触はとてもよろしいですね。

これが汚れていくとこの乾いた感触が無くなっていくのですけど、とりあえずはこの感触を楽しみつつ、次のiPhoneの登場を待ちます。

Mojaveの10.4.5がリリースされました。

eGPUでRadeon VIIをサポートしたそうです。

macOS Mojave 10.14.5：AMD Radeon VIIをサポート[Macお宝鑑定団 blog（羅針盤）]

もっとも上記ページによるとeGPUの推奨電源は650W以上ということで、僕が使用しているeGPUボックス（550W）では役者不足でございました。残念です。RADEON VII搭載GPUカードは10万ほどのようなので、仮に650Wモデルを持っていたとしても、当分は手を出せるお財布状態じゃないから、ホントはそんなに残念じゃないw

おま環な事例なんだけど、外付けHDD（TerraMaster Thunderbolt D5）がHDDをスリープしたらスピンアップ時にMacごと死ぬって症状と、CompressorでのH.264エンコードでmacOSのGUIが死ぬって症状の二つが改善していたらいいなぁって思っているのだけど、どちらもMacが死ぬって動作なので、あまり治ったか試したくない…

と思いつつ、ネットを漁っていたら、HighPointのサイトにてダウンロードできるHighPointRRが入っているドライバのインストーラがMojaveに対応していることを知りました。これにより入るバージョンは4.20.1らしい。とりあえず、Mojaveに付属してきたHighPointRRをバックアップしてインストーラを走らせると入りました（4.20.0と表示されるけど）。ということで一旦Macをスリープさせて、HDDの回転が止まったことを確認して、キーボードをポンと叩いてスリープから復帰させると…、Macは落ちなかったけどHDDの中身が見えてきませんな。ダメそうです。

Compressor問題はまた今度検証してみますけど、ちょっと残念でした。

今回のアップデートの一般的な観点の目玉は令和への対応とAirPlay 2対応機器への対応ってことですけど、後者については恩恵を受ける機器を持っていないのですよね。うちのヤマハのサウンドバー、AirPlay対応なんだけど、AirPlay 2対応ファームウェアアップデートとかしませんかね。

令和への対応はNumbersでセルの内容を日付表示にした時に令和になるんかなぁって思ったけど、そもそも和暦表示にはならないっぽい（西暦しか選べない）。現状のExcelが2019年5月1日以降の2019年を令和1年と表示するところ令和元年って表示したらちょっと偉いかもって思ったんだけど、問題外でした。その他システム周りの日付表示で和暦を使うことはないからなぁ…。恩恵ないなぁ。「㋿」が文字化けしないってぐらいかね？（UnicodeのU+32FF）

例年ですとWWDCでmacOSのメジャーアップデートが発表されて9月から10月にリリースですから、10.4のアップデートは10.14.6あたりで最後になりますかね？願わくば、WWDCで発表されるかもしれないMac Proが10.14.6か10.14.5のカスタム版を搭載して後即発売とかなるといいんだけどなぁ。

<追記>CompressorでMacのGUIが死ぬ問題もどうやら解消した模様。今これを書いている裏でエンコードをかけているのだけど、問題が起こっていた時は確実にフリーズしていました。ところで、そのテストのために回したエンコード処理が終わったらCompressorの「アクティブ」タブ内に、問題を起こしていた時期に立てたジョブが現れたのだけど、これを止めることができない。おかしくなったのはこいつが原因かな？ ジョブはどこにたまっているのだろう…

と思ったけど、どうやら

~/Library/Application Support/Compressor/History/V4/

の中にあるファイルっぽいね。.compressorJobBatchって拡張子のファイルです。一旦消してもどこかにキャッシュされているのか、今さっき実行したものについては復活してきたけど、問題が起こっていた時期（GW中）のについては消えたっぽい。<追記>治ったと思ったけど、やっぱりダメだった…</追記></追記>

<追記>HDDスピンアップ時にMacが死ぬ問題は、OSの問題じゃなく、HDDケースのセッティングの問題だった雰囲気です。こちらのエントリに追記しました。</追記>

突如として発表され、しかもユーザーへの大々的な告知は一切なく、ニュースサイトで取り上げられる事で話題になっているわけですが、

「事後報告すらない」──“Adobe CC”で旧バージョンDL廃止　アドビは理解求める [ITmedia NEWS]

ということが実施されました。

Changes to Creative Cloud Download Availability [Adobe Blog]

Adobe CCの契約をすればCS6とAdobe CCの過去バージョンをダウンロードしてインストール、使用をすることがAdobe Cloudアプリから行うことができていたのが、事前に予告なくそれを撤回し、過去2バージョンのみのダウンロードが可能となるという状態に移行しています。

ちなみにAdobeとしてはAdobeが定義する非認定バージョンを今すぐアンインストールしろということのようです。これはユーザーがどこかから訴えられる可能性があるから、ってことみたいです。コンプライアンス重視でWindowsアップデートは常に最新をとかいうポリシーな会社だったら、これは即座にアンインストールしないとね、って上から圧力かかりそうですね。

非認定バージョンの削除[helpx.adobe.com]

まぁそんな無茶を言ってくる現場はそう多くはないだろうから（もしかしたら本当に訴えられるユーザが出てくるかもしれず、そしたら状況も変わるだろうけど、とりあえずは）多くのユーザーに関係あるのは過去2バージョンという内容でしょう。例えば今年2019年にプロジェクトを開始したとして、現在のAEの最新バージョンは16.1だけど、諸々の理由でそのプロジェクトに最適なバージョンがAE15.1なのでそのバージョンで作業を開始したとします。で、そのプロジェクトが長引いてAE17が登場した後もまだプロジェクトは続行中の時、運悪くマシンがトラブって再インストールが必要となったり、プロジェクトが炎上して人を増やすからと新規にマシンを設置する時、それらマシンにAE15.1はもうインストールできないって状況が予想されます。
過去2バージョンが現行バージョンを除いた過去2バージョンをかもしれず、その場合は猶予が1年ぐらい伸びるのかな。

DTP業界とか古いバージョンを使っているところは直ちに影響が出ている感じですけど、現状で問題が生じていない現場でも長丁場なプロジェクトを抱えていたり、過去バージョンで作ったプロジェクトを再利用せねばならなかったり、過去バージョンにしかマッチしないプラグインを使用していたりすると、詰んじゃう仕事が出てきそうですね。

個人的にはほぼ他人事なんですけど、大変なことになりました、って感じです。権利侵害が関わっているらしい今回の措置ですから、そう簡単にAdobeがこの事態を撤回することはないだろうと思われますが、さて、どうなりましょうか。

頂点シェーダーとフラグメントシェーダーの例 [Unity マニュアル]

前「ワールド空間法線を使った環境リフレクション」の検証

「法線マップを使った環境リフレクション」の検証

Shader "Unlit/SkyRefrection Per Pixel"
{
    Properties
    {
        _BumpMap("Normal Map", 2D) = "bump"{}
    }
    SubShader
    {
        Pass
        {
            CGPROGRAM
            #pragma vertex vert
            #pragma fragment frag
            #include "UnityCG.cginc"
            
            struct v2f {
                float3 worldPos: TEXCOORD0; 
                
                //接空間のベクトルをワールド空間に変換するために使うのが以下の三つ。3x3の回転行列ということです。
                //接空間はテクセル位置に接する平面を基準とした空間。
                //  テクセルはテクスチャの画素ぐらいの意味。
                //tspace0,tspace1,tspace2 の3つの3Dベクトルで3x3行列を構成するようです。
                half3 tspace0 : TEXCOORD1;
                half3 tspace1 : TEXCOORD2;
                half3 tspace2 : TEXCOORD3;
                
                float2 uv : TEXCOORD4; //法線マップのテクスチャ座標
                float4 pos : SV_POSITION; 
            };
            
            //バーテックスシェーダーの関数。
            v2f vert (float4 vertex : POSITION, float3 normal: NORMAL, float4 tangent: TANGENT, float2 uv: TEXCOORD0){
                //シェーダーセマンティクス
                //  float4 TANGENT : 接線。
                v2f o;
                o.pos = UnityObjectToClipPos(vertex);
                o.worldPos = mul(unity_ObjectToWorld , vertex). xyz;
                
                half3 wNormal = UnityObjectToWorldNormal(normal); //法線
                half3 wTangent = UnityObjectToWorldDir( tangent. xyz ); //接線
                //TANGENTは4DベクトルなのでUnityObjectToWorldDirにかけるためにxyzを取り出している。
                half3 tangentSign = tangent.w * unity_WorldTransformParams.w;
                //tangentの向き（w 1か-1を返す？）に
                //（おそらく）オブジェクトが裏返っているかいないかを判断する
                //unity_WorldTransformParams.w（1か-1を返す？）をかけて接戦の方向を確定しているのだと思う。
                half3 wBitangent = cross(wNormal, wTangent) * tangentSign; //従接線
                //法線と接線の外積からこの二つのベクトルに直行するベクトルに向きを考慮して従接線（従法線）を得ている。
                
                o.tspace0 = half3( wTangent.x, wBitangent.x , wNormal.x );
                o.tspace1 = half3( wTangent.y, wBitangent.y , wNormal.y );
                o.tspace2 = half3( wTangent.z, wBitangent.z , wNormal.z );
                //この3つで回転行列になるらしい。
                //接空間で表現されたベクトルにこの回転行列を適用するとワールド座標系で表現されたベクトルになる、らしい。
                
                o.uv = uv;
                return o;
                
            }
            
            sampler2D _BumpMap; //法線マップテクスチャ
            
            //フラグメントシェーダーの関数
            //オブジェクトが画面上でしめる全てのピクセルで実行されるプログラム。
            fixed4 frag (v2f i): SV_Target {
                
                half3 tnormal = UnpackNormal(tex2D(_BumpMap , i.uv));
                //法線マップはUnityに読み込まれた段階で圧縮フォーマットとして内部で保持される。
                //それを適切な法線の値として再現するためのUnpackNormalメソッド。
                
                //以下取り出した法線を接空間からワールド空間に変換。
                half3 worldNormal;
                worldNormal.x = dot(i.tspace0, tnormal);
                worldNormal.y = dot(i.tspace1, tnormal);
                worldNormal.z = dot(i.tspace2, tnormal);
                //接空間のベクトルにワールド座標系への回転行列を適用することと、上記3つの内積を使用した式は同じ。
                //wTangent = (tx, ty, tz) , wBitangent = (bx, by,bz), wNormal = (nx,ny,nz) とするなら
                //下式の3x3行列が回転行列。これをtnormal = (x,y,z)に適用する。
                //┌        ┐┌ ┐ ┌                  ┐
                //│tx bx nx││x│ │tx*x + bx*y + nx*z│
                //│ty by ny││y│=│ty*x + by*y + ny*z│
                //│tz bz nz││z│ │tz*x + bz*y + nz*z│
                //└        ┘└ ┘ └                  ┘
                //となり、右辺の各項は
                //tspace0とtnormalの内積、
                //tspace1とtnormalの内積、
                //tspace2とtnormalの内積とそれぞれ同じになる。
            
                half3 worldViewDir = normalize(UnityWorldSpaceViewDir(i.worldPos));
                //ピクセルごとのカメラへの方向を取得して
                half3 worldRefl = reflect(-worldViewDir, worldNormal);
                //そのピクセルでの反射のベクトルを得る。
            
                half4 skyData = UNITY_SAMPLE_TEXCUBE(unity_SpecCube0, worldRefl);
                //unity_SpecCube0 : Unityがデフォルトで定義しているキューブマップ
                //UNITY_SAMPLE_TEXCUBE：指定したベクトル方向のキューブマップの色を返す。
                
                half3 skyColor = DecodeHDR( skyData , unity_SpecCube0_HDR );
                //DecodeHDRはUnityCG.cgincに入っている関数らしいです。
                //unity_SpecCube0_HDRはunity_SpecCube0のHDRに関する情報が入っていると考えればいいのでしょうか。
                //skyDataは内部形式で保持されている色を本来の色にデコードするのがDecodeHDR、なのか？
                
                fixed4 c = 0;
                c.rgb = skyColor;
                return c;
            }
            
            ENDCG
        }
    }
}