今日こそやるぞ5日目（いやもう休む）

今日こそやらないページ（サービス潰れて移転五回目）

ストーリー型のソシャゲに思うことなど

久々に駄文を投稿するのだけども

 

前置きとしてソシャゲでエヌイノセンスというのがあってそれを少しだけ遊んでみていて

それが画面的にはというかパッと見はというかでのイメージでは次世代FGOという感じがあって

キャラクターが高品質なセルシェーディング3Dで格ゲーを意識した見せ方をされており

自分はFGO自体は未だにプレイし続けているんだけど、FGOがこういう感じでグラフィック的にパワーアップしてくれたらすごい良いなーと思わせるような感じというか

 

で、ここからはエヌイノセンスを触っていて今回も思ったというか

エヌイノセンスに限らず色々なソシャゲ触って思っていたことなんだけども

ストーリー読む気にならない問題

 

あくまで自分の場合はなんだけども

なんか大体のソシャゲ触り始めるときは「カワイイもしくはエロい子がいるな」とか「無料１０連実施中」だとかな場合が多くて

その結果ゲーム始めてオープニング始まっても話が頭に入ってこないもしくは我慢できずにスキップする

頭の中はガチャ回してぇで一杯だから

 

例外としてガーディアンテイルズとかは神々のトライフォース的なアクションゲームで

ゲームプレイそのものにかなり少ないセリフでストーリーを混ぜ込んでくるので普通に頭に入ってきたのだけど

大体の場合はADVパートとゲームパートに分かれていて

（特にシナリオを推して開発している）ADVパートではそこそこ長文を読むことになる

でこのADVパートをスキップしてしまう

 

自分はFGOは読んでいるのだけども

なんで逆にFGOだけは読み始めたのかということを最近何度か考えて

そこでやっと本題なんだけども

シナリオ目的でソシャゲ始めないとソシャゲのシナリオ読まなくないか？

という仮説を思い至ったので駄文を久々に書きたくなったという流れである

 

それでFGOはなんで始めたのかというと

当時は1.5部が進行中だったタイミングで始めたのだけど、一部6章の評判が非常に良かったから自分も一度読んでみたいと思ったからというありきたりな動機で

ただこれだと「ソシャゲ内で名シナリオ生み出して（ここまでは開発側の努力でなんとかなる領域？）それをスキップせず読んでくれるユーザーが一定数以上いて尚且その人たちがアルファツイッタラーとかで口コミで評判広げてくれる」とかじゃないと俺がFGOはじめましたみたいな感じでシナリオ目的でソシャゲ始めてくれる人続出せんじゃろがいと

それで思ったのがソシャゲ内で名シナリオ生み出す前からシナリオ目的で遊んでくれるユーザーを多数確保しないとどうしようもないんじゃないかという

 

ゲームのサービス開始前前からシナリオの面白さを見込んで始めてくれる（ガチャ欲は完全に横においておいてオープニングの長文もしっかり読んでくれる）ユーザーは少数はいると思うけど多数となると通常難しいところなのに

FGOはサービス開始時からシナリオはちゃんと読んでくれるユーザーを多数確保すること自体には成功していたんではないかなと

（だからゲーム内で評判がいいシナリオが口コミで広まる為の口コミの大本になるユーザー数確保できていたんじゃなかろうか）

 

で、それはなんでじゃいというとFGOより前のそもそもの前作というか原作というかでのところでfateステイナイトがあったからではないのかなと

そっちで原作者の書くシナリオの面白さが保証されているんだからそりゃシナリオ目的でソシャゲ始める人を多数確保しやすいよなーと

 

それで他にもウマ娘とかはシナリオ目的で始めた人が多い印象なんだけども

あっちはあっちでかなり評判の良いアニメ作品がゲームより前の段階であって

それがステイナイト的な位置づけになった結果シナリオ目的ユーザーを確保できたんじゃないかと

 

ということを机上の空論レベルだけども考えると

シナリオ重視のソシャゲ始めるならソシャゲのクオリティ以前の話として

ソシャゲの大本になる何かを他の媒体まず作ってそっちでシナリオの品質を絶対保証しないとどうにもならなくないか？と言う事を思った

 

いや「よくわからん展開よりゲームの長々としたチュートリアルよりまずはガチャ回してぇんじゃぁ」ガチャ欲吹っ飛ばせるぐらい強烈な話と演出をオープニングにぶっ込めればまた別かもしれないけども

 

一応お休みはさみつつたまに再開して勧めている程度だけどもヘブンバーンズレッドはシナリオ読んでいて

こちらに関しては

Keyというメーカーへのシナリオへの信頼感と

ホロライブのvtuberに最初の部分をプレイしてもらう事でオープニング周辺のシナリオに関しては各ユーザーがスキップして読まない問題の対策になったと言うところがあるのかなと思うので

絶対に別の媒体でまずは大本のなにかを作って面白いシナリオ絶対保証をしないといけないわけではないのかなとは思うのだけど

逆にそういった点でなにか対策を考えてサービス開始しないとシナリオ重視でソシャゲサービス開始して

FGOやウマ娘レベルでシナリオの評判続出口コミで広がり大ヒットというのは相当厳しいのではなかろうか

 

という妄想レベルのことを最近うんぬんと考えていたので駄文として出力しておきたかっただけという

特になんのオチもまとめもないですハイ解散

ニコニコから何度目かの移転

ニコニコブログサービスが終了するとのことで移転

最近特に更新してなかったし、今後も更新するよりはツイッターで駄文垂れ流しするのが主になるとおもうのだけれど

一応ある程度更新してた時期のいくつかの情報は自分で見返すこと自体はありそうだなーとおもって移転だけはやっておく次第

タグ付けというのだけ記事ごとに更新しないと駄目っぽくてちょい面倒だから順次やっていこうと思う……

PC環境ではyoutubeのVR映像が見れない問題

youtube VR

