hibitの技術系メモ

数学とか3Dとか翻訳とか

アバターを高速移動させたい時に便利な、コライダーボードを用いた移動方法

!注意事項!

 以下の事項に十分に注意した上でご使用ください。

  • ワールド製作者の意図しない動き(ギミックの崩壊 等)をもたらす恐れがあります。
  • ワールドの舞台裏(通常ユーザーが入れない領域)を見られることが不本意な製作者もいるかも知れません。
  • 演算負荷が高いので、他のユーザーのFPSを低下させる恐れがあります。

 Publicや不特定多数が集まる場、とくにギミックがあるワールドでの濫用は避けましょう。

ここから本文

 人はいつの時代も逃れたがる。仕事から、家庭から、社会から、重力から、物理法則から……。

 という訳で、バーチャル世界の中だけでも物理法則を無視して高速移動したい人向けにコライダーボード現象*1を用いたコライダーダッシュ/ジャンプのやり方を紹介します。

 以上のような形でワールドを縦横無尽に動き回ることができます。ついでにアニメーションオーバーライドの基本的な解説もしていきます。

オブジェクトの実装

f:id:hibit_at:20181220014123p:plain

 まず高速移動させたいアバターを選択して、

f:id:hibit_at:20181220014224p:plain

「Create Empty」で空のGame Objectを作成します。

f:id:hibit_at:20181220014442p:plain

 さきほど作ったGame ObjectのComponentに「Box Collider」を追加。

f:id:hibit_at:20181220020908p:plain

 Game Objectに以下のような設定を加えます。

  • TransformのPosition…行きたい方向。
  • Box ColliderのCenter…上で入力した座標と逆の座標を入力。
  • Box ColliderのSize…yのサイズだけ0。

 コライダーボードは、Game Objectのコライダーとアバターのコライダーが干渉した場合、Game Objectに引き寄せられるという現象です。

f:id:hibit_at:20181220015653p:plain

 オブジェクトのコライダーがアバターの足元にある場合、オブジェクトが存在し続ける限り「干渉→テレポート」という無限ループが繰り返されるため、結果として高速移動ができます。オブジェクトのPositionが移動方向になります。コライダーの中心は、アバターの足元に持っていくためにPositionの座標をマイナスする必要があります。

 Positionの設定としては、

 あたりがオススメです。ダッシュにも上方向の移動の成分を入れていますが、これについては後述します。あと、コライダーボードにはオブジェクトのRotationも反映されるため、高速回転、高速きりもみ等も再現できますが、まあ興味ある人はどうぞレベルですね。

f:id:hibit_at:20181220020030p:plain

 設定が終わったらGame Objectの脇のチェックを外して非表示にしておきましょう。これを忘れると一生高速移動し続けるアバターになり、VRChat上での操作もままならなくなります。表示/非表示で移動モードとそうでない時を切り替えられる状態にすることが必要です。次節でその手順を解説していきます。

アニメーションオーバーライドの設定

f:id:hibit_at:20181220021619p:plain

 Animationウィンドウをクリック。

f:id:hibit_at:20181220021845p:plain

「Create」ボタンをクリック。

f:id:hibit_at:20181220021921p:plain

 適当な名前で保存。画像では「dash」としていますが、別に何でもいいです。

f:id:hibit_at:20181220022042p:plain

「Add Property」でさきほど作ったオブジェクトの「Is Active」を追加。

f:id:hibit_at:20181220022840p:plain

 初期状態だと1秒(=60フレーム=1:00)後に設定されているキーフレームを1フレーム(0:01の位置)後まで移動した後、両フレームの「Is Active」のチェックボックスをチェックに。

 以上でアニメーションの設定は終わりですが、今度はそれをアニメータに入れていきます。

f:id:hibit_at:20181220023541p:plain

「Assets > VRCSDK > Examples > Sample Assets > Animation」の中にある「Custom Override Empty」をCtrl + ドラッグで作業フォルダにコピー。コピーした後は名前をわかりやすいものに変えておいた方が良いかもです(検索で紛らわしいので)。今回の例では「Collider Board」にしています。

f:id:hibit_at:20181220224503p:plain

 アニメータファイルを選択すると、インスペクタ欄にずらっと色々でてきますが、その中の「HANDOPEN」に先程つくったアニメーションファイル(例では「dash」)をドラッグ。なぜHANDOPENなのかは後述します。他の動作を割り当てたい場合、下の図に従って対応したアニメーションファイルを設定していきましょう。

f:id:hibit_at:20181220024849p:plain (正確な作者は存じ上げませんが、とてもわかりやすい図。ありがたく転載させていただきます)

 今度は、アバターにアニメータファイルを設定して終わりです。

f:id:hibit_at:20181220224654p:plain

 アバターのインスペクタにある「Custom Standing Anims」にさきほど作ったアニメータファイルをドラッグ。これで、

  • コントローラを操作する。
  • 操作に対応したアニメーションが発動する。
  • アニメーションにより、非表示だったGame Objectが表示になる。
  • コライダーボード現象が起こりアバターが高速移動する。

 という機能を持つアバターが出来上がりました。

