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

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中）のについては消えたっぽい。</追記>

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

「事後報告すらない」──“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
        }
    }
}

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

前「楽しく役に立つメッシュ法線の使用」の検証

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

Shader "Unlit/SkyRefrection"
{
    Properties
    {
        
    }
    SubShader
    {
        Pass
        {
            CGPROGRAM
            #pragma vertex vert
            #pragma fragment frag
            #include "UnityCG.cginc"
            
            struct v2f {
                float3 worldRefl: TEXCOORD0; 
                float4 pos : SV_POSITION; 
            };
            
            //バーテックスシェーダーの関数。
            v2f vert (float4 vertex : POSITION, float3 normal: NORMAL){
            
                v2f o;
                o.pos = UnityObjectToClipPos(vertex);
                
                float3 worldPos = mul(unity_ObjectToWorld, vertex). xyz;
                //unity_ObjectToWorldはビルトインシェーダー変数
                //mulは行列乗算を行う関数。
                
                float3 worldViewDir = normalize(UnityWorldSpaceViewDir(worldPos));
                //UnityWorldSpaceViewDir(float4 v)：UnityCG.cginc に定義されている関数。頂点から見たカメラの方向（3Dベクトル）
                //上記関数は正規化されていない値を返すため、normalizeで正規化。
                
                float3 worldNormal = UnityObjectToWorldNormal(normal);
                //UnityObjectToWorldNormal(float3 v)：UnityCG.cginc に定義されている関数。オブジェクト空間の法線をワールド空間のに変換。
                
                o.worldRefl = reflect(-worldViewDir, worldNormal);
                //ワールド空間での鏡面反射ベクトル。視点から発したレイが反射した方向かな。reflect関数で求められるらしい。
                
                return o;
                
            }
            
            //フラグメントシェーダーの関数
            fixed4 frag (v2f i): SV_Target {
                half4 skyData = UNITY_SAMPLE_TEXCUBE(unity_SpecCube0, i.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
        }
    }
}

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

Unityのドキュメントに頂点シェーダーとフラグメントシェーダーの例ってページがあります。自分のメモがてら、その検証を書いていきます。

「楽しく役に立つメッシュ法線の使用」の検証

Shader "Unlit/WorldSpaceNormals"
{
    Properties
    {
        
    }
    SubShader
    {
        Pass
        {
            CGPROGRAM
            #pragma vertex vert
            #pragma fragment frag

            #include "UnityCG.cginc" //ビルトインシェーダーヘルパー機能の読み込み
            
            //型
            //float4 : 32bitの4Dベクター型
            //float3 : 16bitの3Dベクター型
            //fixed4 : 低精度 -2.0から2.0の11bit。標準カラーに一般的に使用される。
            
            //vertexシェーダーの出力とfragmentシェーダーへの入力のための構造体. vertex to fragment の略として命名している模様。
            struct v2f {
                float3 worldNormal: TEXCOORD0; 
                float4 pos : SV_POSITION; 
                //シェーダーセマンティクス
                // GPUに対して変数にどんな値が入っているか示すための決められた表現
                //  TEXCOORD0 : 1番目のUV座標 float2/float3/float4 て定義するがこの例では法線の値を格納するため float3で定義。
                //  float4 SV_POSITION : 頂点のクリップ座標。ラスタライズ処理のためvertexシェーダーの出力では必ず必要。
                //クリップ座標
                //ディスプレイの描画領域からはみ出た範囲が削られた空間。x,y,z の値が-1から1の範囲に収まるよう正規化されている。
            };
            
            //vertexシェーダーの関数
            //関数は
            // 戻り値の型 関数名(引数){}
            //という形で記述
            //引数には入力用引数と出力用引数がある。
            //入力引数の型
            //　データ型 変数名 : 入力セマンティクス
            //出力引数の型
            //　out データ型 変数名 : 出力セマンティクス
            
            //各頂点で実行される関数。
            v2f vert (float4 vertex : POSITION, float3 normal: NORMAL){
                //この関数の中で、最低限頂点のクリップ座標での位置を出力する必要がある（float4 SV_POSITIONへの出力は必須）。
                
                //シェーダーセマンティクス
                //  float4 POSITION: オブジェクト空間の頂点位置の入力
                //  float3 NORMAL: 法線ベクトル
                //位置情報を4Dベクトルで取り扱うのは座標変換が容易になるから、らしい。
                v2f o;
                o.pos = UnityObjectToClipPos(vertex);
                //UnityObjectToClipPos: UnityCG.cginc に定義されている関数。頂点位置をオブジェクト座標からクリップ座標に変換。
                o.worldNormal = UnityObjectToWorldNormal(normal);
                //UnityCG.cginc に定義されている関数。オブジェクト空間の法線をワールド空間のに変換。
                //  UnityObjectToWorldNormalはドキュメントに書かれていない。
                return o;
                
            }
            
            //フラグメントシェーダーの関数
            //オブジェクトが画面上でしめる全てのピクセルで実行されるプログラム。
            fixed4 frag (v2f i): SV_Target {
                //シェーダーセマンティクス
                //  SV_Target: ピクセルの色
                fixed4 c = 0;
                
                c.rgb = i.worldNormal * 0.5 + 0.5;
                //worldNormalは法線情報を元に作成された値（-1から1の範囲）のため、それをカラー値として扱える0から1の範囲に変換している。
                return c;
            }
            
            ENDCG
        }
    }
}

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

笠間は茨城県は水戸市の西側にある地域ですけど、そちらでGW中ぐらいの時期に有名なのはつつじまつりと笠間稲荷神社の藤の花ということになります。両者は徒歩で渡れる範囲にあるため、観光するにはちょうど良いですね。ということでGW最終日、行ってきました。

常磐道を北上し友部JCTから北関東道を西に進んで友部ICで降り公営笠間稲荷駐車場を目指しました。今の季節、ひたち海浜公園のネモフィラ目当ての観光客で友部JCTあたりが渋滞しがちですけど、GW最終日だからか渋滞が一切なくスイスイ走って現地到着することができました。現地も人出が少ないような気がします。つつじまつりについてはツツジのシーズン終盤ということもあるのでしょうけど、GW最終日というのは結構狙い目なんですかね。ちなみに帰りも渋滞無し、友部S.A.も比較的空いていました。

ってことで現地で鑑賞するわけですが、つつじはシーズン終盤だし天気は曇りだしてでちょっと残念でした。

こーいう感じのもちらほらありました。でもまだ綺麗なのも結構ありましたし、それなりに満足できたかな。

で、そのあとは笠間稲荷神社に行きます。車を停めた駐車場から少し歩いた門前通りから脇の鳥居をくぐって神社へ。先に進んで楼門を超えると右側に藤棚が見えてきます。

藤の木は2つあり、手前が大藤で奥が八重藤ということです。どうしても手前の大藤に目がいっちゃいますけど、

県指定の天然記念物なのは八重藤の方です。

樹齢400年ということで、幹が見事でございました。

いろんなところに有名な藤棚があるから、来年以降、それらを見に行きたいものですな。

余談ながら藤棚として管理されていない野生の藤の木は他の木に寄生して枝を伸ばしているわけで、今の季節風景としては綺麗なんだけど、寄生されている木にしてみるとたまったもんじゃないだろうなと思ったりしつつ家路につきました。この野生のを剪定して枝を這わせるものを作ればやがて藤棚になるんかね？