・前置き
検索しても日本語でこの話に触れているもの自体がほぼ出てこなかったので
誰かが困ったときに助けには一切ならないけど
現状としてはこうなっているんですよという情報にはせめてたどり着けるように残しておく
たどり着けないと延々ループするしかないので（自分がそうだった）
（自分がたどり着けなかっただけでほかにもあるかもしれないけど、検索結果のゴール地点は粗悪でも増やしておいた方がいいと思うので）
以下に書くことで自分の勘違いがあるかもしれないので其処はネットでも社会でも片隅のおっさん調べの精度での情報ということで

一応現在21/01/11でのお話なので、一週間後とかにしれっと状況が改善している場合もあるとは思う1％以下の確率で


・本題
PCでyoutubeのVR映像が見れません
見る手段が消失しています

元々PCのVR機器でYOUTUBEのVRを（もちろん立体視できる前提で）見ようとした場合
Steamで配布されるyoutubeアプリを使うしか手段がなかった
でこのアプリなんだけど、当初は各UIのアイコン表示がバグって
このボタンは高評価だか低評価だか押してみるまでわからんというぐらいの感じだったんだけど（これは人によっては正常に表示されている人もいたっぽいレベルの話ではある）
半年ほど前からいよいよVR動画自体が正常に再生されなくなった

これまでも右目用映像と左目用映像が上下に分割されたようなリソースそのままで各視点に振り分けられてない
みたいな状態で再生されることは度々あったのだけど
半月ほどで修正はされており
今回もまた半月ほどはVR映像見れないのかなーぐらいの気持ちだった

ところが今回は上記のような症状に加えて、Youtubeとしての映像のさらに手前に
嫌がらせのような真っ暗な画面が出現して的確に視界を遮ってくるという現象が追加された
まぁこのぐらいなら今回はそういう感じのバグねーぐらいだったのだけど
そこから半年、バグは一切改善されず放置されつづけ
つい最近Steamのストアページそのものが消失したのである

返す返すいうがPCでYoutubeのVR映像をみるのにこのSteamで配布されていたYoutubeアプリがほぼ唯一の手段であるので
これで表題の通りyoutubeのVR映像が見れなくなったわけである



・360度動画に限っての代替手段
YoutubeのVR映像には360度対応のものと180度対応のものが二種類あり
360度のものに関してはGizmo VRというアプリで一応視聴可能（ちゃんと立体視状態）です

Gizmo VRを立ち上げると最初はGizmo専用動画サイトにいくのだけど
・アドレスを打ち込むところにyoutubeのアドレスを直接打ち込む
（自分が先ほどやったときはyoutubeに移動するためのアイコンボタンも出てきたけど、これは以前一度上記方法でアクセスしたときにブックマークされたとかかもしれないのでこっちの方が確実）
・普通のブラウザみたいな状態で表示されるのでVR動画を検索
・動画のページに来たらブラウザっぽい画面の下部に「全画面表示にする」というボタンがあるはずなのでそれを押す
・360度のVR映像が上下、もしくは左右に分かれた状態で表示されたらOK
・再生バーの右側にオプション簿tんがあるので、それで「立体視にする」「360度か180度か」「上下分割か左右分割か」の設定をすれば正常に立体視で見れるはず
（先ほど試した時は動画再生ごとにやらなければいけないようだった）

上記方法なら180度動画でも見れそうに思うだろうけど
Youtubeの配信サイト側が180度動画の場合は特別な処理を入れているようで
上下、もしくは左右に分かれた状態というリソースそのものの状態で動画を取得できないっぽい

 

21/05/04追記

vr180でも一応代替手段があるらしい

operaというブラウザの特定バージョン（自分が見たタイミングだと55、最新の56だと駄目とのことだったけど、偶々そういうタイミングだっただけで、この情報を見るタイミングによっては最新のものをダウンロードするのでもよいかもしれない）だとvr180でも見れるらしい？

ということがすでにストアページが閉じてしまったsteamのコミュニティに書かれていた

 

それならこれでいいじゃん！と思って自分もインストールなどしようとしたのだけれど

特定のバージョンの入れ方を調べる中でoperaというブラウザそのものが結構怪しいみたいな話も検索でいっぱい出てきて

そういう怪しいものをめんどくさい情報調べたり翻訳サイトの力で逐一翻訳したりの面倒かけてまで、となってしまって

結局試していない状態なのだけれど、一応こういう話もあるよ程度の情報を追記しておく



・以下はおっさんのお気持ち表明なので読まなくていい部分

許せん！理不尽！根拠は巧く解析できんが俺は怒っている！みたいな感じ
いや、世の中コロナが流行って会社側もいろいろ事情があって大変なのかもしれないよ
でも流石になにかしらの説明とかはしてもよくないですか？
（英語のストアページではされているとかだったら本当にすまないけども）
度々バグっていたのを最後には放置した挙句にストアページごと消失
この間一切説明もなければ今後の代わりの視聴手段もないっていう

自分がVR買った目的はいろいろあったけど
メインの楽しみはYOUTUBEに投稿されるいろいろな人のVR映像（主にMMD）だったわけなんですよ
MMDのVR映像は今も主にyoutubeに投稿されているものが一番活発だし
（ほかの方、特に投稿している本人はどうやって見ているんだろう？　QuestみたいなPCなしで動くやつとかPSVRでみるとかかな？
　自分はPSVRはもっているもののPS4がPROではないのもあって高解像度のVR映像見るとすぐ読み込みが挟まる感じになってしまう……）

公式から何かの説明がある、もしくは代わりの手段があるとかならまだ納得いったかもしれないけどなぁ……
うだうだ愚痴っても黒歴史が増えるだけなのでここまでにしとくけども
こういう現状について全然情報が出てこないのは
そもそもVR映像なんて誰も見てないから現状事態に気づいていないってことなのかなぁ……