実際に動かしてみる

 アバターをVRCに上げたら、今度は実際に動かしてみましょう。あと、大事な部分を言い忘れていましたが、コライダーボード現象は床の上にいる状態だと発動しません。ジャンプするなり段差を移動するなりでなにがしか落下している状態を作り出す必要があります。

 例でHANDOPENに設定したのはこのためで、「右親指でジャンプ→他の指でグリップボタンを押す」という操作がやりやすいからです。あと、HANDOPENはグリップボタンを離すだけでアニメーションが解除されるので制御が楽というのもあります。また、ダッシュの動作に上方向の動きを入れた方がいいのもこのためで、ダッシュで高低差を稼ぐことでHANDOPEN以外の操作に割り当てたアニメーションも発動させやすくなります。

 皆様も用法用量を守ってよき高速移動ライフを(慣れない内はわりと酔います)。

*1:コライダーテレポートと呼ぶこともあります。私の場合はうれいしさん、あーあーあ~さん→SHIARUさん→私、という形で教えていただきましたが、他にも色々な方が編み出していたようです

TOEIC900点とれませんでした

 どうも、タイトルの通りです。去る11月18日にTOEIC(L&R)を受けてきました。諸般の事情があってハイスコアが必要な状況で、900点を目標、800点を最低ラインとしていたのですが、先日公開された結果はL430+R415で845点でした。

f:id:hibit_at:20181214020539p:plain

 普段Twitterアメリカ英語とイギリス英語の違いが~」とか呟いたり、VRChat内で「まあ外国人が来たら俺が対応するから」的な空気出したりしているくせにこのザマだよ!

 実はTOEICを受けるのはこれが2回目で、1回目に受けた時は学生の時で760点(うろ覚え)でした。その時に比べれば、個人海外旅行も何回か経験したし、英語圏の友人も増えたから、その気になって1か月ぐらい本気で対策すれば900も夢ではないかも……!? という甘い考えでいましたが、余裕で甘かったですね。

試験当日の様子

 当日はリスニングが全然聴き取れなくて(結果的にはある程度は聴き取れていたみたいです)50問目ぐらいで泣きそうになっていました。試験が終わった後もしばらく放心状態で、家に帰ってからも「この一か月の努力はなんだったんだ……」とふて寝してました。

↑ふて寝の様子

 リーディングは結構できた感触だったので(結果的にはそんなことはなかった。我ながら点数予想がザル過ぎでは?)、「L320+R480で800点取れれば御の字かな」という予想でした。いやまあでも本当に、700点台にならなくてよかった。

良かった点…リーディング全般

 やったことがある人ならわかると思いますけど、TOEICのリーディングは時間との勝負です。とにかく大量の長文を読まされます。最初に受けた時は長文の物量に圧倒されてしまい、後半は完全に塗り絵状態でした(初心者あるあるらしい)。そのことだけは覚えていたので、とりあえず75分で長文を走りきる! ということだけは意識して訓練してきました。本番も良いペースで解き切ることができたので、そこは素直に自分の成長を認めたいです。

悪かった点…リスニング(Part2)

 Part2は短い質問に答えるやつです。長時間の会話は2,3語聞き逃してもなんとなくストーリーがわかりますが、短い質問は1語聞き逃すと終わりです。試験当日は結構終わっていました。反省。

TOEICの住人、物分りよすぎ説

 ところで、TOEICに出てくる登場人物ってえらく物分りがいいですよね。飛行機が遅れるけどクーポンで我慢してとか、渋滞にハマったからスケジュールを変更してくれとか。「飛行機が遅れるのに、200ドルのクーポンなんかで納得できるか! 訴えるぞ!」とか「渋滞にハマったとか寝言いってんじゃねえ! 這ってでもこい!」みたいな展開があっても面白いと思うのですが。そこまでTOEICに詳しくないので、実はあったらごめんなさい。

セル結合の記事についての釈明

 先日、セル結合について以下のような記事を投稿したところ、予想外の反響をいただくことになりました。

deux-hibi.hatenablog.com

 その中には同意の声も批判の声もあって、まあそれはそうだなという感じなのですが、こちらの伝え方が明らかにまずかった部分もあって、そこは非を認めて補足・訂正させていただくべきかなと思い、記事を書くことにしました。

タイトルが不適切

 第一に、セル結合を全否定するようなタイトルは明らかに余計でした。炎上目的と言われても仕方ないです。ある程度ぶっちゃけると、まさかここまでバズるとは思わずに適当にタイトルつけてしまったのですが、これはさすがに私が悪かったです。申し訳ありませんでした。全面的に非を認め、元の記事にも釈明コメントをつけさせていただきます。

お前は一切セル結合してないのか

 何を隠そう、かくいう私も労の場では当たり前のように結合しています。私にも生活があるのでな。場合によってはセル結合も必要になる、というのは十分理解しています。ただ、そこも含めて詳しく説明するべきだったな、というのがあるので、次節以降述べていきます。

セル結合が悪かは用途による

 エクセルは編集用と提出用とで使い方が異なり、編集用データでセル結合するな、それはさすがに百害あって一利なしだよ、というのが一番言いたかったことです。

f:id:hibit_at:20181213040201p:plain

 けして、一切のセル結合を認めないという意図ではなかったです。が、十分そう読めてしまう内容だったので、それは私が悪かったです。

