hibitの技術系メモ

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

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

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

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が望まれますが、それは筆者の統計能力の上達を待ってからになります。

Blenderを一切触らずにボクセルアバターを作成する方法

 MagicaVoxelは簡単にボクセルデータを作れる素晴らしいソフトです。今まで3Dソフトを触ったことがない人でもマイクラ感覚で簡単にアバターを作れる……と言いたいところですが、アバターに持っていくためには

  • リギング
  • テクスチャ画像作成

 という2つの工程を経る必要があり、これにはBlender等の3DCGソフトを用いる必要があります。

 いや、Blenderは無料ソフトだし、サンフィッシュ熊野さんの素晴らしい解説記事があるので、これを見ながら操作すればええやんと言われたらそれまでなのですが、世の中には宗教上の理由でどうしてもBlenderを触れない人もいると思います。そのような方のために、Blenderを一切触らずにボクセルアバターを作成する方法を伝授します。

mixamoによるリギング

 mixamo、というAdobeが提供しているサービスがあります。これはなんと自動でリギングをしてくれるというとてもすごいサービスです。Adobeのユーザー登録が必要ですが、別に登録するだけで金を取られるようなものではないので、しましょう。以下、SSによる解説。

f:id:hibit_at:20181011204058p:plain

 まず、MagicaVoxelでメッシュを作成します。今回は説明のために緋色さんの素体を使わせていただきます。ありがとうございます。

f:id:hibit_at:20181011204401p:plain

 エクスポートする時に「obj」形式を選択します。

f:id:hibit_at:20181011210201p:plain

 熊野さん方式だとplyですが、ここではobjにします。そうじゃないとmixamoで読み込めないからです。出力先には、objファイルと、mtlファイルと、謎の虹色のpngファイルが出力されたと思います。このpngファイルは後で使います。

f:id:hibit_at:20181011204620p:plain

 次にmixamoを開いてこのobjデータを読み込ませます。私はすでに一通りテストした後なのでこの画面ですが、サインインしたばかりだと中央のウィンドウには誰もいないはずです。右上にあるオレンジ色の「DOWNLOAD」……ではなく、その下の「UPLOAD CHARACTER」のボタンを押します。

f:id:hibit_at:20181011204922p:plain

f:id:hibit_at:20181011205041p:plain

 先程エクスポートしたobjを読み込みます。ドラッグ&ドロップでもいけます。

f:id:hibit_at:20181011205357p:plain

 それぞれの色の輪っかをドラッグして対応する箇所にはりつけていきます。「NEXT」を押したらオートリギングが始まります。英語のメッセージで「2分ぐらいで終わります」とありますが、大体1分足らずでやってくれます。終わったらなんかメッセージウィンドウが出てきますが、何も考えずに「NEXT」を押し続けていきましょう。

f:id:hibit_at:20181011205615p:plain

 終わったらリギング済みのキャラクターが画面に出てきます。ここでやっと右上の「DOWNLOAD」を押します。ここで左側にあるアニメーションアイコンを押すとアバターが動き出してTポーズでなくなってしまうので注意です

f:id:hibit_at:20181011205819p:plain

 フォーマットはfbx、ポーズはTポーズでDOWNLOADしましょう。

Unityでの操作

 できあがったfbxをUnityに持ち込みます。……が、真っ白です! これは、fbxはテクスチャ画像を含まないという仕様によるものです。なので、別途テクスチャ画像を用意してあげる必要があります。実はそれが、最初にobjファイルをエクスポートした時に出した謎のpngファイルです。

f:id:hibit_at:20181011210538p:plain

 真っ白なfbxをクリックした時に出てくるマテリアルにpng画像をぶち込めば……

f:id:hibit_at:20181011210651p:plain

 このように無事最初の着色通りのアバターができました。カラーパレットからピンポイントで色を持ってくるような変態的なUVマップを持っているということでしょうね。

 ちなみに、もっとベタッとした発色にしたい~という方はUnlit Shaderにしてください。

f:id:hibit_at:20181011211022p:plain

 ここで変えられます。

