眠くなっちゃった

気持ちで書きます

【Xenoblade2】善行を積む

!注意!

ネタバレ記要素を含みます、注意してください。

善行で絶望する

トキハのキーキズナリング二つ目、「街の人に親切にして小さな善行を積もう」...。 ふんわりしすぎだしわかりづらすぎる。 そしてシナリオをクリア済みの人はググって絶望する。 クリア済みでアーケディアに行けなくなった今、楽にできる善行がないのでは、と...。

とまあそんな感じで僕も絶望してたのですが、割とあっさり達成した。 アーケディアに行けなくなった人達のための善行情報を記事にまとめておく。

以下に善行対象とその位置をマップのスクショで示していきます。マップのプレイヤーがいる位置が善行対象がいるところです。

善行箇所その1

場所: グーラ トリゴ基地の奥、難民

やること: クッキーを買う

アーケディアでクッキーを売っていた子が難民としてグーラのトリゴ基地に来ているっぽい。

f:id:ykun33:20171225201823j:plain f:id:ykun33:20171225201850j:plain

善行箇所その2

場所: インヴィディア フォンス・マイム商業区 左奥

やること: サンゴ製ノポンチェスを渡す

サンゴ製ノポンチェスはアヴァリティア商会 中央交易所のホビー・トイノポックスで購入できます。

f:id:ykun33:20171225202917j:plain f:id:ykun33:20171225202451j:plain

善行箇所その3

場所: スペルビア アダマー格納区 建物の屋上

やること: ゴールドシリンダを渡す

シナリオクリア済みの人であればゴールドシリンダはまあその辺で買えば手に入るでしょう。

f:id:ykun33:20171225202925j:plain f:id:ykun33:20171225202930j:plain

おわりに

この記事はネタバレ記事という悪行なのか、攻略記事という善行なのか...。

簡単な触知覚インターフェースの開発

この記事はMCC Advent Calender 2016 12日目の記事です。

はじめに

なんか色々*1あり、触知覚インターフェースを作成しています。現状できているものについて軽く話をしようかなと思います。

作るもの

どういった触知覚インターフェースを作っているかといいますと、バーチャル空間上に存在する物体に手が触れると実際の手に振動が生じるというものです。

作ったもの

実際に手を動かすとそれに連動してバーチャル手が動きます。また、バーチャルな手はバーチャル空間上の物体の影響をうけます。バーチャルな手が物体にぶつかっている間は、写真のようなデバイスにくっついている振動モータが振動します。また、実際の手がバーチャルな物体に侵入している量に比例して振動が強くなります。

手に装着するのがこれで、

画面に映ってるバーチャル空間の様子がこれです。緑色の立方体が実際の手の動きで、赤色の立方体がバーチャルな手の動きです。

youtu.be

バーチャルカップリング

という手法を使っています。これは触知覚インターフェースであるデバイスとシミュレーションとを接続するための手法です。実際には、バーチャルな手と実際の手を、バーチャルなバネ-ダンパで接続し、位置情報の差を用いて計算した提示力をデバイスとシミュレータの両方に出力するということをやっています。その提示力を用いて振動の強さの制御とバーチャル手の移動を行っています。まあこれについては「安定性と忠実性を両立させる高解像度レンダリングの開発」という論文*2の図3がわかりやすいです。

実装

実装には次のものを使用しています。

あとはUSB延長ケーブルだったりブレッドボードだったりを使っています。UnityでKinectを動かすのにはこれを使用しました。ソースコードとかは色々整えたらGitHubに上げてここにリンク貼ります。しばしお待ちを...。

結果と考察

ここを書いちゃうと後に控えている発表とかで厳しくなる可能性があるので、今は省略して来学期になったら公開しようと思います。ご了承ください...。*3

おわりに

なんにもない記事になってしまい厳しい。許してください。

こういう実験を(信用できる)観測データで評価する方法を僕は知らないので、どうしても感想とそれに対する予測とかでやっていくしかないというのはやはりつらいものがあります。もっと色々知る必要がある気がしますが、それよりも実験を数こなした方がいい気もするので、さてどうしたものか...。