f:id:hibit_at:20181213040229p:plain

 あと、エクセルをデータベース用途でのみ使えという風に取れる書き方もしてしまったので、それもそうではなかった、ということも合わせてお伝えしたいです。

f:id:hibit_at:20181213043109p:plain

 また、編集用と提出用とで明確に分離できていないワークフローも問題だよね、ということも言いたかったことです。

f:id:hibit_at:20181213040256p:plain

 ただ、これは組織全体としてのITリテラシーやワークフローの問題であり、簡単に変えられるものではなく、個人がどうエクセルを操作するかの範疇を超えています。なので、これから先は議論してもしょうがない領域かなと思います。というか、この部分については問題提起とか啓蒙とかというより、こういう凝り固まった社会ってままならないよね、という嘆きのポエムのつもりでした。簡単に変えられないからこそ、同じような論争が何十年も続いているのだろうなぁ……。

技術系を標榜するなら解決策を示せないの

 上にも述べたとおり、組織のワークフローの問題であり、局所的解決法があればみんなハッピーという問題ではないと思いますが、一応私の場合の局所的解決法も示しておきます。

 前記事のAやBをCにする方法ですが、VBAで表の範囲をRangeで選択した後に、Unmergeした後、if cells(i,j) = "" then ; cells(i,j)=(i-1,j) ; end ifというイテレーションを繰り返して整然データを作ったりしますね。ソースコードを貼ろうと思いましたが、VBEを開いてコードをコピペするスキルがある方はそもそもここら辺の問題で悩まないと思うので省略します。

 あと、前記事のCをBっぽく見せる方法については、詳しくない方向けに少し丁寧に解説します。

f:id:hibit_at:20181213043457p:plain

 表を選択して「条件つき書式」「新しいルール」

f:id:hibit_at:20181213043601p:plain

「数式を使用して~」で=左上のセル=その1つ上のセルという数式を打ち込みます。

f:id:hibit_at:20181213043712p:plain

 数式欄の右下にある「書式(F)」を押して、文字色を白色に。

f:id:hibit_at:20181213043817p:plain

 すると見かけ上はBっぽくなります。空白に見える部分も文字はちゃんと入力されているので、集計はできます。(12/16追記)ブコメで「真っ白よりはうすいグレーとかの方がよいのでは」という指摘を頂きました。データがあるのを明示したい場合は確かにそうですね。指摘ありがとうございます。

 あと、コメントでいただいたSUBTOTAL関数(AGGREGATE関数の方がより高機能ですが)は結局「ピンポイントで範囲を指定する」労力がかかるので、私は選ばないですね。小計を入れたければ別シートにするしかないかなと思います。

曖昧な仕様を許しているMicrosoftに文句を言うべきでは?

 それもそうですね。おい、Microsoft! そういうところやぞ! コラ! わかっとんのかワレ!

怒りすぎ、口調がキモい

 これは純粋に驚きだったのですが(我ながらサイコパスみたいな発言だ)、私は別にそこまでマジギレしていた訳ではないのですよ。「セル結合に両親でも殺されたのか」というコメントをいただきましたが、幸い両親は健在です。もちろん、セル結合のここはダメだなあという積年の思いはありまして、それを淡々と書き記したつもりなのですが、上のような反応をいただいた訳です。

 それで、改めて自分の文を見てみたら「言われてみれば確かに怒ってそう」とか「言われてみれば確かにキモいわ」とかいうことに気付いて、自分の認知が歪んでいたなと思いました。と言うのも、単語のチョイスや言い回しが芝居がかって大袈裟ですよね。大悪とか、弾劾とか、0.5秒とか。ただこれって、怒りのあまりそうなったというよりは、文章の流れ上、そういう戯画的な表現になったという方が実情に近いです。とはいえ結果的にできた文章がアレだったので、そこは配慮をすべきだったなと反省しています。今回の件である程度懲りたので、以後気を付けることにします。

 なんというか、自分には「おちょくり癖」「不謹慎癖」みたいなものがあって、言葉遊びでふざけられるポイントを見つけたら徹底的にふざけてしまう悪癖があります。今この文をご覧になっている皆様も、随所から隠しきれない「ふざけオーラ」のようなものを嗅ぎとっているものと思われます。行を削除する例で「町田市」を出したのもその手の遊びで、「ここで敢えて町田市を出したら帰属問題でややこしくなって更に面白いな」という考えのもと、意識して悪ノリしました。

 もちろん、無用な暴言は生産的な結果を生まないことは人並みに認識しており、むしろ実生活とくに対人では絶対にそういうことを言わないように心掛けているのですが(説得力ゼロ)、今回の記事ではチラ裏気分で悪ノリが暴走してしまったみたいです。一方で「文が面白かった」と言ってくださる方もいて、それは純粋にありがたいなという思いです。自分の文章の「癖」がどういう人達の口に合う/合わないのかがわかったので、これからも皆様を(行きすぎない範囲で)アジテートしていけたらと思います。

f:id:hibit_at:20181213042656p:plain

(こういうふざけた画像を作る性格だから怒られるんだろうなあ)

(でもやめられない)

(これはもう本能のようなもの、逃れられぬ宿痾……)