ニコニコ動画のほうでVR映像対応とPCの視聴用アプリ配信してくれません？
いまならYOUTUBE出し抜けますよ
VR映像見てるのおれぐらいとかじゃなければだけど！！


orz
久々の更新がこんな愚痴

ジョーカーをみる（映画感想、ネタバレあり）

感想

ジョーカーをみて久々にいろいろ吐き出したくなったのでブログに長々と
字幕版一回見ただけでバットマンは「ニンジャバットマン」しか見たことないという体たらく
尚且つこれは自分の浅い考えでの感想なので間違っている可能性大きいけども

●悲劇と喜劇の違い
見終わった後でいろいろ考えている間、個人的に一番引っかかったところとして
作中の終盤で主人公アーサーは「自分の人生は悲劇だと思っていたが喜劇だと思うことにした」というようなことを言う
このセリフは普通なら「悲劇過ぎてもう笑うしかない」という意味の王に思えるが
そういうある種のやけくそ感、みたいなものは感じられなかった
ではその場その場でそれっぽいことを言っただけなのかといえば、そういったノリ重視の映画でもない
しばらく考えて
・悲劇は主人公の心情を理解しないと成立しない
・喜劇は主人公の心情を理解しなくても成立する
という違いなんではないかなという思いに至った
理解者が皆無なアーサーの人生は悲劇として成立しないのだから喜劇になるしかないのではと


作中で一番良心的な小人症の人物がいるのだけども
この人物ですらアーサーが凶行に走ったときにどうして？と言う
見ているこちらとしてはそういう状況になってしまうだろうという可能性は大いに考えられるのだけれど
そういったことを想像すらおらずにその場所に来てしまっている

また、唯一の家族、心の支え、アーサーを肯定してくれる母親は主人公の想像以上に妄想の世界に生きている、精神障害的なものを抱えているということが発覚し、彼女からの肯定が社会的な自己肯定としての意味をなさなくなる

それ以外の人物はそもそも話を聞く気がない人物ばかりだったように思う
雇い主に関してはアーサーの釈明のタイミングすら与えないし、
カウンセラーに対してはアーサー自身が「話を聞いてないだろう？」という
また彼が最後のほうのジョークとして、「ノックノックノック」というのは
（今調べたところノックノックジョークというのがあるそうなのだけれども）
「ノックしてもしもお～～～し」という話聞いてる？的な意味合いで彼以外のすべてにたいしての皮肉のように思った

彼はの自分の人生が喜劇だと認識を切り替える決定は
自分を理解してくれる誰かの誕生をすっぱりあきらめたようにしか思えなかった
特に最後のコメディアンとのやりとりはいくらでも言い返せる余地があり
「君が私の何を知っているというんだ？」あたりはもう盛大なるブーメランで
見ている自分としては「おまえがな！？アーサーの何か知ってて今まで馬鹿にしてくださってたんですかねぇ！？」と心の中では声を大にしていたが
アーサーは説明したり理解を求めたりせず撃ち殺した

エンディングでもジョークを思いついたのち「理解できないだろうけど」と説明はしない


●アーサーは笑いを信じているのか？
また喜劇というもののポジティブというか当然の側面として笑えるというのがあるけど
そもそもアーサーにとって「笑い」ってそんなポジティブなものだったのかなと

アーサーは子供のころから脳の障害で笑いたくもないのに笑ってしまうという状態であり
尚且つそれによって人生に多大な不利益を抱え込んでいるというのがネガティブな要素として一つある
また、彼はコメディアンを目指しているが母の言いつけである「笑顔で人を楽しませる」という路線に従っているというような動機しかでてこない
アーサーは笑いというものにポジティブな衝撃を受け
人生の芯となった結果コメディアンを目指しているというわけではなく
仮の目標であるそこにすがるしかないという意味での人生の方向性でしかなかったように思える

（あとこれは自分の想像でしかないのだけど皆が笑っている環境下であれば自分の笑ってしまう障害を持った状態もその環境下では不自然ではなくなるというのがあったのではと思う）

また彼自身が笑いを理解できていない、もしくはほかの人と笑うポイントに決定的なずれがあるようなシーンがいくつかあって
酒場でコメディアンがジョークを言って観客のみんなが笑うのだけどアーサーだけ笑うタイミングがずれているところや、小人症の同僚をバカにして皆が笑うシーンでアーサーもわらうものの部屋を出た瞬間にすっと真顔になるシーン等、彼自身「笑い」をちっとも楽しめていないように思えた


それでも物語の開始時点では消極的理由であっても笑いは彼にとって救いの分量が大きかったと思うのだけど、最後には笑いの生贄にされてしまう
「笑い」に大きな裏切りを受けた物語最後の彼にとって笑いはもはやネガティブな存在なのではと
実際作中でいくつかコメディ的な間の取り方がされたシーンがあるか個人的にはそこで思ったのは「クスリ、ニヤリ」という笑いではなくて「なんでそんなことになってしまうんだ」という気持ちで
そういう意味でも自分の人生を喜劇、「笑い」を振りまくものであると設定したのは
ゾッとするというか、悪党としての行動原理が完成してしまった感じがある
（そして皮肉にも母親の言いつけである皆御笑顔にという役割を悪役としてのねじ曲がった芯ではあるが、守って生きていくことになる）

またこれは後で批評をあさっていて見かけたことなのだけど
パンフレットには最後の「理解できないだろうけど」の時のジョーカーの「笑い」のみが心からの笑いである、と明記されているらしい
悪役となり、人を踏みにじる側になってやっと心から「笑い」が生じるようになった
これはある種あのコメディアンがやっていたことであり
ジョーカーとしては「ああこれがお前らが感じていた人を踏みにじることで得られる幸福感、笑いという奴か」という風な理解を得てしまったのかもしれないとも少し思った


