private-isuを手元(VM)で動かす用メモ
GitHub - catatsuy/private-isu: 社内ISUCON
これのMacやLinux上で適当に動かすをやってベンチマーカーを動かしたらpass:trueになる状態にするだけ
環境
| Host OS | Windows 10 Home 64bit | | Guest OS | Ubuntu Server 20.04 amd 64bit | | 仮想化ソフトウェア | Oracle VirtualBox 6.1 |
Hostで諸々インストール
ssh
記憶がないので不明...。でも標準でOpenSSHが入ってるらしい。
VirtualBox
公式のダウンロードページでVirtualBox 6.1.26 platform packagesのWindows hostsを押してダウンロード
Guest OSを動かす
Ubuntu イメージを持ってくる
Ubuntu 公式からUbuntu Server 20.04.3 LTSをダウンロード
VMの構成から起動後のUbuntu初期設定まで
この記事の手順通りにやる。OpenSSHは後でいれるので入れなくていい。
Guest OSに必要なソフトウェアをインストールする
面倒なので全部aptで入れます。あとvagrantとかでやろうとしたときの依存パッケージ回りが不明なので、明らかに不要なのも混ざってますが念のため入れときます。多分Ruby周りがAnsible入れた時に入ってる。
sudo apt upgrade sudo apt install -y build-essential openssh-server git net-tools nmap ansible virtualbox vagrant ruby-dev golang mysql-server mysql-client libmysqlclient-dev memcached libmemcached-tools libssl-dev
【Unity】Compute Shaderで画像処理をやってみる
この記事はMCC Advent Calender2018 5日目の記事です。今日なの忘れてて遅刻しました。
はじめに
Unityでは、Compute Shaderを用いることでGPUを用いた並列計算を行うことができます。主にGPUパーティクルを実装したいときに使う感じっぽいです。
今回は、このCompute Shaderの入門として軽い画像処理をしてみます。FFTとかを扱うとFFTの書き方の解説が面倒になるので、今回はエッジを抽出するフィルタの一つである、ラプラシアンフィルタを実装してみます。
表示用UIの準備
Compute Shaderとは関係なく、今回の実験のためにいくつか準備をします。
まず、画像処理の入力と出力を表示するためのUIを作成します。HierarchyビューのCreateからUI>Raw Imageを選択してRawImageを作成できます（下図）。これを二つ作り、それぞれSrc、Dstと名付けます。
Compute Shaderを用いるスクリプトの準備
Compute Shaderはスクリプトから呼び出して用います。というわけでスクリプトを作成しましょう。Projectビューで右クリックをし、Create>C#Scriptと選択して作成、ImageProcesserと名付けます。
そして、ImageProcesser.csを以下のように書きます。
Compute Shaderからの結果を受け取るためのにRenderTextureを作成(rTex)、設定します。このRenderTextureはARGBFloatにしておくと値が0から1の浮動小数点数になるため計算が楽です。 そして、ここで作成したRenderTextureを表示用UI(dstImg)に設定します。
RenderTextureについて：レンダーテクスチャ - Unity マニュアル Unity - スクリプティング API: RenderTexture
次に、SetTextureでShaderに入力用の画像、出力用の画像をShader側での変数名を指定してセットします。そして最後に、Dispatchで実行します。この辺の引数は後でまとめて説明します。
Compute Shaderを作成する
Compute Shaderのファイルは、Projectビューで右クリックをして、Create>Shader>Compute Shaderの順で選択すると作成できます。名前はLaplacianにします。
中身を編集して、次のように書きます。
一行目に#pragma kernel CSMainとありますが、これはCSMain関数がこのCompute Shaderのエントリーポイントの一つだよと指定するものです。ちなみにCSMainという名前になっていますが、ここは他の名前に変えても大丈夫です。
numthreadsでは、1つのグループで並列に実行するスレッドの数を3次元で指定できます。スレッド数の合計は、ここでは32321個となります。先ほどImageProcesser.csの方でDispatchをしたときに、w/32、h/32で指定した値は、このグループの数を指定しています。つまり、ここでは、全グループでのスレッドの合計が画像の画素数になります。
続いて、CSMainを見ていきます。カーネルに指定した関数は引数にスレッド番号を受け取ることができます。今回はDispatchThreadIDという、グループに関係なく全体での番号を受け取ります。これで各スレッドが画像の各画素の座標を受け取れます。このidはid.xyとすることでxy座標の座標を取得できます。
CSMainの処理の内容はラプラシアンフィルタです。up,down,left,right,middleはそれぞれラプラシアンフィルタ（下記）で0以外になる値を出しています。
up,down,left,right,middleを足した結果をsumに格納、dstTexの対応する画素に格納します。これでラプラシアンフィルタの実装完了です。これだけです。
おわりに
Compute Shaderでラプラシアンフィルタを実装しました。こんだけでできるので、みなさんいろいろ活用してみてください。あと遅れてしまってすみません。
【Xenoblade2】善行を積む
！注意！
ネタバレ記要素を含みます、注意してください。
善行で絶望する
トキハのキーキズナリング二つ目、「街の人に親切にして小さな善行を積もう」...。 ふんわりしすぎだしわかりづらすぎる。 そしてシナリオをクリア済みの人はググって絶望する。 クリア済みでアーケディアに行けなくなった今、楽にできる善行がないのでは、と...。
とまあそんな感じで僕も絶望してたのですが、割とあっさり達成した。 アーケディアに行けなくなった人達のための善行情報を記事にまとめておく。
以下に善行対象とその位置をマップのスクショで示していきます。マップのプレイヤーがいる位置が善行対象がいるところです。
善行箇所その1
場所: グーラ トリゴ基地の奥、難民
やること: クッキーを買う
アーケディアでクッキーを売っていた子が難民としてグーラのトリゴ基地に来ているっぽい。
善行箇所その2
場所: インヴィディア フォンス・マイム商業区 左奥
やること: サンゴ製ノポンチェスを渡す
サンゴ製ノポンチェスはアヴァリティア商会 中央交易所のホビー・トイノポックスで購入できます。
善行箇所その3
場所: スペルビア アダマー格納区 建物の屋上
やること: ゴールドシリンダを渡す
シナリオクリア済みの人であればゴールドシリンダはまあその辺で買えば手に入るでしょう。
おわりに
この記事はネタバレ記事という悪行なのか、攻略記事という善行なのか...。
簡単な触知覚インターフェースの開発
この記事はMCC Advent Calender 2016 12日目の記事です。
はじめに
なんか色々*1あり、触知覚インターフェースを作成しています。現状できているものについて軽く話をしようかなと思います。
作るもの
どういった触知覚インターフェースを作っているかといいますと、バーチャル空間上に存在する物体に手が触れると実際の手に振動が生じるというものです。
作ったもの
実際に手を動かすとそれに連動してバーチャル手が動きます。また、バーチャルな手はバーチャル空間上の物体の影響をうけます。バーチャルな手が物体にぶつかっている間は、写真のようなデバイスにくっついている振動モータが振動します。また、実際の手がバーチャルな物体に侵入している量に比例して振動が強くなります。
手に装着するのがこれで、
— y@冬コミ3日目東R-13a (@ykun03) 2016年12月8日
画面に映ってるバーチャル空間の様子がこれです。緑色の立方体が実際の手の動きで、赤色の立方体がバーチャルな手の動きです。
バーチャルカップリング
という手法を使っています。これは触知覚インターフェースであるデバイスとシミュレーションとを接続するための手法です。実際には、バーチャルな手と実際の手を、バーチャルなバネ-ダンパで接続し、位置情報の差を用いて計算した提示力をデバイスとシミュレータの両方に出力するということをやっています。その提示力を用いて振動の強さの制御とバーチャル手の移動を行っています。まあこれについては「安定性と忠実性を両立させる高解像度レンダリングの開発」という論文*2の図3がわかりやすいです。
実装
実装には次のものを使用しています。
あとはUSB延長ケーブルだったりブレッドボードだったりを使っています。UnityでKinectを動かすのにはこれを使用しました。ソースコードとかは色々整えたらGitHubに上げてここにリンク貼ります。しばしお待ちを...。
結果と考察
ここを書いちゃうと後に控えている発表とかで厳しくなる可能性があるので、今は省略して来学期になったら公開しようと思います。ご了承ください...。*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等で管理し、複数人で開発しやすいようにしなかった
僕自身の作るべきものを明確にしなかったため設計もなくできていくものがめちゃくちゃになった
チーム結成段階でマネジメントが必要になる状況に気づけなかった。
というのを感じました。既にモノはある程度形になってしまっているので、もしこれを続けて開発する機会があれば、
というふうに改善したいです。でも貸していただいた機材はもう返却し、その分いろいろやらなきゃいけないのでまたお借りするのは(今更どの口が言うのかという感じですが)迷惑がかかりそうだなと思うので悩んでます。どなたかViveとめっちゃ性能のいいPCと場所を貸してください...お願いします...。あとさらに作ったものを展示できる場所がほしいですね...。IVRCの予選で展示してアドバイスをもらってもそれでおしまいというのはあまりにもつらい...。
アイデア
僕たちのチームの作品は、僕が少なくとも月に一回くらいは思う「力がほしい」というのをmake_now_just氏に言ったら「怪獣になる」というのが出てそれになりました。その後メンバーを集めてどういうのをどうやって作るかを話し合って企画書を書き上げ、書類が通過することを確認するまではスケジュール等の必要な情報の把握を行ってました。そして、書類が通過してみんなでなぜだ...となりながら制作を開始しました。「なぜだ...」ってなんだよという話です。
企画書を書いていた時は、ビルを破壊するというのをジェンガを使って実装するという話で進めていました。しかし、よりリアルな体験を目指すのか、それともコンテンツとして、爽快感を求める方向に走っていくのかなどは決まっていませんでした。いや、正確には、決めてはいたけどみんなあまり納得がいってないという状況でした。根幹の部分がもやもやしている状態で突き進んだのは、制作が進行しづらいという点でかなり問題だったかなと思います。
大会
日記
13日
展示のための設営を午後の間行いました。また、必要だと思った機能の追加や動作確認を行ったため2時間弱くらいしか眠れませんでした。
14日
午前中設営をするも、ハードウェア側の動作が上手くいかず、なかなかうまく体験ができない状態になり、みんな精神がやられていきました。なんとか動くようにしたもののなかなか体験者は来ず...。しかしその後体験、アドバイスをしていただき、精神とやる気が回復していきました。アドバイスを元に最も重要な部分を見せるための工夫を実装するためにまた開発とデバッグを夜中に行いました。
15日
午前中の予選通過が決まる前の最後の展示では、改善によりスムーズに体験が可能になりました。おかげでより多くん感想やアドバイスを聞くことができました。頑張った甲斐がありました。午後はVRSJ20周年記念式典で樋口真嗣さんの講演を聞いたりしました(落合さん達のトークセッションもありましたが、身体が限界だったためかいつの間にか気を失っていました...とても聞きたかったです...)。機材を持ち帰ることができなかったことと僕の体力が限界になっていたため、ホテルに戻ってからは何もしませんでした。
16日
最終日だったので各々交代して他の展示を見たりしました。僕は疲れを認識できる程度までしか回復できていなかったため発表を聞きに行ったものの全く内容が頭に入って来ず、会場の人のいないところで爆睡していました。起きようとしたらかなしばりにあったみたいに全く動けなくなったりしたのでこれはこれで面白い体験ができました。午後は頑張って展示をし、展示時間終了後は機材を返却しに行くために即撤収しました。
知見とか考えたこととか
(自分の思ったことについてはなんの根拠もなく推測で述べている感じになっていますし雑ですが、書かずにはいられなかったので許してください)
「現実なのにリアリティがない」
樋口真嗣さんのお話しで出てきたことです。
樋口さんは、「現実で起こることは現実だと思っているものを超えてくる」というようなことをおっしゃっていました。例としては、大嵐で屋根が紙のようにクシャクシャっと潰れていったりすることです。現実で起こることは、人間の思っていたものを超えた振る舞いを見せることがあり、それを見たときにリアリティを感じない。また、そのように超えてくることが現実で起こっているということを受け入れていくことでリアリティは更新されていくという話でした。
このリアリティは更新されていくという話から、僕は人間の感じるリアリティは経験によるものがかなり大きいのでは？もしそうであれば、リアリティを更新することは可能で、リアリティを作っていくことさえできるのではないかと思いました。いや、既にリアリティを作るというのは行なわれているように思えます。例えば、今回僕たちが体験で実現しようとした、「怪獣になってビルを壊す」ということのリアリティへの認識です。そもそも、怪獣がビルを壊すなんてことは現実には起こりえません。それでも、なんとなく、それについてのリアリティを感じることができる人はいます。この原因は、そういうことを表現した作品を見ているからではないかと思います。また、そうであればこれは作品によって怪獣によるビルの破壊という事象へのリアルがその人に植え付けられたということになるのではないでしょうか。
現実っぽく見せるには
樋口さんが監督をした「シン・ゴジラ」は、「現実(ニッポン) 対 虚構(ゴジラ)」というキャッチフレーズがあります。このキャッチフレーズの通り、「シン・ゴジラ」のゴジラという虚構以外のリアリティの追求っぷりは半端ではないです。例についてははネタバレ要素やオフレコ要素を含むので例については書けませんが、本当に徹底されています。降ってきた要望を現実っぽさを残しつつ答えるための演出や、ほとんどの人は見たことがないがそれっぽく見えるなど、本当にすごい作られ方をしています。また、「」ほとんどの人は見たことがないがそれっぽく見えるとありますが、これはゴジラについても同じことです。ゴジラを実際に見たことがある人はこの世には存在しないでしょう。しかし、それでもあの映画でのゴジラのリアリティはすごいものです。
このリアリティはどこから来るのだろう？と考えて、私は上記の経験からくるリアリティの他に、周囲のリアリティというのもあるのではないかと考えました。4869の日報に講演のあとに僕が彼から聞いたハリー・ポッターについての話が載っているのですが、このハリー・ポッターのリアリティというものも、魔法以外のリアリティの高さからくるものなのではないでしょうか?「シン・ゴジラ」についてもゴジラ以外のリアリティの徹底されていますし、そういうものはあるように思います。
おわりに
疲れたので一旦これで終わりにします。得た知見についてはもっとあるので追記します。
Skyboxの色をスクリプトから変えたときの出来事
Unity Editorにて「バグのようなそうではないような...なんというか...」って感じの挙動を見つけたのでとりあえず書きます。
やってしまったこと
2つのSkyboxのマテリアルを用意してそれをスーッと切り替える、つまりSkyboxのクロスフェードをしたかったわけです。 そして「ColorならLerpあるけど、さすがにMaterialにはないよな～」なんて思ってたら、ありました。
「Shaderもあればテクスチャもあるのにマジか...Unityってすごい...」と思い使ってみることに。こんな感じにスクリプト(色々省略してます)を書きました。
RenderSettings.skybox.Lerp(a, b, t);
いざ再生！！ ...色が変わっただけでした。まあ...そうですよね...現実は甘くない。ちなみにこれtsubaki_t1さんが3年前に見つけてました。
で、がっかりするだけでは終わりませんでした。
起きたこと
停止すると、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個重ねただけでもだいぶ迫力があるとかやはり視覚だけでも物が倒れてくると怖いとか，自分が手で物を動かしたというよりは何か超能力的な何かをしているような感覚があったとかいろいろ発見がありました．楽しいのでもっといじってみようと思います．