全人類に告ぐ。セル結合をやめろ。

(12/13追記 タイトルや表記に過剰な表現があり、セル結合を全否定するかのような印象を与えてしまいました。そのような意図はなかったのですが、補足記事を書きましたので、併せて読んでいただけると幸いです。すみませんでした。)

 人類よ、なぜそんなにセル結合を使いたがる? それが罪深い行為とも知らずに……。

 思わず神視点になってしまいましたが、この世界にはExcelのセル結合を無意味に使いたがる人が多すぎます。いや、メリットがないことはないのですが、それを余裕で上回るデメリットがあることを意識している人が少ないように思われます。データというのは、コピペしやすいこと、集計しやすいこと、数え間違いをしづらいことが第一なので、それを損ねるような行為は許されざる大悪というべきでしょう。断固として弾劾していきます。

綺麗なデータとは

 ここにエクセルで作った、同じソースから作成した3種類のデータ(東京都の区市町村別の人口をまとめたもの)があります。(データは東京都の統計より引用)

f:id:hibit_at:20181203004906p:plain

 赤のA、緑のB、青のCは、データが綺麗な順もしくは汚い順に表を並べたものになりますが、綺麗なのは赤のAでしょうか、それとも青のCでしょうか。赤のAと答えた人は残念ながら大きな間違いです。悔い改めてください。しかし悲しいことに、世の中の業務で扱うデータは赤のAのようなものが溢れています。「え~、小計総計やエリアが分かった方が便利じゃないの?」という声が聞こえてきそうですが、そうではありません。それをこれからわからせてやる。

選択範囲が飛び火する

 例えば、このデータから区市の名前を別の表にコピーしたいとします。

f:id:hibit_at:20181203005722p:plain

 西東京市から初めて……

f:id:hibit_at:20181203005824p:plain

 ……

 本来選択したい列だけでなく、余計な列まで選択してしまいます。これでは他の表にコピーできません。市の部分だけピンポイントでコピーした後、区の部分をピンポイントでコピーする手間が必要になります。これは単純な例だからいいですけど、小カテゴリが10個あるような表でも同じ操作をするつもりですか? 余計な行さえなければ0.5秒で済んだ操作を、なぜ人間が神経をつかって再現しなければいけないのですか?

 それに、神奈川県が町田市を強引に東京都から引き抜いてしまった日はどうでしょう。ここで町田市の列だけ消そうとしても、「東京都」の列を選択した時点ですべての行を選択してしまいます。ピンポイント(ピンポイントで、というのは基本的に人間の貴重な脳味噌を酷使します)で町田市の行だけ3セル分選択して「削除(上方向にシフト)」しても列のズレが生じます。この場合、行全体を選択できる(つまり他の列に残したいデータがない)場合を除いては、セル結合を解除してから作業して、もう一度結合するしかないのです。なんという無駄な作業……。

コピペで表に貼り付けることができない

 例えば、何かの都合で国分寺市国立市については合計で数える必要が出てきたとします。こういう邪悪な表は業務ではしばしば発生します。

f:id:hibit_at:20181204082241p:plain

 他の表からコピペで貼り付けようとすると…

f:id:hibit_at:20181209011739p:plain

 ……

 この操作は結合したセルには行なえませんじゃあないんだよこの操作は結合したセルには行なえませんじゃあ。いや、悪いのは我々人間であってExcelさんサイドには何の責任もないのですが。

 最近のバージョンだとないみたいですが、バージョンによっては「結合されたセルの一部を変更することはできません」となってそもそもコピーすることすら不可能だったりします。ストレス!

コピペで表から貼り付けることがやりづらい

 結合されたセルをコピペで貼り付けると結合されたサイズのままペーストされます。

f:id:hibit_at:20181209013109p:plain

 レイアウトが一致しなかったら死亡ですね。「形式を選択して貼り付け」で「値」のみにするとサイズの不一致は防げますが、以下のようになります。

f:id:hibit_at:20181209013256p:plain

 巻き添えになったセルの数値は死亡します。なにこのトラップ。

並べかえができない

 せっかく人口で並べてるんだから、人口順にソートしたい時もあります。しかし結合セルがあると

f:id:hibit_at:20181204081347p:plain

 この操作を行うには、すべての結合セルを同じサイズにする必要がありますじゃあないんだよこの操作を行うには、すべての結合セルを同じサイズにする必要がありますじゃあ。 

そもそも列の途中に小計をはさむな

 っていうか、列の途中に小計挟む必要あります? 列全体を数えたらダブル計上、トリプル計上になりますよね。というか、同じ列の間に違うカテゴリレベルの値が入ってるって気持ち悪くないですか。東京都、神奈川県、沼津市ってなったら気持ちわるいでしょう。そもそも、SUMで一気に数えられないでしょ。

 え、個別にプラスしてるから大丈夫です?

f:id:hibit_at:20181209013502p:plain

 キモッ!

 悪いけどドン引きです。関数の保守性とか考えたことあります? 小カテゴリが4つに増えたらどうするんでするか? また数式をいじって個別にプラスするんですか? これが本当にすべてを合計してるか丁寧にひとつずつ確認するんですか? SUMだったら、あー全部のセル囲ってるねってすぐ確認できるのに、なんでそんな苦行をしなければならないのですか。あとこの方式だと、カテゴリが消えたら参照エラー起こりますけど、そういうのも考えてるんですか?