●アーサーがどこまでやってくれるのか＆しまうのかというハラハラ感
上記二点が自分が一番吐き出したかった感想なのでもう大体落ち着いたのだけど
映画としても面白かったということも
個人的にこの映画の面白さは同情すべき人物であるアーサーがどこまでやってしまうのかというところだと思った
上のほうで作内のコメディアンに批判的な心象を書いておいて矛盾してしまうが、見ている側としてはやはり、自分の期待した通りにこちらがスカッとする復讐を果たしてほしいし、後味が悪くなるようなやりすぎなだと感じることはしてほしくないという身勝手な楽しみが存在する
アーサーは元々ひどい人生歩んで生きたところに加速度的にトラブルや社会情勢が重なって
失うものは自分の命ぐらいという存在になってしまうのだけど
彼の境遇に感情移入してみてきた身としては悪党になってしまうのは仕方ないにしても
悪辣なことはしてほしくないと思ってしまう

どこからが悪辣で正当性のない八つ当たりになるかというのは個人個人でライン引きが違うだろうけど
自分の感覚でいえば小人症の男性を殺さずに逃がしたシーンでは本当にほっとした
逆にその後の会場に向かうシーンでは悪役として覚醒したかのようなシーンが入るので
ここまでの暗い雰囲気を吹き飛ばす復讐劇がはじまるのか？彼を笑いものにした存在にどこまでやってくれるのだろうと期待をしてしまっていたりした

そのほかにどこまでが妄想で、どこまでが現実なのかというミステリー要素も面白さとして大きいように思う
いくつかのシーンは完全に妄想だったと明示されるけども
個人的に最後の警察に捕まった後、暴動民衆に囲まれ支持されるシーンは妄想なのか、あのあともう一度捕まったのかちょっと判断しかねる感じ
（感想によっては作中の出来事全てが妄想だという解釈もあるとか）
アーサーがセレブが集まる会場にしれっと侵入できちゃうシーンとかもあって、そこは妄想であるみたいな感想も
自分も見ている最中は「そんな簡単に侵入できちゃうもんなの？」とおもったけど
あそこはアーサーのジョーカー的悪党の才能があったからかなーみたいな解釈してたりする
（返す返すニンジャバットマンしかみてないのに何言ってんだこいつというかんじだけども！）


●映画見る前と見た後
映画を見る前はツイッターの感想で海外での裕福の差が生み出したストレスを反映してのヒットでそれは日本でも起こっているというような話を見かけて
自分自身、貧民側であると大いに思っているので
そういうストレスをジョーカーがいかに反映させ悪役としての答えを見せてくれるのかと思っていたのだけれど
作中でその問題で騒いでいるのは民衆であってジョーカー自身は貧困に悩まされてはいるものの彼の一番の問題はそこではなかった
そういった民衆のうち暴動を起こす人達はジョーカーをヒーローとして祭り上げるもののやはりジョーカーに好き勝手自分の理想の暴発者イメージを押し付けているだけで理解しているわけではない
なのでジョーカーをちゃんと見た後にそういう感想もしくは言説をみると個人的感覚としては首をひねるようになった

もちろん貧民層、富裕層といったレイヤーでの話は社会的にはも自分的にもすごく重要な問題だけど
そこからジョーカーが誕生するといわれてしまうと現実の理解されない人（達）に勝手なイメージ押し付けてる
映画の中の暴動民衆と同じになってしまわないかなーとか
いや映画としての面白さはむしろそこにある気がするので難しいところな気はするけど



unityでボーンコンストレインするC#スプリクトを書いたものの……

unity マリオメーカー

書いたものの結局必要なかったというか、そもそもの原因を勘違いしていたという結論


事の始まりとして自作ゆかりさんを一度テスト的にunityに持ち込んでモーション当ててみて大丈夫かを確認するところが始まり

unity標準のhumanoid という人体構造用のボーンを踏襲することでアセットストアなどで売られているモーションを適用できるようになるのだけども
これは当然MMDのときとは構造が違う

それでまぁ多少はすり合わせればいいのだけど、腕のねじりを分散緩和するようなボーンがどうやら組み込まれていないっぽい
（ただ肩だとかの？さらに親や子のほうにねじれ具合を分散するなどの対策はされているらしい、いま見直してもうちょっと正確な理解になったがこの時点ではあまり把握していなかった）
参考：UnityでHumanoidリグを利用する際の肘関節の捩れを調べる


そもそも最新のunityには回転コンストレインのスプリクトがある
参考：Unityにおけるボーン回転コンストレイント
じゃぁhumanoidボーンから部分的に並列的な親子関係にして、
自前のボーンのほうにコンストレインで値を移してあげてねじりだけMMDと同一構造のところに同じように分散したらいいのでは？
と思いblenderでのボーン構造見直しもそれを見込んで行って
unity上で設定して動かしてみるとなんかずれる

ここで勘違いしたのが「unityの回転コンストレインってワールド空間判定でやっているのでは？だからずれるのでは？」
やったことないスプリクトに挑戦する前に、もうちょっと試して確認するべきだったよね
まーそのうちやろうとか詳しくなりたいと思ってたことであるので知識、学習的に無駄なことはなかったんだけども

さんざん勘違いしてたと書いているから今更なのだけども
unityの回転コンストレインはちゃんとローカル軸を見てやってくれてたっぽい
ということを自前のスプリクト完成してから
「あれ？こっちもずれる上にずれ方に見覚えしかないぞ！？」
という

自前のスプリクトもunityのコンストレインもunity上でキューブとか出して
簡易的に対象のボーン回りと同じ親子構造作って試したらどっちも一応正常動作してて
完全に別の原因ですよ……


そうなると何が原因かが謎で頭抱えるのだけど
先ほど上に「もうちょっと正確な理解になった」と書いたhumanoidボーンについて
上腕のねじりを肩とかにも分散してるっぽいというのが
今ちょうど上腕で試しているのでそれが原因か？とかちょっと思っているところなんだけども
（でもねじりを分散したとき（根本はxz回転のみコンストレイン、子供のほうでY回転を0.25づつ請け負う）に思いっきりずれるのであって、根元でxyz全部請け負ってコンストレインする分にはずれない（少なくとも見た目上は）なのでやっぱり違うかな……）
それはそれとしてせっかく参考書とか買って読みふけって書いてみて
正常に動いてはいるからスプリクト晒しとけ！！
という奴ですはい（結論）