*1:東京農工大学工学部情報工学科にはSAILプログラムというカリキュラムがあり、それでやっています(雑)。

*2:ググると出てきます。リンクを押すとダウンロードされるのがなんか嫌なのでリンクは貼りません。

*3:これによりこの記事はただのやってみた案件に成り下がった。つらい。

IVRC2016予選大会に出場しました(再up)

はじめに

9/13-16, つくば国際会議場にて行われた日本バーチャルリアリティ学会大会の一部として開催されたIVRCの予選大会で"I am a monster"という作品の展示を行ってきました。今回のことについてあったことや考えたこと、思い知ったこと、反省などをまとめるために書いておこうと思います。

 

制作のための環境確保

発生した問題

僕らのチームは、全員通っている大学が違う^1という特徴があります。しかし、この状況でアイデアを実現させるためには、

  • 集まって作業をする場所がない

  * 集まっての話し合いの機会が少なくなる

  • 必要な機材(PCなど)がない

という問題を解決する必要がありました。

 

解決

高校の先輩経由で知り合ったViling Venture Partners のCEO、栗島さんにViling Venture Partnersの場所をお借りして企画書・制作のための話し合いなどをしました。また、さらに栗島さん経由で知り合ったアブログ合同会社代表の内田さん経由で知り合ったGIFTED AGENT代表の河崎さんにHTC VIve、PC、場所をお借りして制作を行いました。

 

この辺りは運が良かったのとなかなか図々しくやっていった結果上手くいった気がします。図々しくするのは結構精神にくるので、送信するメッセージを考えたあとはしばらく本当に送っていいのか...と悩んだりしましたがそこを乗り越えてやっていきました。

 

制作

マネジメント

チーム全体の進捗が...とならないように、タスクの振り分け、明確化などを行いました。全員のスケジュールを確認してタスクを振れそうな人にタスクを期限つきで振り、間に合わなかった場合にどういうタスクを誰にやらせるかまで決めておくなどしました。幸い皆ある程度期限を守ってくれたのでそこは問題になりませんでした。

 

一番問題だったのは僕自身の進捗でした。僕はチームにおいて上記のようなマネジメント、IVRC運営や場所/機材を貸していただいた会社との諸連絡、必要となる事務的な作業だけでなく、Unityでメインとなる開発も請け負っていました。開発以外のところに追われたために進捗が悪く、開発期間の終盤になってようやく形になった、という感じでした。これについての反省点として、

 

  • Unityを用いた開発をgit等で管理し、複数人で開発しやすいようにしなかった

  • 僕自身の作るべきものを明確にしなかったため設計もなくできていくものがめちゃくちゃになった

  • チーム結成段階でマネジメントが必要になる状況に気づけなかった。

 

というのを感じました。既にモノはある程度形になってしまっているので、もしこれを続けて開発する機会があれば、

 

  • 現状のものと改善すべき点を踏まえた再設計とリファクタリング

  • gitなどのバージョン管理ツールの導入

  • マネジメントと開発を行う人を分ける

  • 作るものを明確に文書化して開発と進捗管理を行いやすくする

 

というふうに改善したいです。でも貸していただいた機材はもう返却し、その分いろいろやらなきゃいけないのでまたお借りするのは(今更どの口が言うのかという感じですが)迷惑がかかりそうだなと思うので悩んでます。どなたかViveとめっちゃ性能のいいPCと場所を貸してください...お願いします...。あとさらに作ったものを展示できる場所がほしいですね...。IVRCの予選で展示してアドバイスをもらってもそれでおしまいというのはあまりにもつらい...。

 

イデア

僕たちのチームの作品は、僕が少なくとも月に一回くらいは思う「力がほしい」というのをmake_now_just氏に言ったら「怪獣になる」というのが出てそれになりました。その後メンバーを集めてどういうのをどうやって作るかを話し合って企画書を書き上げ、書類が通過することを確認するまではスケジュール等の必要な情報の把握を行ってました。そして、書類が通過してみんなでなぜだ...となりながら制作を開始しました。「なぜだ...」ってなんだよという話です。

 