それでも小計や合計が知りたいという方

 ピボットテーブル使いましょう。冒頭で述べた青のCみたいな表があれば、一瞬で下の表みたいのが生成できるから。カテゴリを並べ替えたり、データをソートしたり、小計を間に挟んだり、そういうのもすぐできるから。ていうかそういうのをセル結合で再現しなくていいから。

f:id:hibit_at:20181209014255p:plain

 まあピボットテーブル使うにせよ関数で表現するにせよ、青のCから緑のBや赤のAみたいな表を作るのは容易ですが、その逆は手間がかかります。だからデータがどのような形になるかわからない場合や、後で変更が加えられるかもしれない時は、青のCのような形式で編集を行うのが大事なのです。

f:id:hibit_at:20181209020441p:plain

まったく意味のない結合もある

f:id:hibit_at:20181209014659p:plain

 こういう表は見てるだけでモニタを割りたくなりますね。

構造とデザインの分離

 少し話を広げます。今まで述べてきたような問題は、根本的には構造とデザインが分離されていないがゆえに起こる問題です。構造とデザインが分離されている状態というのは、例えば雑誌の編集においては、ライターが執筆原稿を送って、編集者がそれを雑誌に製本するような状態のことです。雑誌が印刷された後で、ちょっとあの部分の文章変えてよ、ということは基本的にはありえません。

 つまり、人の目に見やすいように整形された表というのは印刷された雑誌のようなもので、本来ならばそこから内容を修正するようなものではないのです。電子データだから無理矢理遡れるだけで、セル結合された表を変更するというのは、印刷された雑誌を切り抜いて文章を変更するようなものです。もし修正があれば、原稿の方を修正して、それから製本し直すというのがスジでしょう。出版なら大がかりな話になりますが、電子データ上なら一瞬で済みます。そのために関数やピボットテーブル機能があるのだから、そうするべきですExcelにおいては、原稿は整然データやCSVにあたります。それらを修正するにあたって、余計な手間は一切かかりません。

 なのに、Excelではデザインまで自分で完結させたい人や、デザインが固まった状態で修正を要求されるシーンがあまりにも多すぎます。人類にWYSIWYG(編集画面とレイアウトが一致していること)は早すぎたのだ……。

 ついでに言うと大半の人類はWordも雑に使いすぎですが、まあそれはまたの機会に。

ExcelがよりExcelらしくあるために

 Excel表計算ソフトです。けして版組ソフトではありません。セル結合やオブジェクト配置を使ってあなたの芸術を表現するキャンバスではありません。関数や、フィルターや、ピボットテーブルや、VBAを使って、99%の業務に必要なデータは一瞬で作成できます。そのために、その根本となるデータは整然データ(tidy data)でなければならないのです。

f:id:hibit_at:20181209015048p:plain

 だからみんな、データを作る時やそれを人に渡す時は、できるだけ青のCみたいな形で揃えてくれると嬉しいな……。それが私の最期の願い……。

お手軽にいい感じになれる(かもしれない)シェーダ「HibitShader」を公開しました

(12/15 追記)Qiitaソースコードの解説記事を投稿しました。1行ずつ全部解説していますので、興味ある方はぜひ。

 Unityのシェーダを自作しました。ここからDLできます。

先行研究と当シェーダの位置づけ

f:id:hibit_at:20181202034558p:plain

(比較表:すべて同じfbxとテクスチャを使用)

 VRCで良く使われているシェーダには、

 等がありますが、これらよりもっと手軽にセッティングできるシェーダをめざして作りました。

 使い方のイメージは下のようになります。

f:id:hibit_at:20181202034617p:plain

セールスポイント

 まず、パラメータが圧倒的に少ないです。2つしかありません。

  • Color

 全体的な色味をきめます。元のテクスチャだけだと冷たい感じがするな~という時はオレンジを足すと血色がよくなるみたいな使い方です。

  • RimColor

 リムライト(輪郭が光るやつ)のカラーを決めます。紫とか緑とかにするとアンニュイな感じになります。

(以下は補足的なパラメータ)

  • NormalMap

 ノーマルマップも一応適用できます。

  • Change

 これは当シェーダ独特の機能で、やや飛び道具的ではありますが、色相を変化させることができます。簡易的なコードで実装しているため、厳密な意味での色相ではないですが……。服の色や髪の色をピンポイントで変えたいという時に便利です。

めちゃくちゃ短い

 このシェーダはなんと49行で構成されています。フルスクラッチにも最適です。詳しいコードの解説等は近日中にQiitaで公開する予定ですので、興味がある方はお楽しみに。

(12/2 リムライトの明るさを環境光に対応させる変更を行ったため、1行増えました)

(12/8 コードの見直しを行った結果、1行減りました)

Substance Painter(2018)を使って淫紋を押しまくる方法