ただまぁ返す返すunity標準のコンストレインで用は足りるというかそっちのほうが優秀というかなので
自分と同じくスプリクトやり始めた人がみたらなんか参考になるところあるかもぐらいの感じ
（例によって自分がすぐ忘れるからコメント入れまくったつもりなので）


using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEditor;


[ExecuteInEditMode]　//これをつけることでゲームすたーとしていないエディター上でも動作するようになる
public class LocalRotationConstraints : MonoBehaviour //通常はMonoBehaviourを継承することでunity用の各種メソッド？を使用できる
{
//public……どこからでもアクセスできる変数ですよという宣言
//private……このクラス内からしかアクセスできないですよ（このクラスの外では使用しませんよ）という宣言
//後程スプリクトを書き換える時などに、このクラス自体が不要じゃね？となったとき、publicが使われていたら
//いやどっかでこの変数使ってるはずだぞアブねー確認！となる為のものらしい

//各型で変数を宣言（といってもVector3は正確にはクラスだったらしい……）
//これで登録欄も同時にできるっぽいがボタンなどは無理なので下のカスタムインスペクター用の記述で改めて書く
//（するとそちらが優先される？）
public GameObject ConstraintBone;
public Vector3 ThisBoneRotation;
public Vector3 ConstraintBoneRotation;
public float ConstraintWeight;
public bool ConstraintX;
public bool ConstraintY;
public bool ConstraintZ;
public bool ConstraintActive;




// 初期化に使用 最初に一回だけ実行される処理ということ、繰り返さなくていいならここに記述してしまう
private void Start()
{
//リアルタイムで動いてほしい処理なので個々の記述はとくになし
}


// Update はフレームごとに1 回　毎フレーム繰り返す、常時処理されるということ
// FixedUpdateは一定間隔（フレーム落ちしても本来のフレームタイミングでということ？）
// FixedUpdateであるべきな気がするけどExecuteInEditModeで反応しなかったのでいったん通常のUpdate
private void Update()
{
if (ConstraintActive == true)
{

//vectore3の入れ物を用意しておく　ゼロで初期化済みにしておく
Vector3 Temporary_Value = Vector3.zero;


//Mathf.DeltaAngleは角度の差を-180～180の間の最小で返してくれる350と20みたいな時でも330ではなく-30となって実際安心
//それぞれの軸の有効無効判定もして有効なものだけ処理
if (ConstraintX == true)
{
Temporary_Value.x = Mathf.DeltaAngle(ConstraintBoneRotation.x, ConstraintBone.transform.localEulerAngles.x);
}
if (ConstraintY == true)
{
Temporary_Value.y = Mathf.DeltaAngle(ConstraintBoneRotation.y, ConstraintBone.transform.localEulerAngles.y);
}
if (ConstraintZ == true)
{
Temporary_Value.z = Mathf.DeltaAngle(ConstraintBoneRotation.z, ConstraintBone.transform.localEulerAngles.z);
}

//その差分をこちらのベースと足してあげてからクォータニオンに変換して入れる
this.transform.localRotation = Quaternion.Euler(ThisBoneRotation + (Temporary_Value * ConstraintWeight) );

}
}




//以下はボタンが押されたとき用の処理

//通常時のコンストレインされる側ボーン角度を取得
//角度はlocalRotationだとQuaternion（xyzw）で取得する必要があることに注意
//Vector3でほしいときはlocalEulerAngles
public Vector3 GTBR()
{
Vector3 Temporary_Value = this.transform.localEulerAngles;
return Temporary_Value;
}

//通常時のコンストレインする側ボーン角度を取得
public Vector3 GCBR(GameObject NowBone)
{
Vector3 Temporary_Value = NowBone.transform.localEulerAngles;
return Temporary_Value;
}

/*
//間違えた時のためにボーン角度リセット
//必要かと思ったがRevert的なリセット方法というかデフォルト時の値取得方法なさそうなのでいったんオミット
public void ResetBone(GameObject NowBone)

{
this.transform.localRotation = Quaternion.identity;
NowBone.transform.localRotation = Quaternion.identity;
}
*/

}







//ここから下はスプリクトのUI（カスタムインスペクターというらしい）の描画に関する記述-----------------------------------------------------------------------------------------------------------