企画書を書いていた時は、ビルを破壊するというのをジェンガを使って実装するという話で進めていました。しかし、よりリアルな体験を目指すのか、それともコンテンツとして、爽快感を求める方向に走っていくのかなどは決まっていませんでした。いや、正確には、決めてはいたけどみんなあまり納得がいってないという状況でした。根幹の部分がもやもやしている状態で突き進んだのは、制作が進行しづらいという点でかなり問題だったかなと思います。

 

大会

日記

13日

展示のための設営を午後の間行いました。また、必要だと思った機能の追加や動作確認を行ったため2時間弱くらいしか眠れませんでした。

14日

午前中設営をするも、ハードウェア側の動作が上手くいかず、なかなかうまく体験ができない状態になり、みんな精神がやられていきました。なんとか動くようにしたもののなかなか体験者は来ず...。しかしその後体験、アドバイスをしていただき、精神とやる気が回復していきました。アドバイスを元に最も重要な部分を見せるための工夫を実装するためにまた開発とデバッグを夜中に行いました。

15日

午前中の予選通過が決まる前の最後の展示では、改善によりスムーズに体験が可能になりました。おかげでより多くん感想やアドバイスを聞くことができました。頑張った甲斐がありました。午後はVRSJ20周年記念式典で樋口真嗣さんの講演を聞いたりしました(落合さん達のトークセッションもありましたが、身体が限界だったためかいつの間にか気を失っていました...とても聞きたかったです...)。機材を持ち帰ることができなかったことと僕の体力が限界になっていたため、ホテルに戻ってからは何もしませんでした。

16日

最終日だったので各々交代して他の展示を見たりしました。僕は疲れを認識できる程度までしか回復できていなかったため発表を聞きに行ったものの全く内容が頭に入って来ず、会場の人のいないところで爆睡していました。起きようとしたらかなしばりにあったみたいに全く動けなくなったりしたのでこれはこれで面白い体験ができました。午後は頑張って展示をし、展示時間終了後は機材を返却しに行くために即撤収しました。

 

知見とか考えたこととか

(自分の思ったことについてはなんの根拠もなく推測で述べている感じになっていますし雑ですが、書かずにはいられなかったので許してください)

「現実なのにリアリティがない」

樋口真嗣さんのお話しで出てきたことです。

 

樋口さんは、「現実で起こることは現実だと思っているものを超えてくる」というようなことをおっしゃっていました。例としては、大嵐で屋根が紙のようにクシャクシャっと潰れていったりすることです。現実で起こることは、人間の思っていたものを超えた振る舞いを見せることがあり、それを見たときにリアリティを感じない。また、そのように超えてくることが現実で起こっているということを受け入れていくことでリアリティは更新されていくという話でした。

 

このリアリティは更新されていくという話から、僕は人間の感じるリアリティは経験によるものがかなり大きいのでは?もしそうであれば、リアリティを更新することは可能で、リアリティを作っていくことさえできるのではないかと思いました。いや、既にリアリティを作るというのは行なわれているように思えます。例えば、今回僕たちが体験で実現しようとした、「怪獣になってビルを壊す」ということのリアリティへの認識です。そもそも、怪獣がビルを壊すなんてことは現実には起こりえません。それでも、なんとなく、それについてのリアリティを感じることができる人はいます。この原因は、そういうことを表現した作品を見ているからではないかと思います。また、そうであればこれは作品によって怪獣によるビルの破壊という事象へのリアルがその人に植え付けられたということになるのではないでしょうか。

 

現実っぽく見せるには

樋口さんが監督をした「シン・ゴジラ」は、「現実(ニッポン) 対 虚構(ゴジラ)」というキャッチフレーズがあります。このキャッチフレーズの通り、「シン・ゴジラ」のゴジラという虚構以外のリアリティの追求っぷりは半端ではないです。例についてははネタバレ要素やオフレコ要素を含むので例については書けませんが、本当に徹底されています。降ってきた要望を現実っぽさを残しつつ答えるための演出や、ほとんどの人は見たことがないがそれっぽく見えるなど、本当にすごい作られ方をしています。また、「」ほとんどの人は見たことがないがそれっぽく見えるとありますが、これはゴジラについても同じことです。ゴジラを実際に見たことがある人はこの世には存在しないでしょう。しかし、それでもあの映画でのゴジラのリアリティはすごいものです。

 