humanoidを適用

 今だとまだアバターは直立不動のgenericアバターなので、humanoidを適用します

f:id:hibit_at:20181011211813p:plain

 右上の欄にある「Animations」を「Rig」にして、「Generic」を「Humanoid」にして、「Apply」を押します。これでhumanoidになりました。これでアバターに「VRC Descriptor」を適用すればもうアップロード可能に……!

(※VRC Descripotorの適用等についてはこのページの解説がとても詳しいです)

ボーンの罠

f:id:hibit_at:20181011212216p:plain

 Your rig has the UPPER CHEST mapped in the Humanoid Rig. This Will Cause Problems with IK.じゃあないんだよYour rig has the UPPER CHEST mapped in the Humanoid Rig. This Will Cause Problems with IK.じゃあ。

(和訳:あなたのリグには、ヒューマノイドリグにマップされたUPPER CHESTがあります。これはIK上の問題を引き起こす可能性があります。)

 はいはい、UPPER CHESTを外せばいいのね。Configureしていきましょう。

f:id:hibit_at:20181011212444p:plain

f:id:hibit_at:20181011212533p:plain

 ここを選択してDelキーを押せばここのリグを外すことができます。

 これでやっとアップロード可能に……!

f:id:hibit_at:20181011212703p:plain

 は~~~~~~~~?

 Spine Hierarchy incorrect. Make sure that the parent of both Shoulders and the Neck is the Chest.じゃあないんだよSpine Hierarchy incorrect. Make sure that the parent of both shoulders and the Neck is the Chest.じゃあ。

(和訳:Spineの階層が正しくありません。ShouldersとNeckの親がChestになっていることを確かめてください。)

 結論から言うと、もともとUpper ChestにあったボーンをChestにもってくる必要があります。何このトラップ。

f:id:hibit_at:20181011212954p:plain

 こうなればOKです。

 これでやっとアバターがアップロードできます。

 blenderを無視して、mixamoで横着したものには、最後には神罰が待っているのだ……!

アニメーションオーバーライドによって中腰になってしまったアバターを直す方法(Unity5.6.3用)

※Unityのアップデートに伴い、以下の「方法1」は使用できなくなりました。Unity2017用の方法は、こちらを参照願います。

 アニメーションオーバーライドを適用したアバターはなぜか以下のように中腰になってしまうことが知られています。

f:id:hibit_at:20180921214146p:plain

方法1(手軽なやつ)

 これを解決するためには、

 この方法が一番手っ取り早いです。

 先日この方法を動画にしたものをTwitterに投稿したので、それを見るのがわかりやすいです(手前味噌)。

 こんな感じで操作すれば一瞬で中腰を直すことができます。

 めでたしめでたし。

 ……。

 聞こえる……。

 聞こえるぞ……中腰に親を殺された者達の恨みの声が……!

方法2(中腰を憎む人用)

 実は上の方法で中腰を直しても再生中は中腰になってしまいます(再生が終われば直ります)。中腰にトラウマのある方にとっては、それを見るのもイヤだということがあるでしょう。今日はそんな中腰ヘイターのために、完膚なきまでに中腰を絶滅させる手段を伝授します。

 Unityのアセット欄をたどって、

Assets > VRCSDK > Examples > Sample Assets > Animation

 の中にある「tpose-new」の横にある小さな再生ボタンを押します。(押しづらいわ!)

f:id:hibit_at:20180921214316p:plain

 そうしたらその横に「tpose-new」というアニメーションファイルが出てくると思うので、それを選択した状態でアニメーションウィンドウを押すと、   f:id:hibit_at:20180921214535p:plain

 このように、夥しい数のアニメーションコンポーネントが出てきます。これを全部コピーして、元々あった(つまり中腰の原因になっていた)アニメーションにペーストします。

f:id:hibit_at:20180921214856p:plain

 解決!

 こうしてこの世から中腰が消え、VRCの世界の平和は保たれることとなった。

 TRUE END

※方法1でも特に不都合はないので、こだわりがなければ方法1をオススメします。