[CustomEditor(typeof(LocalRotationConstraints))] //属性を与えて（？）どのスプリクトをカスタマイズするのかを指定
public class LRCEditor : Editor //カスタムインスペクターの場合はEditorを継承しないとダメらしい（ので別クラスで記述することになる）
{



public override void OnInspectorGUI()
{
// 「target は処理コードのインスタンスで 処理コードの型でキャストする」
//クラスを宣言しなおしてそれをインスタンスで取得しているということでよいかな？？
LocalRotationConstraints LRC = target as LocalRotationConstraints;


//シリアライズオブジェクト？関係あるかもしれないのでコメント扱いで残している
//serializedObject.Update();
//ボーンを登録するフィールドを改めて設定と取得
LRC.ConstraintBone = EditorGUILayout.ObjectField("On the constraining side", LRC.ConstraintBone, typeof(GameObject), true) as GameObject;
//こちらもシリアライズオブジェクト
//serializedObject.ApplyModifiedProperties();

//間にスペース作る
EditorGUILayout.Space(); EditorGUILayout.Space();

//このボーンの基本角度入力欄
LRC.ThisBoneRotation = EditorGUILayout.Vector3Field("ThisBoneRotation", LRC.ThisBoneRotation);

//ボタンを表示するのと同時に、押されたときにTrueを返すので一緒にif文に含めてしまうことで押された時の処理も書けるようにということらしい
if (GUILayout.Button("GetThisBoneRotation"))
{
// 以下はボタンが押されたときに実行される処理
//上で記述した角度取得メソッドを呼び出してこのボーンの角度を取得
LRC.ThisBoneRotation = LRC.GTBR();
;

}


//上と同じ内容の拘束側ボーン版
LRC.ConstraintBoneRotation = EditorGUILayout.Vector3Field("ConstraintBoneRotation", LRC.ConstraintBoneRotation);
if (GUILayout.Button("GetConstraintBoneRotation"))
{
//このボーンの角度ではないので対象ボーンをゲームオブジェクトとして渡すところだけ上と違う
LRC.ConstraintBoneRotation = LRC.GCBR(LRC.ConstraintBone);



}



/*
//スプリクトが変に動作したときに各ボーンの角度おかしくなった時用の角度リセットボタン
//いったんオミット
EditorGUILayout.Space(); EditorGUILayout.Space();
if (GUILayout.Button("RotationRest"))
{
LRC.ResetBone(LRC.ConstraintBone);

}
*/


EditorGUILayout.Space(); EditorGUILayout.Space();

//コンストレインの影響度
LRC.ConstraintWeight = EditorGUILayout.FloatField("Weight", LRC.ConstraintWeight);

//コンストレインのXYZそれぞれのONOFF用チェックボックス
LRC.ConstraintX = EditorGUILayout.Toggle("X", LRC.ConstraintX);
LRC.ConstraintY = EditorGUILayout.Toggle("Y", LRC.ConstraintY);
LRC.ConstraintZ = EditorGUILayout.Toggle("Z", LRC.ConstraintZ);

//コンストレインをアクティブ状態にするかどうかのチェックボックス
LRC.ConstraintActive = EditorGUILayout.Toggle("ConstraintActive", LRC.ConstraintActive);
}


}

数年前のblender用pythonと違ってC#だから
スペース修正しなおしとかしなくてもコピペで動くかも、動かんかも





そしてどうでもいいけどマリオメーカー２かってコース作ったのでついでで晒しておく！
（本当に関係ない）

QSP-0YY-LNG
森をコイン集めながら登っていくコース
現在クリア率30％ぐらいなので平均して三回チャレンジしたらクリアできてる感じの難易度のコース
普通にマリオにありそうな感じのを作りたいと思ってやったので難易度的にもあっている気はする……？


RXH-831-L6G
前作でも作ったパズル系ステージがいま見直すとごちゃごちゃして
パズル以前のところが把握しずらいのではと思っていろいろ整理しなおしたり簡略化したりしてみたコース
壁を壊さないと進めないけどどうやって壊せる形にもっていくかみたいな感じ



前作があっての今作だからかネットで作られているコースも落ち着いた難易度のものが前作より多い印象でヌルゲーマーには大分ありがたい……

あとコース作ってもどっかで晒してみて、誰かの評価なり足跡なりつけてもらわないと
野良の人というかマリオメーカーでコースをランダムに遊ぶとかには限りなく引っ掛かりにくいようなので
コース作った人はどこかでガンガンコースIDさらしたほうがいいと思う
（自分のコースも某所で晒してみる前は足跡一個もつかなかったし、
　ぎゃくにいいね！してくれた人のまだ遊ばれてないコース遊んだらそのコースのタイムが更新された＝ほかの人も遊んだみたいなお知らせが割と早めに来たりとか）




しばらく時間あったのでのんびりながら期間的には集中していろいろ手を出せていたのだけど
また普通に戻ってしまうので
次のゆかりさんをunityに持ち込む進展報告の更新はいつになるやら……

PC新調したのでMMDVR動画作ってた（unityシェーダーはどうした）

youtube VR mikumikudance mmd

いやーセルシェーダーおよびそれ用にゆかりさんをunityにもっていく作業をすすめようとはおもってたんだけども
前からつくってみたかったとういうか実際いくつかは作ってたんだけど
その時はPCのスペック低くて低解像めなのをMMD標準のシェーディングでだすのが手一杯だったりとか
当時は360度動画しか投稿できなかった（記憶違いじゃなければ）で
後方特に何も用意してないからその分解像度的に無駄がとかあって
せっかくMMDのゆかりさんも更新したんだからさーと一個出してみたら興が乗ってという奴ですはい







11/08追加投下していたのを張ってなかったので追加で張り付け




（以下の話は追加分にかんしてはないときに書いた話なので整合性ちょっとおかしくなってるかも）

で、一番上のは以前出したのと同じでほぼ固定カメラなのだけども
二つ目以降はカメラの視点切り替えとかもやってみたりとか
下のになるほどカメラがエロく動くようになっていっちゃってる

VRでカメラワークってどうすんだ？みたいなこと思いつつだったんだけども
大きく位置移動したり激しく動くものがあるタイミングで
それなら視聴者はここに視点を移動させるだろう、というタイミングでカット切り替えて
次のカットでも同じ画面位置に見てほしいものを配置しておくとわりとすんなりいけたかもしんないと勝手に思ってる
そういうところは普通のカメラワークと同じでよさそうというか

あと自分はたまにVR映像みるかー程度の使用頻度だったのだけど
昔に比べるとわりとVR酔いに耐性ができてきたっぽく昔なら速攻不快感かんじていただろうなというカメラ動きも割と普通に見れるようになっていた
ただそれは逆に自分で作成するときにVR慣れてない方が見て大丈夫かこれの感覚的判断ができなくなってしまったということでもあるので
上の三本、後半に行くほどグリングリンとはやらないもののすこし動かしたりしちゃってるので
大丈夫なもんかなーコレというのが謎なところ