このリアリティはどこから来るのだろう?と考えて、私は上記の経験からくるリアリティの他に、周囲のリアリティというのもあるのではないかと考えました。4869の日報に講演のあとに僕が彼から聞いたハリー・ポッターについての話が載っているのですが、このハリー・ポッターのリアリティというものも、魔法以外のリアリティの高さからくるものなのではないでしょうか?「シン・ゴジラ」についてもゴジラ以外のリアリティの徹底されていますし、そういうものはあるように思います。

 

おわりに

疲れたので一旦これで終わりにします。得た知見についてはもっとあるので追記します。

Skyboxの色をスクリプトから変えたときの出来事

Unity Editorにて「バグのようなそうではないような...なんというか...」って感じの挙動を見つけたのでとりあえず書きます。

やってしまったこと

2つのSkyboxのマテリアルを用意してそれをスーッと切り替える、つまりSkyboxのクロスフェードをしたかったわけです。 そして「ColorならLerpあるけど、さすがにMaterialにはないよな~」なんて思ってたら、ありました。

docs.unity3d.com

「Shaderもあればテクスチャもあるのにマジか...Unityってすごい...」と思い使ってみることに。こんな感じにスクリプト(色々省略してます)を書きました。

RenderSettings.skybox.Lerp(a, b, t);

いざ再生!! ...色が変わっただけでした。まあ...そうですよね...現実は甘くない。ちなみにこれtsubaki_t1さんが3年前に見つけてました。

tsubakit1.hateblo.jp

で、がっかりするだけでは終わりませんでした。

起きたこと

停止すると、Skyboxが元に戻りませんでした。え?と思ってSkyboxに適用したMaterialを見てみると、Tint Colorの値が変わってました。ちなみに僕は上のスクリプトのbのMaterialのカラーをRGBAで(0,0,0,0)にしてたので空が真っ暗になりました。恐ろしかったです。何が怖いって、場合によっては元の色の設定値がわからないと戻せないことです。しかも、SkyboxにはDefault-Skybox(Unityのビルトインのやつ)だったのでDefault-Skyboxが真っ黒になり、Projectビューから選択して編集もできないのでインストールしなおしか...ってなりました。

解決?

そのときは、なんとなく新しいマテリアルを作成したらDefault-Skyboxが元に戻りました。Materialを新規作成した際に再読み込みが走って元のデータをUnity Editor上で反映させたのかな、と思い、別のマテリアルを用意して実験。作ったマテリアルをSkyboxに設定し、上のスクリプトを実行して色が変わるのを確認して、新しくマテリアルを作成、と同じようにやってみても元に戻りました。

あと、"RenderSettings.skybox.SetColor("_Tint", color);"として色を変えた場合も同様にマテリアルの色が完全に変わってしまいました。こちらの怖いところは、マテリアルを新しく作っても元に戻らないことです。

しかしこれだといちいち再読み込みさせないといけないってことだからめんどくさい...。そこでスクリプトに以下のようなものを追加。

void OnApplicationQuit() {
    RenderSettings.skybox.SetColor("_Tint", firstSkyboxColor);
}

firstSkyboxColorはpublicなメンバ変数で、あらかじめ最初に設定したSkyboxのマテリアルのTint Colorの値を手動コピーしておく感じです。雑すぎるしあまり解決にはなってない気がする...。

考察

Material.Lerpの使用時の挙動を見ると、RenderSettings.skyboxはUnity Editor上で元データからコピーしたものを扱っているように見えます。それに対して、Material.SetColorの使用時の挙動を見ると、元データを書き換えているように見えます。まあどちらも静的メソッドではなく、インスタンスのメソッドだからそういう挙動をするのは当たり前のような気がします。というか、参照っていうだけのことでは...。参照だから、参照先を変えるだけみたいな下のコードは問題ないっぽいですし...。

RenderSettings.skybox = mySkybox;
DynamicGI.UpdateEnvironment();