淫紋、押したいですよねっ?(小林製薬


 細かいツッコミはおいといて、Substance Painter(サブスタ)を用いて、3Dモデルの肌にスタンプみたいに淫紋(※R-18)を押す方法を解説していきます。

まずは素材

 まずは素材がないと始まりません。幸い、ふぃーるどさんがフリーの淫紋素材を公開してくださっているので、ありがたく使わせていただきます。個別ページでもお礼を申し上げましたが、この場でも改めてお礼申し上げます。

白黒反転

 サブスタに取り込む前に、画像の白黒を反転をする必要があります。なぜかと言うと、素材の状態だと「黒…紋様、白…背景」となっていますが、これだと透明部分が「黒」だと判断されてしまうからです。アルファチャンネルは「白→1」「黒→0」と判断するからですね。

f:id:hibit_at:20181027152655p:plain

 こうなれば良いです。私はgimpでやりましたが、別にフォトショでもクリスタでも、使い慣れたソフトで編集するのが良いかと思われます。念の為、gimpだと「色→階調の反転」Alt + C → V → Enterできます。

サブスタにとりこむ

 次はサブスタに画像をブラシとして取り込みます。

f:id:hibit_at:20181027153349p:plain

 サブスタを開いて、適当なfbxを読み込みます。人体にペタペタ貼っていくのは生々しくてアレなので、今回はパンダくんに犠牲になってもらいましょう。

f:id:hibit_at:20181027153458p:plain

 ここの「Import resources」を押して、

f:id:hibit_at:20181027153608p:plain

「Add resources」からさっき作った画像ファイルを読み込みます。

f:id:hibit_at:20181027154038p:plain

 ここの「undefined」を「alpha」に。

f:id:hibit_at:20181027154308p:plain

 ここの「Import your resources for」は何でも良いのですが、「project~」だとプロジェクト単位での保存、「shelf」だとプロジェクトを超えての保存になります。淫紋を末永く使いたい方はシェルフにブチ込んでおきましょう。

f:id:hibit_at:20181027154534p:plain

 これでアルファブラシに淫紋が追加されました! 

f:id:hibit_at:20181027154626p:plain

 初期設定だとBase Colorが白のままなので、これを黒にします。

f:id:hibit_at:20181027154815p:plain

 ここで注意なのですが、「ジッタ」はすべて0にします。ジッタ(Jitter)とは、手塗りのムラを表現するために出力にゆらぎをつける機能なのですが、淫紋を押す際には邪魔なので全て無効にする必要があります。また、角度を変えたい時はその上にある「角度」のバーを調節することによって変えることができます。ブラシのサイズはCtrl + ホイールで変更することができます。これで全ての準備は整いました。

f:id:hibit_at:20181027155118p:plain

 あとは本能の赴くままに淫紋をつけまくりましょう。

f:id:hibit_at:20181027155242p:plain

【注意】淫紋は、それ自体がR18という訳ではありませんが、肌を過剰に見せるアバターガイドラインに抵触するおそれがありますので、くれぐれもご注意を。

 皆様も、用法用量を守って良き淫紋ライフを。

FE(ファイアーエムブレム)に性差別はあるのか?~あるいは多変量解析と有意差検定~

 どうも、今回の記事はVRもCGもあまり関係ありません。敢えていえば数学です。

 皆様はFE(ファイアーエムブレム)という家庭用ゲームのシリーズをご存知でしょうか。任天堂が発売しているSRPGで、戦場でコマを動かして敵を倒して……というジャンルの草分け的存在でもあります。このシリーズ、ユニットがレベルアップする時に、そのパラメータが乱数によって上がるというユニークなシステムがありまして、その数に一喜一憂するのも大きな楽しみです。

 しかしこの成長率、どうも「美男美女>>>その他大勢」「美女・ロリ>>>醜男・老人」的なルッキズム/セクシズムに支配されていて、なんとなく現代のポリティカルコレクトネスに反しているように思えてなりません。そこで、本記事ではその点を統計解析によって厳密に検証していくのが目的になります。美醜/年齢は厳密なラベリングが難しいので、今回は性別に焦点を当てていきます。

 なお、余談になりますが、FC・SFC時代は「剣=正義=高性能=イケメン>>>斧=悪役=低性能=悪役顔」という斧差別が深刻であったのですが、トラキア776ではアファマティブアクションによる斧優遇が入りまして、今ではいいバランスに落ち着いています。やはり現実世界と同様、ゲームにも時代に合わせた倫理観のアップデートが必要ですね。後述しますが、トラキアは斧優遇以外でも、シリーズで独自の立ち位置を築いています。

成長率のリストアップ

 まず、全シリーズをまとめた成長率のリストを作成する必要があります。しかし、各シリーズによってパラメータの項目があったりなかったりするので、まずそれを整理する必要があります。整理したのが下の表です。

タイトル HP 魔力 武器 速さ 守備 魔防 体格 移動
暗黒竜と光の剣 - - -
外伝 - - -
紋章の謎 - - -
聖戦の系譜 - - -
トラキア776 - -
封印の剣 - - - -
烈火の剣 - - - -
聖魔の光石 - - - -
蒼炎の軌跡
暁の女神 - - -
新・暗黒竜と光の剣
新・紋章の謎 - - -
覚醒 - - -
if - - -
エコーズ - - - -

「△」は、成長率がほぼゼロであったり低いパラメータに設定されていたりするものです。つまり、上がるのが非常にレアなパラメータです。トラキアは「移動」と「体格」が上がる可能性があるというぶっ壊れ具合だったなあ……。

 もう一つ整理する必要がある点は、シリーズがリメイクを重ねているということです。「紋章の謎」は「暗黒竜と光の剣」のリメイクですし、更にそれをリメイクして「新・紋章の謎」が発売されています。こういったリメイクを全てカウントしていくと、同じキャラが複数出現してしまってデータが見づらくなります。なので、リメイクがされているものはそれを優先して、リメイク前のタイトルのデータは使わないという整理をします。それとは別に、異なるタイトルで同じユニットが出る(「新・紋章の謎」のカチュアと「エコーズ」のカチュア)ものや、同じ作品で年齢等が違う(「聖戦の系譜」の親世代のフィンと子世代のフィン)という例もありますが、それは異なるユニットとしてカウントします。

 以上のような要素を勘案した末に調整した表が以下になります。

タイトル HP 魔力 速さ 守備 魔防
聖戦の系譜
トラキア776 魔力
封印の剣
烈火の剣
聖魔の光石
暁の女神
新・紋章の謎
覚醒
if
エコーズ

「力」と「魔力」は、当該タイトルにそのパラメータがないので便宜的に他パラメータから流用したものです。タイトルによって「力=魔力」(つまり、武器と魔法を同時に使用するケースがない)ものと、「力と魔力は独立」(マスターナイトのように、武器と魔法とを両方使えるクラスが存在する)ものがあるので仕方ないです。トラキアは「魔防=魔力÷2」としているので、魔力を流用します。エコーズの魔防は成長率が低めに設定されているので10倍補正します。

 そのような調整を経た後の成長率リスト、いわば全シリーズ統一成長率表を作成したのですが、それを貼ると557行の膨大なデータになってしまうのでgithubにまとめております。ちなみに性別の欄は私が手作業で入力しました。疲れた……! どこかにミスがあるかもしれないので、プルリク等随時募集しております。

 なお、データの収集にあたっては主にかわき茶亭様のデータを使用させていただきました。この場を借りてお礼を申し上げます。

外れ値の除外

 なお、上のデータではカレル(封印の剣)とマリナス(封印の剣)(烈火の剣)を除外しています。カレルは成長率が一人だけダントツで高いためです。その成長率に意味があるならまだわかりますが、終盤で加入してレベルも上限に近い、いわゆる「お助けキャラ」(レベルアップしても意味ないので成長率は低いのが普通)なのに、なぜか異常なまでに成長率が高く設定されています。スタッフのお遊びでしょうか……。FEは時々スタッフの贔屓が目に見えるのが玉に瑕です。マリナスは非戦闘員の割りに成長率が高く、ノイズになりそうなので除外させてもらいました。

 また、外れ値という訳ではないのですが、聖戦の子世代の子供ユニットのほとんどは、成長率を一意に定めることが不可能なため除外しています。

主成分分析

 実際に統計的有意差の検討に入る前に、ユニットの成長率の分布を見た方が面白いので先にそちらの話をします。パラメータは、HPから魔防までの8種類がありますが、8個だと多すぎるので3個に集約しましょう。もし、8個のパラメータに何の偏りもなく散在しているならば集約は不可能ですが、現実のデータにはほぼ必ず何か偏りが存在します。例えば、魔力の成長率が高いユニットは魔防のそれも高い傾向にあります。そのような似た傾向を持つパラメータをセットにして少数の重要な変数に要約する方法を主成分分析(Principal Component Analysis)と言います。偏ったデータが真っ直ぐに見える「角度」を見つけ出す方法とも言えます。以下、556ユニットに対して主成分分析を行った結果です。

f:id:hibit_at:20181022033844p:plain

f:id:hibit_at:20181022034358p:plain

 PC1、PC2、PC3の3次元のデータをそのまま表すのは不可能なので、2つの2次元に分けています。赤い文字は女性ユニット、青い文字は男性ユニットを指します。

 PC1が低い側はファやミルラといった高成長率ユニット(マムクートがロリだから、ちくしょう!)、高い側がアランやバヌトゥといった成長をあきらめたユニット(ジェイガン系)(ジェイガンは集計の都合上いませんが……)であることから、PC1は「全体的な成長率の低さ」であることがわかります。

 PC2の高い側はトリスタンやヨハルヴァといった肉体派ユニット、低い側はサラやミカヤといった魔法系ユニットであることから、PC2は「肉体派傾向」であることがわかります。PC2の高い側に、アルテナ、リーフ、キュアンと並んでいるのが親子の絆を感じさせてよいですね。逆に、ロナンは弓使いなのになぜそんなに魔力の成長率が高いの?

 PC1とPC2のベクトルは以下のようになっています。

PC1 f:id:hibit_at:20181022040937p:plain

PC2 f:id:hibit_at:20181022040953p:plain

 おおむね所感と一致していますね。

 なお、3次元のグラフもrglライブラリを使って描画可能なのですが、文字ラベルを載せられませんし、グラフを動かせないとあまり意味がないのが辛いですね。やはり人類は一刻も早く2次元ディスプレイを脱出してVR空間で3次元情報を扱えるようになるべき……。一応下に3次元グラフ(の1投影)を載せておきます。私の技量をもってすれば4次元以上のグラフも、投影と回転を駆使して描画できないこともないですが、それをしたところでわかりやすくなる訳でもないので、しません。

f:id:hibit_at:20181022034314p:plain

線形判別分析

 男女によって成長率の傾向に違いがありそうということがわかりました。では、成長率から性別を予測できるのでしょうか。先程の主成分分析は、男女関係なく数値を解析した後で「色付け」をしてその分布を見ましたが、最初から「男女」の違いがわかった上で変数を組み立てれば、成長率から男女を予測するようなモデルを作れるのではないでしょうか。線形判別分析(Linear Discriminant Analysis)という手法でそれを実験してみましょう。すごく原始的ですが、これも一種の教師あり機械学習というやつです。

 判別分析では通常、学習データ(training data)とテストデータ(test data)を分けます。全てのデータを基に学習すると良い成績が出て当たり前なので、学習データと無関係なテストデータを正しく判別できてこそということです。そこでそのようにデータを分けるかという点が重要になるのですが、ここは「暁の女神」以前(FC~Wii)と「新・紋章の謎」以降(DS~)でちょうどハードも分かれてキリがいいので、そのようにしています。(なお、全てのデータを学習に使って、データ内で学習データとテストデータを交互に分け続ける交差検証(cross validation)という手法もあるのですが、今回は正攻法でいきます)

 以下が、暁以前の312ユニットを基に学習させたモデルから、新紋章以降の244ユニットを対象に判別分析を行った結果になります。

M F sum
M 137 9 146
F 68 30 98
sum 205 39 244

 …あんまり判別率がよくないですね。特に女性(F)は過誤(Mと判定)の方が多いです。成長率だけで男女を断定することは難しそうです。

有意差検定

 いよいよ核心に入っていきます。女性ユニットは男性ユニットに比べて有意に成長率が高いと言えるのでしょうか。まずは単純なランキングを並べてみます。

順位 名前 性別 合計
1 ファ F 690
2 ミルラ F 670
3 セティ M 475
4 セリス M 440
5 チャド M 415
6 サラ F 410
7 アルテナ F 404
8 エフラム M 400
9 ミカヤ F 400
10 ビーゼ F 400

 色々な作品からバランスよく選出されていますね(GBA世代のマムクートはダントツですが)。私はこの中だとビーゼさんが一番好きです。クールだけど無愛想じゃないところが好き。4章で加入してから頑張って育てると一気にエースになれるところも好き。解析する前は、作品によって成長率の「相場」が違ったらどうしようかと思っていましたが、そこまで違いはなさそうです。男女比も、トップ10を見るだけではなんとも言えませんが、そこまで偏りはなさそうです。

 では、統計検定に入る前に、まず分布が正規分布に従っているかを確認します。自然な分布は、平均を中心に釣鐘状の分布(正規分布)を示すもので、「統計的に差がある」という場合もこの分布を前提にしているものが多いです。この前提が崩れていると(フタコブラクダみたいな分布とか)例えば偏差値とかも信頼性がなくなってしまいます。え? 偏差値って頭の良さじゃないのって?

f:id:hibit_at:20181022194848j:plain

(「無頼男/梅澤春人」6巻より引用)

 失礼、取り乱しました。何はともあれヒストグラムを書いてみたらハッキリします。下図が成長率全体のヒストグラムです。

f:id:hibit_at:20181022195214p:plain

 ついでに、男女の違いを明示してみますか。

f:id:hibit_at:20181022200614p:plain

 男性の平均は281.3、女性の平均は304.2であり、平均は女性が優れていることはすぐにわかるのですが、問題はこれが統計的に有意な差といえるかどうかです。  この分布、見かけはなんとなく釣り鐘っぽいのですが、正規性を確認するShapiro-Wilk検定を行うと

        Shapiro-Wilk normality test

data:  x[, 12]
W = 0.9096, p-value < 2.2e-16

 となり、2.2*10^{-16}というすごい数値で棄却されます、残念。これではt検定が使えない……。しょうがないのでノンパラメトリックな手法であるU検定を試みることにします。

        Wilcoxon rank sum test with continuity correction

data:  xM[, 12] and xF[, 12]
W = 30221, p-value = 0.002382
alternative hypothesis: true location shift is not equal to 0

 なんと、帰無仮説(男女差はない)の採択率は0.002382\simeq0.2\%となり棄却されてしまいました。よって、対立仮説である「男女差はある」が採択され、ファイアーエムブレムにおいてはやはり女性ユニットが成長率において優れていることが統計的にも明らかになってしまいました。なんたるポリティカルコレクトネス違反。任天堂およびインテリジェントシステムズは、現代に相応しいゲームを開発するべくその倫理観をアップデートされたし。

まとめ

  • ファイアーエムブレムにおいて、成長率は「全体的な成長率の高低」「肉体派か魔法系か」によってある程度要約される
  • 成長率だけで男女を予測するのは困難
  • 女性ユニットの方が有意に成長率が高い傾向にある
  • ポリコレ云々はすべてジョークです
  • Swtichで発売する予定の据置新作楽しみにしています

 以上です。Further studyが望まれますが、それは筆者の統計能力の上達を待ってからになります。