あとは出力するのにEquirectangularXというエフェクトとお芋という方が作られた出力～合成の自動化マクロ（とそれで使うフリーソフト）など使ったのだけど
ちょっと問題が起こったのでメモ
というのも自分のゆかりさんリムライト表現にスフィアマップを使っているんだけども
上記の方法だと出力時間短縮のためにカメラ角度を45、-45度という感じで正面からは撮ってなくて
結果としてスフィアマップの表示が意図しない形になってしまっていた

ただ幸いにして「エミッシブで問題が起こる場合がある」とのことでの対策のために
さらに真正面からもう一度追加で取り直して重ねるというオプションがあったので
それを使用して（合成用マスクもふちにちょっとグラデを入れてあげて）とかで改善できた



そのほかはMMDのエフェクト初めてまともに使ってみたとかなので
わからんながらわりと雑に割り当てちゃったかなーとか思いつつ

よく見かけるray-mmdとかは自分のゆかりさんには完全に使えないなーというのを発見したりとかして頭抱えたり
（背景にだけ使いたかったんだけど、シーン全体に影響してしまう、その結果ゆかりさんのリムライト表現に用に用意している薄皮＆スフィアマップの表示がこれまたおかしくなるという）
あとVRはカメラの角度何度も変えて取り直して合成するからカメラの角度で反射だとかの感じが変わっちゃうのは使用できないらしいみたいな情報とかもみかけたり
フォグに関してもそういうのあるらしかったんだけど自分の使用したhkFog_Postに関しては大丈夫そうだったかな

HgDOFの被写体深度のぼかしもやっちゃうと低解像度に見えちゃうとかで避けたほうがいいらしいとかみかけたのでかなり弱めに使用してみたりとか
（シーンの途中で思いっきり強くするとかやってみてもよかったかもなと今更ちょっと思った）

AutoLuminasも初めてつかってみたのでこういう設定をモデル側でしとけばいいのかーとか
ゆかりさんも対応させたほうがよかったかなとか今更ちょっと思ったり
それだけのために更新するのもうーんとおもうのでやんないけども


という感じの思ったこと垂れ流しメモ
明日からはまたunity関連に戻るかなー
ゆかりさんをunityにもっていくにあたってボーン構造をunity標準の名称、親子関係に修正し始めてるのだけど
ウェイトの割り当て直しとかも発生してしまうっぽくてなかなかめんどい（ので現実逃避してた面は否めない）

最後にMMDのエフェクト使った通常の映像もニコニコに投稿したりしてたので
ついでにペタッとしておく

セルシェーディングのシェーダー作るにあたってライト周りのことメモ殴り書き（またもうちょっとわかったり整理できたら追記していくやつ）

unity Shader

ちょっとセルシェーディングやるにあたって複数のライトがあった場合の処理をちゃんとやろうとして
その結果調べたりしたことやブックマークがそこそこの量になってごちゃごちゃしてきたので
一旦メモ的に書いてみることで脳内整理＆今後自分でも見返せるようにする
（とはいえふわふわ認識のままごちゃごちゃ書くやつなので他人が見ても意味なさそう）

まず通常のシェーディングとして陰影を形成して
それを明るい領域、暗い領域になるように絞った後それをマスク化してという流れになるんだけど
それをやるためには一つのPass内で全部の明暗を処理しないといけない（と思う）
（Passをまたぐと前のpassの情報を取得、調整、再利用というのは基本的に無理っぽい重ね書きレベルのことしかできない感じ？）

ここでDeferredとForwardBase＆ForwardAddとVertex Litの三種類があるので
セルシェーディングをやるにあたりどれが一番いいのかというのに今さら行き当たった感じの話


・Deferred（まだあやふやだがセルシェーディングには向かないっぽい？）
g-bufferといういくつかの材料（ワールド座標ノーマル情報だとかデプス情報だとか、メタリックだのベースカラーだの）を全オブジェクト描写してしまって最後に一括処理するような感じっぽい？
でこのg-bufferに陰影があればよかったのだけどそれは最後に一括処理されるときにはじめて生成されるっぽい？
(と思っていたのだけどこの記事を書くために調べなおしていると陰影情報のみ描写したものもあるっぽい情報があるので後々ちらべ直す……
　今から調べると話がそれるのでいったん保留)
のでセルシェーディングの材料としての単純な陰影情報としては利用できないっぽい（？）

あと全オブジェクトを一括処理する都合上プロジェクト全体に影響が出る感じで処理の切り替えが必要っぽいとか
（例えばVRChatだと（やったことないけども……）forwardbase設定らしいので多分駄目）
半透明は基本使えないとかもあったりするらしいけどまだあやふやなのと陰影情報の取得には関係なくなってくると思うので割愛


・ForwardBase＆ForwardAdd（セルシェーディングに最も向いてる？）
従来通りオブジェクト事に描写していく方式（であってる？）
ただunityの仕様だと（ほかのソフトでも同じ？）一つ目のPass内でとれるライトの情報には限界があるっぽい？

主な参考先
VRChatの皆に手軽に綺麗になってほしくて作ったシェーダーの話

・_WorldSpaceLightPos0等
unityが一番重要だと判断したライト（基本的にDirectional Light）が一つだけ情報が取れる

・unity_4LightPosX0等
あまり重要でない（重要度二番目以降ということ？）ライトが四つまで情報をとれる

・ShadeSH9等
それ以降のライト及びライトプローブにベイクされた情報を取得できる

ということのようなんだけど（それぞれさらに精度とかあるようだけどそこはいったん省く）
unity_4LightPosX0でとれるライトの情報がいまいちしっくりこない……
ビルトインのシェーダー変数だと「重要でない最初の 4つのポイントライト」という説明だけども
・ポイントライトのみ
シンプルなシェーダー記述で試しなおしてみたもののスポットライトも反応しているっぽくて
？
・重要度
二番目以降という解釈でいいのかもっと後ろのほうなのか……？というのが謎
というのも以前シンプルな構成で試した時に一番近くて強いポイントライトが反応してなかったからなんだけども
これはまた試しなおしたらちゃんと反応してたっぽい……
前の時は自前の記述部分がおかしくてそういう風に見える動作になっちゃってただけとかなのか？というところが確信が得られないので不安