結論

詳しくはわかっていないので迂闊に使わない方がいい気がする(まあ僕は必要に迫られているのでSetColor使ってごり押ししますが)。Skyboxのマテリアルの色を元のデータを変えずに変えるいい方法ないですかね...。

HTC Viveを使ってCubeに触る

はじめに

最近話題(?)のViveを触らせていただける機会があったので簡単なものを作って遊びました.Unityを使用してCubeに触るまでの過程をとりあえずメモしておきます.あとで図を入れたりして編集するかもしれません.

Viveのセットアップ

まず箱に入っている説明書のとおりに http://www.htcvive.com/us/setup/ を開いて"Download Vive Setup"というボタンを押してインストーラをダウンロードします.あとはインストーラの指示に従ってセットアップを行います.セットアップが一通り終わるとチュートリアルが始まります.ここで様々なエラーが出る場合があるようですが,私がやったときは何もなかったので省きます(本当は2台のPCでやって片方だけHMDを認識しない問題が出ましたが...).

UnityでViveを使う

インストールが長いのとチュートリアルが楽しいのでここにくるまで結構時間がかかったのではないでしょうか(僕だけですかね...)?次はUnityでViveを使えるようにしてからサンプルで遊んでみます.

まずはUnityを開いて新しいプロジェクトを3Dを選択して作ります.開いたらメニューバーのWindow -> Asset Storeと選択し,Asset Storeを開きます.Asset Storeで"Steam VR Plugin"と検索して無料の"Steam VR Plugin"というアセットをダウンロード,インポートします.インポート終了後,開発環境に応じて設定を変えたりするような画面が出ると思います.問題なければ"Accept All"を押しましょう.次にSteamVR/Scenes/にあるexampleシーンを開きます.Viveを装着して実行してみます.これでちゃんと動いていれば,UnityでViveを使う準備は整っています.

Cubeに触れるようにする

せっかくなので自分で新しくシーンを作ってそこでものに触れるようにします.まずは適当な名前で新しくシーンを作りましょう.タイトルにはCubeと書きましたがなんでもいいので,触りたいものに適当なColliderとRigidbodyをつけます.use gravityをオンにしておく場合は触りたいものが無限に落ちていかないようにPlaneなどを下に置いておきましょう.

ここまではViveと関係ないのです.Viveを使えるようにしましょう.ProjectビューのSteamVR/Prefabs/から[CameraRig]をSceneに配置します.[CameraRig]にはSteamVR_PlayAreaというコンポーネントがついており,これのPlayAreaを変えることで部屋のサイズをViveの設定と合わせます.部屋のサイズはSceneビュー上で表示されているため,オブジェクトを配置するときに便利です.[CameraRig]には3つの子オブジェクトがついており,その子オブジェクトの名前通り,それぞれ左のコントローラ,右のコントローラ,HMDを表しています.コントローラが触りたいものに当たるように当たり判定を付けていきます.コントローラのオブジェクトまたはコントローラの子オブジェクトにColliderとRigidbodyをつけます.Colliderについてはコントローラが小さいので半径0.1のSpehreColliderを付け,RigidbodyについてはUse Gravityをオフに,IsKinematicをオンにします.これで後はオブジェクトの位置を自分が移動できる範囲内に持ってきて準備完了です.実行するとViveのコントローラでオブジェクトを触れる(というよりは弾く)ようになったと思います.

おわりに

とりあえず画面上のオブジェクトに作用できるものができました.室内であまり動き回ると危ない環境で作ったので本当はオブジェクトの位置をリセットしたりするスクリプトを書きましたが,これくらいのものは1行も書くことなく作れます.もちろん「こんな挙動じゃ納得いかない!」となると思うのでそういう場合は色々調節したりすると良いと思います(雑).Unityのpositionは単位が1[m]なのでただCubeを2個重ねただけでもだいぶ迫力があるとかやはり視覚だけでも物が倒れてくると怖いとか,自分が手で物を動かしたというよりは何か超能力的な何かをしているような感覚があったとかいろいろ発見がありました.楽しいのでもっといじってみようと思います.