さらにForwardAddというのがあって
こっちを使用すればすべてのライトを順番に処理してくれるようなのだけど
これがもう２Pass目以降になってしまい、１Pass目で描写したものに加算（おそらく）で上乗せする形なので
セルシェーディングの領域分けに利用するのは不可能なんじゃないのかなと思う
（１pass目でセルシェーディングしたものに重ねることはできるけどそれはもう普通のシェーディングが重なったどっちつかずのものになっちゃうのではというか……）
なおかつ先ほどunity_4LightPosX0で処理したライトとの重要度的な比較でどっちが重要だと判定されているわけ？というのもまだわかってないのも痛い……
（仮に_WorldSpaceLightPos0系、ForwardAdd系、unity_4LightPosX0系の順で重要だとされるならば、ForwardAdd無理にでもしないと二番目に重要なライトは処理されていないということになってしまう……）

とかいろいろ知識不足なところもありつつでベストとはいいがたい感じがしてしまう

・Vertex Lit
unity_LightPosition[]を使用することで一つのPASS内で重要なライトを8個まで処理できる！
主な参考先
[Unity] ひとつのPass内で複数のライトを使う
Unityでハマッたこと一覧メモ
ライトにもいろいろ種類があるからややこしい処理をさらに自前でしなきゃいけないものの
情報取得という点では申し分ないしこれ使えばいいじゃん！
とおもったらどうも落ち影を受けるということができないらしい……
（自分でいろいろ書こうという感じで超頑張れば別なのかもしれないけども……）
あがー……

・減衰の取得に関して
unity_4LightAtten0[0~3]
unity_LightAtten[0~7].z
でそれぞれ取得できるっぽいもののそのままで使用できるわけではないというか
これをそのままフラグメントシェーダーの最終出力に突っ込んだとしても
ポイントライトから離れるにつれ暗くなるという本来イメージしている状態にはならないっぽい？
これまた上のほうで出した参考サイトからパクり＆改変なんだけども

float4 worldPos = mul(unity_ObjectToWorld, v.vertex);
//ライトの位置を取得
float4 lightPosition = float4(unity_4LightPosX0[i], unity_4LightPosY0[i], unity_4LightPosZ0[i], 1.0);
//ライトの位置と頂点位置を減算して方向を取得（長さをとりたいので正規化はしない）
float3 lightDirection = lightPosition.xyz - worldPos.xyz;
//内積でベクトルの長さをとる
fixed lengthSq = dot(lightDirection, lightDirection);
//ライトの減衰を取得？
float attenuation = 1.0 / (1.0 + unity_4LightAtten0[i] * lengthSq);

という感じでいくつか材料的な値をとってきて最後に計算してやることでやっとイメージ通りの減衰の出力になる
（上の図の場合はattenuationがその出力内容）
ただ最後の行の計算の意味がさっぱり理解できてないけどなー！！！

ただポイントライトはこれでいいんだけど
スポットライトの場合が全然わからん……という段階

・ライトのIntensityの取得に関して
_LightColor0だとかで色を取得する際に
ライトの色のrgb　x　Intensity
という形で混ぜ込まれて渡されるらしい？
なのでIntensityが欲しい場合は
_LightColor0同士で内積を出せばベクトルの長さとしてライトの強さを取得できるっぽい
（これまた上記サイトの内容）
色にライトの強さ混ぜ込まれているというのも知らなかったし
内積は方向が一致してるかしてないかを-1～1で取得できるという解釈だったのだけど
それは正規化されたベクトルの場合で、そうでない場合は同じもの同士をやることで長さ（強さ？）を取得できるというのを知らなかったのでメモしておく


ということまでわかった段階が今

これまでForwardBase（addは使わない）でセルシェーディング書いてきたものの
複数ライトを処理しなきゃという段階になってライトの重要度の判定がいまいちわからんとかもあり
じゃぁちゃんと複数ライト処理できる方法あるらしいからそっちに変更するかとしたものの
それがVertex Litで落ち影もらえないのはダメよな……となり
じゃぁやはりForwardBaseでできる範囲内で頑張るしかないのか？？


で、そうなってくると取捨選択の話になってくる気もするけどもForwardBaseだけだと不安な部分について
・二つ目のDirectional LightってShadeSH9とかで考慮してくれてるのか？（してくれてない気がする）
・上でも書いたけどForwardAddで処理される内容と判断されたライトが抜け落ちるとかない？（これは試しなおしたところだと大丈夫そう？以前のシェーダー記述が駄目だっただけ？）
・スポットライトはShadeSH9でしか処理されてないとかっぽいけど大丈夫なもんなのか？
（そもそも浅く広く調べる感じになってしまっているのもあってまだDirectional Lightとpint lightしかシーンにおいてなかったとかもある……）

という点をつぶしていかないとどうにも……

ただ今のところForwardBase以外に選択肢はないように感じるなぁ結局
正直シェーダー自分で頑張って書くというレベルまでやるなら
複数ライトの情報ぐらい制限なく取れるイメージだったけどエンジンごと（もしくはもうここはそういうものでどのエンジンでも同じ？）の制約というかできることできないことあるのね……



というあたりのことをやってたら脳内ごちゃごちゃしてきたので書き出してすっきりしたいという話だった
（前の記事に追記してもよかったんだけどこれだけで長くなりそうだったから別記事としてメモすることにした……）
ただこれ書き始めたところでDeferredでも陰影情報とれるっぽい感じのを見かけたので（勘違いかもだが）まずそれもちょっと調べたいかな（優先度は低めで）

あまりに内容が難しい、もしくはForwardBaseのみでは無理っぽいライト情報は切り捨てる方向で行くしかないのかなーとかも考えないと
わかんないのでぼーっとしてしまうみたいな時間が長くなるばかりかもしれない……