バスキュール技術ブログ

宇宙に浮かぶひまわりの目からいろんな地球を見る

2024-05-09T14:17:08+09:00

こんにちは！エンジニアの勝田（https://twitter.com/nichol76_yk）です！

前回、武田がこんな記事↓を書いてました。 blog.bascule.co.jp

私たちが4月22日に配信した『KIBO宇宙放送局 #アースデイライブ 2024 〜丸い地球をほぼ生中継。〜 - YouTube』という番組があるのですが、前回は企画・開発の裏側にフォーカスした記事でした。

システムの詳細は武田の記事を参考にしていただくとして、ざっと番組内容を説明すると、

気象衛星ひまわりの画像を取得して
アップスケールしたり
フレーム補完をしたりして
ほぼリアルタイム生成された
はちゃめちゃにきれいな地球映像を超高解像度のLEDに映してみんなで見よう！

という感じです。

じゃあ実際どういう映像なの？というのを、番組では紹介できなかったものも含めてこの記事でお見せしたいと思います！

実際には22Kの動画を超でかい高解像度LEDに映すのでどうしても生でないと迫力は伝わらないのですが・・
ぜひぜひYoutubeの4K再生で見てみてください！！　　　　　　

春夏秋冬

youtu.be

左から春・夏・秋・冬の24時間を比較した映像です。
いかがでしょうか？
同じ一日なのに3か月違うだけでこんなにも日の当たり方が違うのだと驚きます。

なんでこんなことが起こるのかについては、番組で気象予報士の井田キャスターに超わかりやすい説明をしていただいているので、ぜひご覧ください！

www.youtube.com

日食

いわゆる日食というと、↓のようなイメージの方が多いと思います。

地上から見た日食

#部分日食の画像を公開しました。石垣島天文台で撮影した食が最大頃の部分日食です。https://t.co/3gSpOrVh1P pic.twitter.com/H6Bhz5SLmt
— 国立天文台 (@prcnaoj) 2023年4月20日

宇宙から見た日食の映像というのは見たことがない方も多いのではないでしょうか？
ひまわりから見た日食の映像がこちらです！

宇宙から見える日食

youtu.be

左下から徐々に黒い影が地球を横切ってきます。
これが月の影なんです！！

こうして宇宙から見る日食と地上から見る日食、同じ現象なのに全然見え方が違うってすごいですよね。

日食のメカニズムについても番組で井田キャスターの説明がありますので、ぜひぜひあわせてご覧ください！

www.youtube.com

カルマン渦列

ここからは番組で紹介できなかった未公開映像となります！

youtu.be

こちらは「カルマン渦列」という、雲の流れが山や島にぶつかり、迂回しようと回り込んだときに起こる現象です。
渦ひとつが数十キロメートルほどの大きさになるので、地上から視認するのが難しいんですが、ひまわりの目はこんな巨大な自然現象も映すことができるんですね。

モーニンググローリー

まずはこちらをご覧ください！

地上から見たモーニンググローリー

Morning Glory cloud in the North. Australia's Gulf of Carpentaria is the only known location where it can be observed pic.twitter.com/tBLKgvcxTf
— Woow pics (@photo98765) 2015年7月19日

ひまわりから見たモーニンググローリー

youtu.be

まるでSFやRPGのような現実離れした壮大な雲ですよね。

(What's the Story) Morning Glory?

海からの湿った風と陸の乾いた風がぶつかったときに起こる現象で、オーストラリアの北部にあるカーペンタリア湾付近でよく見られるそうです。
といってもレアな出来事なので、これを見るために世界中の雲クラスタが訪れるけれど見れずにしょぼんと帰ることも多いんだとか。

この超かっこいい名前の語源は、朝に起こることが多いことと、その見た目の荘厳さ。
一日の始まりにこんな美しい光景を見たら「Morning Glory（朝の栄光）」と名付けたくなる気持ちもわかる気がします。
カルマン渦列は宇宙からしか見ることのできない現象でしたが、モーニンググローリーは地上、宇宙、両方から視認できます！

森林火災

youtu.be

少しショッキングな映像かもしれません。
これは2019年から数か月に及んで続いたオーストラリアの森林火災の様子です。
東に流れた煙が海を覆っているのがわかります。

この映像の中で多くのいのちや自然が失われていると思うと胸が痛みます。

ただそれと同時に、いいことも悪いこともひっくるめて世界中で同時にあらゆることが起こっている中で、
それを冷静に見つめる宇宙からの目として、ありのままの事実をたくさんの人に見てもらうことって意義あることなんじゃないか？と思いました。

知らないことを知ること

もともと私はド文系で、理系には縁がなかった人間です。
なのにこの一年あまりで気象や天体、自然科学についてたくさん触れることができました。
知れば知るほど昨日とは違った目で世界が見れるということを感じられます。
たとえば気象について知れば、ふと見上げた空に映った雲がどんなふうにできてるんだろう？と考えるきっかけになったり。
現在だけではなく、きっと昔の人も同じように空を見上げて雲の成り立ちに思いをはせたんだろうか？と想像したり。

番組中で河森正治さんもおっしゃってましたが

「知識を体験に変える」

ってそういうことなんだと思います。

そんな新たな体験をみなさんにお届けしたい！と思っているので、ぜひ万博に実際に見に来てください！

shojikawamori.jp

22Kの地球タイムラプス映像をグリグリする

2024-04-27T01:31:20+09:00

どうも！バスキュールの武田(@neko_300YEN)です。

弊社が、4/22 アースデイにやってる番組『KIBO宇宙放送局 #アースデイライブ』

ここで使われたシステムについてメモを残しておきます。

#アースデイライブ2024

www.youtube.com ⇧番組アーカイブはこちら

プロジェクトがどんな建て付けなのかは、動画でも説明してる通り。

地球映像でコンテンツを作ろうと思ったきっかけ

2年前にトンガの噴火があった際に、ひまわりの衛星画像にその衝撃波が映ってるって話があって、試しにひまわりの画像をつなぎ合わせて動画を作ってみたことから始まる。

今日のトンガの噴火(0:08~)。衛星写真で見ると地球という惑星規模で何かが起こったんだなぁという感じがする。 pic.twitter.com/cUap9w7gyg
— 𝕟𝕖𝕜𝕠 𝟛𝟘𝟘𝕐𝔼ℕ (@neko_300YEN) 2022年1月15日

だいぶショッキングな映像で、不謹慎だけど自然現象の規模感とかパワーすげぇなと、圧倒されました。

こんなSF映画みたいなことが実際の地球上で今起こっているのかと。

いろいろ端折りますが、このリアルな映像をなんとか体験にしたいなぁと思ったところからコンテンツ作りが始まったわけです。

インタラクティブに地球映像をズームする

気象衛星ひまわりの画像は11K。10分に1度撮影されています。

単純にこのひまわりの画像をタイムラプスとして繋ぎ合わせるだけだと映像がカクカクしてしまう。あと日本列島までズームすると、フルディスク画像だとさすがにボケる。

そこでひまわりの画像をもとに、機械学習を用いてフレーム補完をしたり、さらに22Kにアップスケールしたりして、高画質で滑らかな映像を作りました。

今回の番組では、コレを4KのLEDディスプレイに表示しています。

※ 映像のクオリティをあげる試行錯誤については、また別の機会に

概念図

こんな感じのイメージで、22Kの映像をディスプレイ解像度の4Kで切り取って表示する再生システムを作りました。

TouchDesignerで動画再生しながら、ゲームパッドを使って地球上のいろんな場所に視点を移動したり、ズームできるようになっています。

システム構成

特筆すべきことはないですが、LEDに出されている映像のポン出しはMIDIコンを使っています。

AKAI MPD226
AKAI APC40 MKII

パッドに映像切り替え、ノブに映像の明るさとか色味のパラメータ調整をアサインして、適宜調整しています。

ボタンはでかければデカい方がいいし、ノブも硬ければければ硬い方がいい。

本番は焦るから・・・。

あと、APC40 MKIIのパッドのMIDI配列の並びがちょっと使い辛かった。

縦の列でチャンネル毎のパッドがあるんだとしたら下記のような並びが良かったんだけど、なんかZ型になってて、これはどういうことなんだろう？

MIDI初心者にはわからない何か理由があるんだろうな。　　

並びを変えたAPC40 MKIIの入力をとるtoxは以下に置いておきます。 MPD226も。

誰もいらないと思うけど。

⇨ https://github.com/Putoshi/TouchDesigner-AKAI-MIDI

あと映像の送出はBlackMagicのDeckLink 8K Proを挿して、SDI出力。

滞ったWindowsアップデートやマカフィーの無料期間終了の通知が画面に出ちゃったら恥ずかしいので、ライブ系の案件ではデスクトップ拡張は避けてます。

映像ファイルがデカすぎる問題

映像ファイルが1日分のデータで40秒くらいしかないのに、40GB近くある・・・。

Hapだとボケまくるので、AppleのProResで書き出して、Windows機で再生しています。 Hapじゃないのにめちゃくちゃでかい。

コレを再生するのにボトルネックになったのは、GPUやCPUではありませんでした。

SSDのデータ読み込みが間に合わない！！

40秒で40GBのファイルだから1GB/s以上の読み込み速度がないといけない。普通のSATA接続のSSDだとカタついてしまう。こういう問題は今まで初めて遭遇した。

NVMe接続のM2.SSDにして解決。

TouchDesignerのFloating Cloud Licensesが外れる問題

Floating Cloud Licensesというネットワーク認証のライセンスを初めて使ってみたんですが、なんかコレちょいちょい外れません？？実行中に急に無料ライセンス版に切り替わったりして、映像が22Kから1280pxになっちゃってびっくりした。

ネットワークの問題なのか、原因を追う時間がなかったので普通のオフラインの商用ライセンスに急遽変更。

ライブ系のプロジェクトで焦らないために・・・。

ライブ系のプロジェクトでは、何かしらの都合で直前に番組の構成が変わったりとか、

何かしらのトラブルで番組中にシステム構成を変更したりしなきゃいけない事があったりします。

いくら自分の作ったものが万全だと思っていても、そういう事態になった時にはけっこう焦ります。

kibo.space

こういう宇宙系のものだと、番組スタッフやそれを実現するために動いてくれた人間が100人とか軽く超えてきてしまう。その人たちの姿を想像すると流石に震えてきたりしちゃうわけです。

パニックに陥った人間はびっくりするくらい頭が回らなくなるもので、前述したような、「ボタンはデカく！！！」とか、そういう些細なことでも案外自分を救ったりします。

ちょっとした安心感をいっぱい作っとくと吉。

自分はそういう思想なので、ライブ系のプロジェクトのコントローラーにあたる部分のシステムには、 TouchDesignerやMaxなどのノードベースのプログラミング環境を使うことが多いです。

パニクってる時は、文字がまともに読めません。

スタッフ用のヘッドセットから「なんで〇〇の映像でてないの！！？？」とか、「音声聞こえてないぞ！！？？」みたいな怒号が飛び交ってる中で、コンソールのちっちゃい文字読めますか？？

僕には無理です。

ログの文字が読めるのは本番前日まで！

だから、文字じゃなくてビジュアルとして何が起きているかわかるノードベースのプログラミング環境を好んでいます。ビルドしないで動くものが好き。

なにか不具合があった際にログを追うよりも早く対応できる気がするし、本番中にプログラムを修正するのも全然怖くない！

あと僕はそもそも自分の書いたコードを信用できるほど、ちゃんとプログラムを書いてないという根本的な問題もある・・・。

以上です。乱文失礼しました！

UnityでiPadをバーチャルカメラにしてイベント本番で使うときの問題点を解決した話をしますね

2022-12-02T14:20:57+09:00

バーチャルカメラを振り回していい感じのメタバースの映像を撮る

宇宙とISSを舞台にしたメタバース、THE ISS METAVERSE のテックリード桟(@katapad) です。

ISSメタバースでは体験者の様子をより魅力的に見せるためのパブリックビューを用意している。iPadをバーチャルカメラにし、手持ちならではのカメラワークで無重力感ある映像を出力している。

このようにiPadがUnityのバーチャルカメラになり、直感的なカメラワークができる。

iPadだけでなくゲームコントローラでも操作できるようにしているが、やはりゲーム感が出てしまう。加速・減速、手ブレ感をチューニングすればそれっぽくもなるが、それはまた別の話。

前提条件: パブリックビューと管理画面をマルチディスプレイで出力

THE ISS METAVERSEではGameViewのDispaly1にゲーム画面(パブリックビュー)、Display2に管理画面を表示して運用している。

この状態でiPadバーチャルカメラを振り回そうとしていた。

iPadバーチャルカメラとフルスクリーンの落とし穴

いざ試してみると以下の障害があった。

Live CaptureがUnity Editor 専用。ビルドすると動かせない
- イベント本番で使うなら、Unity Editorをフルスクリーン化する必要あり
Unity Editorをフルスクリーンにすると
- マルチディスプレイにすると各ディスプレイでマウスの座標・クリック等が共有されてしまう
- 意図した画面をキャプチャできない
Live Captureのないシーンを経由するとLive Captureの接続が切れる

バーチャルカメラとUnity Editorフルスクリーン化+マルチディスプレイを組み合わせると、以下の障害があった。

順番に説明していく。

Live CaptureがUnity Editor専用でビルドすると動かせない (裏技で動かせるらしい)

このiPadをバーチャルカメラにするLive Captureが、実はビルドに対応しておらず、Unity Editorでのみ動作する。

↓Unityの中の人の発言

Yes, the app is only designed to work with the editor. It is theoretically possibly to use for other cases, but this is not officially supported at this time.

Technically you can include the Live Capture package in a standalone build, but it is not officially supported at this time as there is still much work left to properly support this.

↑ この話の流れを見る限り、まだビルドは正式にサポートされてないが、live-captureのパッケージをローカルに移動し、iPadとやりとりをするサーバーをpublicに変更したりCompanionAppServer.OnUpdate()を叩くとうまくいくらしい。って今気づいたよ…。今度試すか…。

じゃあビルドせずにUnity Editorで無理やり使おう！

ということで、まずはUnity Editorでフルスクリーンにできるアセットを導入。

Unity Editorをフルスクリーンにするアセット

Fullscreen Editor | Utilities Tools | Unity Asset Store

このアセットを使うとUnity Editorでもツールバーの出ない完全なフルスクリーンができる。

しかもマルチディスプレイ対応。最高。

display1にUnity内display2の管理画面を持ってきてる

しかし、こういうアクロバティックなことをすると、だいたいうまくいかないもんである。

問題1: Unity Editorでマルチディスプレイをすると、マウス座標が各ディスプレイで共通になって、めちゃくちゃになる

ISSメタバースはパブリックビューと管理画面を1つのアプリで完結させている。なので2画面のマルチディスプレイだ。

困ったことにUnity Editorでの再生時はマウスの位置やクリックなどの情報はすべてのGameViewで共有される。

つまり、GameView1の右上をクリックすると、GameView2の右上もクリックされたことになる。

これは困る…。

解決策: 対症療法で管理画面にロック機能をつけた

ロック解除しても一定時間で必ずロックに戻るようにした。めんどくさい…。

問題2: フルスクリーン時に画面キャプチャーすると、意図しない画面がキャプチャーされる

THE ISS METAVERSEではカメラマンが記念写真を撮ってTwitterにアップする仕組みがある。

twitter.com/astro_cameraman

管理画面とパブリックビュー(ゲーム画面)を同じマシンで出力しており、Display1に管理画面、Display2にパブリックビューが表示される。

で、このキャプチャが難題だった。普通にCameraのTargetTexutreに設定したRenderTextureに焼き込むとポストエフェクトが乗らない。今回はポストエフェクトで太陽に対してレンズフレアを入れてるので、そこを削るわけにはいかない。そこでGameViewをそのままキャプチャする texture.ReadPixels() を使った。似たようなメソッドでScreenCapture.CaptureScreenshotIntoRenderTexture(rt)もあったが、色がおかしくなるのと画像が反転していたので、深く追うのを諦めた。

で、ゲーム画面がキャプチャされるように設定したいところなのだが、フルスクリーンにするとうまくいかない。ゲーム画面ではなく管理画面がキャプチャされてしまうことがある。

ちなみにビルドするとわりと意図した画面がキャプチャできる。Unity EditorではGameViewの座標がマルチディスプレイの環境ではうまく動作しないのが仕様なので、もしかするとDisplay1とDisplay2の座標が同じになって、どっちをキャプチャするかがランダムになるのかもしれない。しらんけど。

解決策: フルスクリーンガチャをする

そんなこんなで何度か試していると、キャプチャ対象になる画面はフルスクリーンにしたときにランダムで決まることがわかった。

なので、フルスクリーンにしてキャプチャし、意図通りの画面をキャプれたらOK。失敗したらもう一度フルスクリーンにしてキャプチャ…、というガチャをすることで対応した…。

問題3: PhotonでシーンをロードするとLive Captureが外れる

ISSメタバースはロビーとなるシーンを経て、実際のゲームルームシーンへ遷移する。

Live Captureが含まれているのはロビー以降に読み込まれるゲームシーンのみ。なので、ロビーを経由した時点でiPadの接続が切れてしまう。

解決策: iOSのタスク切り替えを一瞬やると戻る

Live CaptureのiOSアプリがタスク切り替え時に再コネクトしようとするらしく、それでうまくいく。

まとめ

そんな感じで無理やり対応したけど、めちゃくちゃいいカメラワークができたんじゃないか。

あと、地味にビルドせずにフルスクリーン化して動かすのもめっちゃ楽。ずっといじくり倒せるのがいい。

でもビルドしてえよなあ。またいつかビルドできるように書き換えよう。

キャプチャまわりはこうしたほうがいい！とかLive Captureビルドして使った！などの怪談がありましたら、教えてください！待ってまーす！

おもしろがって作れる人材募集中！

ISSメタバースみたいな新しい遊び場を作って、自分らで遊び倒して、でっかいプロジェクトにしてみんなに遊び倒してもらう。そんなことやってみたいなーって思う人はJOIN US！！！

bascule.co.jp

オカシなツリーを飾る技術とチャレンジ

2022-02-21T16:57:50+09:00

こんにちは、エンジニアの野島(@daumkuchen)です。

株式会社明治様の特設サイト「明治クリスマスこどもパーク」内メインコンテンツ「オカシなコーラスツリー！」の企画・制作を弊社が担当しました。
コロナ禍でのコミュニケーションを模索する中、合唱という形を通じてつながりを感じる体験ができるスマートフォンサイトです。カスタマイズしたキャラクターをポストし、インターネットを通じて世界中の参加者が1つのツリーに集まります。

bascule.co.jp

テクニカルディレクション
バックエンド開発
インフラ構築

自分の担当領域は主にこちらの3点です。
普段はフロントエンドを担当することが多い自分にとって、バックエンド・インフラ領域へのチャレンジとなるプロジェクトです。
具体的にどういったことにチャレンジをして、どういったことに気をつけたのかなどを話します。

チャレンジしたこと

技術選定

新しい技術を使う部分と慣れた技術を使う部分を明確に分け、実現可能性とのバランスを取りました。

新しい技術
- Go（API）
- Terraform（IaC）
慣れた技術
- Nuxt.js（管理画面）
- Python（ロードテスト）
- Node.js（AWS Lambda）

セキュリティ対策

参加型コンテンツということもあり、多くの方の個人情報を扱います。
なのでセキュリティに関しては一般的なウェブサイト案件よりも厳しい基準を設けて臨みました。

インフラはAWSで構築しました。構成は以下になります。

VPC：プライベートサブネットを使ったセキュアな構成
EC2：Trend Micro Cloud One Workload Securityを導入しセキュリティを強化
NLB：リクエストの分散処理
CloudWatch：パフォーマンスやリクエストのモニタリング
SNS, ChatBot：異常検知時の通知（メール、Slackチャンネル）
WAFv2：Dos攻撃対策
GuardDuty：脅威検出
S3：各種ログの保管

上記のようなセキュリティ対策を徹底し、運用期間中は問題もなく稼働させることができました。

役に立ったこと

特にGoはとても良い感触で作業することができました。

動作が軽い
記述ルールが厳密で記述の揺れが少ない
ポインタや構造体もシンプルで扱いやすい
複雑化しやすいエラーハンドリングがきれいに書ける
APIに必要なアセットやリファレンスが充実している（例：gin, gin-swagger, gorm）

例：ユーザー作成時の処理の流れ

// 構造体を初期化
user := User{}

// ユーザー作成
createdUser, err := controller.Create(user)

// エラーが返って来れば、メッセージのレスポンスを返す
if err != nil {
 c.JSON(500,
 gin.H{
 "message": fmt.Sprintf("Error: %s", err),
 })
 return
}

c.JSON(200, createdUser)

Goの特徴である並列処理を今回使う機会はありませんでしたが、それでも十分メリットを実感することができました。

気をつけたこと

リスクを常に考える

課題は自分1人で抱えず、全体に周知する
少しでも不明な箇所は事前に相談する
運用・インシデント対応マニュアルを作成する

社内の先輩エンジニアとコミュニケーションをとり、常に視界をクリアにしながら進めることを心がけました。

チャレンジした結果

常に勉強しながらの作業は決して楽ではありませんでしたが、その分大きな学びとなりました。
特にセキュリティ周りを厚めに対応したので、今後の案件でも活かす機会がありそうです。
新しいことを覚えるには、実践を通して手を動かすことが一番身につきやすいと実感しました。

成長機会を求めている方をバスキュールは探しています

バスキュールはやりたいことに手を挙げればチャレンジさせてくれる会社で、適切に取り組めばそれをバックアップしてくれる環境があります。
率先して何かにチャレンジしたいと思っている方は、是非ご気軽にお声掛けください。

（特にバックエンドエンジニア募集しています...）

bascule.co.jp

「#きぼうを見ようAR」逆ジオコーディングを作った話

2021-10-28T14:00:57+09:00

はじめまして、こんにちは。
今年の4月から新卒入社したエンジニアの矢尾(@80momoka)です。

弊社が以前から運営している「#きぼうを見よう」に、
新たに「ARきぼう予報」という機能が追加されました。

#きぼうを見よう
https://lookup.kibo.space/
AR機能はスマートフォンでご覧ください。

#きぼうを見ようのサイトに、新機能「🆕ARきぼう予報」が追加されました🎉

スマホを空にかざすだけで、ISSの現在地や軌道予測がわかります✌️これからはもっとISSを探しやすくなりますよ！🛰️
今夜のISSは日本上空を通過予定。ぜひ、あなたの上空の予報を見てみてね！https://t.co/qVOXuh8k5T
— KIBO宇宙放送局 (@KIBO_SPACE) 2021年10月6日

このARきぼう予報の中で、方角と位置関係をわかりやすくするために、周囲の都道府県がどの方角にあるかを示す表記をいれています。（下画像、赤い枠内に〇〇方面と表記）

この都道府県名を表示する際に、ユーザーが今いる県は非表示にしています。そのために現在地から都道府県を割り出す必要があり、簡易的な逆ジオコーディングを独自実装したので、それについて書きたいと思います。

逆ジオコーディングとは

まずジオコーディングとは、住所などから座標（緯度経度）を取得する機能のことで、
逆ジオコーディングとは文字通り逆の、座標（緯度経度）から住所を取得する機能のことです。

ARきぼう予報ではISSの軌道予報を計算するために、既にユーザーの現在地の緯度経度を取得していたため、そのデータを使用して地名を取得しようとしました。

逆ジオコーディングのAPIを探しましたが、有料であったり利用制限があったりと、望ましいものが見つからなかったため作ることになりました。

取得の流れ

全国各地の住所とその緯度経度のデータから、現在地の緯度経度と一番近い距離のデータを探し出し、その住所を取得しています。

全国各地の住所と緯度経度のデータは、国土交通省が提供している位置参照情報を使用しました。

国土交通省　位置参照情報ダウンロード
https://nlftp.mlit.go.jp/cgi-bin/isj/dls/_choose_method.cgi

各データは以下のようになっています。

{
    '都道府県コード': '01',
    '都道府県名': '北海道',
    '市区町村コード': ' 01101',
    '市区町村名': '札幌市中央区',
    '大字町丁目コード': ' 011010001001',
    '大字町丁目名': '旭ケ丘一丁目',
    '緯度': '43.042230',
    '経度': '141.319722',
    '原典資料コード': '0',
   '大字・字・丁目区分コード': '3'
}

このデータが羅列されたCSVファイルのままだとサイズがとても大きく扱いにくいため、
まずはJavaScriptから扱いやすいようにjsonを作成することにしました。

JavaScriptで現在地の都道府県を割り出す仕組みとしては、以下のように考えました。

上の画像のように、緯度経度の値ごとに区切った座標検索データを作って、現在地の緯度経度が含まれている範囲のデータの中から一番距離の近いデータを探し出します。
円が重なっている所はデータが重複しますが、距離を計算するための緯度経度の値があればいいので、都道府県や市区町村などの住所のデータは別で分けて緯度経度のみのファイルにします。住所データは、緯度経度のデータと対になるidを付けて、id 1~100、101~200…とファイルを分けます。

ただ今回の実装では、都道府県のみ取得できればよく、そこまで厳密な市区町村情報までは不必要であったため、データの重複をなくし、下の画像のように経度ごとのみで分けました。

(左：経度ごとに分けるイメージ　右：分けて作成した緯度経度情報のみのjsonファイル)

今回は経度0.1度ずつに分けてjsonファイルにまとめました。
件数の少ない経度127.5度以下や145度以上、128度以上129度未満(沖縄県の東側〜鹿児島県大島郡付近)はそれぞれまとめて一つのファイルにしています。

データを割り出す際は、現在地の経度と一致するjsonファイル(127.5度台であれば1275.json)を指定し、その中から現在地の緯度経度と一番距離が近いデータを探し出して割り出します。

しかしこのままだと、例えば下図のように赤●が現在地で★が一番近い市区町村だとしても、黄●の市区町村を取得してしまいます。精度を上げるために、赤●を含むデータとその左右のデータも含めた中から、一番近い距離のデータを探します。

今回の機能では、都道府県名のみ割り出せたらよく厳密な市区町村情報までは不必要であるため、現在地の経度を含む範囲のファイル内のみで割り出しています。

また、今後もし精度が求められる機能が追加されることがあった時に、データを使いやすいように緯度経度と住所に分けたままにしています。

(左：緯度経度のみのファイル　右：住所のみのファイル)

周囲の都道府県を選出・表示

まず各都道府県の県庁所在地の緯度経度と県名、ARに表示する名前をリストにしたものを用意します。

static list = [
   {'lat':43.06417, 'lng':141.34694, 'name':'北海道',   'label':'北海道方面'},
   {'lat':40.82444, 'lng':140.74,    'name':'青森県',   'label':'青森方面'},
 …

このリストの中から、現在地の緯度経度と距離が近い順に取得します。
ユーザーがいる場所の県名は非表示にしたかったので、逆ジオコーディングで取得した県名とリストのデータ内の県名を照らし合わせて、合致しているものは省きます。
また今回は近隣の県のみ表示したかったので、ある程度距離が離れている県はこの時点で省きました。

県庁所在地がある方向を単純に2点の緯度経度から求めようとしたものの、地球は球体であるため簡単な計算ではズレが生じてしまいました。
現在地から各地点への正確な方角を求めるのは、geodesyというライブラリ内のコードを使用しました。

geodesy
https://www.npmjs.com/package/geodesy

Geodesy functions | Class: LatLonEllipsoidal_Vincenty finalBearingTo()
https://www.movable-type.co.uk/scripts/geodesy/docs/module-latlon-ellipsoidal-vincenty-LatLonEllipsoidal_Vincenty.html#finalBearingTo

Javascriptで２地点間の距離と方角を計算するライブラリ
https://thr3a.hatenablog.com/entry/20190502/1556772556

finalBearingTo()という関数にて取得した方角(0~360の値)をもとに、3D空間内に配置しています。

const len = 360;
const step = Math.PI * 2 / len;
const size = this.ar.dome.size;


const point = { 'lat':lat, 'lon':lng };
const angle = this.finalBearingTo(point);


// pos
let x = Math.sin(step * angle) * size;
let y = offsetY;
let z = Math.cos(step * angle) * size * -1;

youtu.beこのようにユーザーの周りに県名を表示することで、自分がどこ方面を向いているのかわかるようになり、ISSがいま日本のどこの上空を通過しているのか想像しやすくなっているのではないかと思います。

エンジニアを募集しています

私自身はまだエンジニア一年生ですが、バスキュールには凄いエンジニアの方がたくさんいらっしゃいます。
見たこともない新しいコンテンツを、企画から制作まで一緒に作っていけるのが非常に楽しいです。
また、かっちり決まった部署や働き方があるわけではないので、望めば様々なことに挑戦できる環境だと思います。
バスキュールの働き方に興味がありましたらぜひご応募ください。

bascule.co.jp

ARきぼう予報を作って宇宙飛行士に手を振った話

2021-10-20T10:43:50+09:00

エンジニアの勝田です。こんにちは。

弊社で開発・運営している「#きぼうを見よう - 国際宇宙ステーションが見える予測日時をお知らせ」というサイトに新しく「ARきぼう予報」というWebAR機能を追加しました。

ARきぼう予報 | #きぼうを見よう - 国際宇宙ステーションが見える予測日時をお知らせ

国際宇宙ステーション（ISS）がどんな軌道を通るか、リアルタイムでどこにいるのかがわかるサービスです。
今日はそのAR機能についてお話したいと思います。

ISS観測について

上空付近をISSが通過するときにいくつかの条件がそろうと肉眼で観測することができます。
詳しくはこちらをご覧ください。

lookup.kibo.space

ISSは、

明るい星のような強い光
飛行機のようにチカチカせず
飛行機よりも速いスピードで

見えます。
とても特徴的なので、一度見つければ「あれはISSだ！」とすぐにわかります。
ただ、見つけるまではなかなかわかりにくく、ISSかな？と思って見ていると星だったり飛行機だったりします。特に初めてISS観測を行う人の場合、雲が多かったり、仰角（ISSが見える高さ）が低いとどれがISSなのかわからず、本当にISSは見えるんだろうか…と不安な気持ちで空を眺めて待つことになります。

そんなとき、ARきぼう予報を使ってスマホを空にかざすと、いまどこにISSがいて、いつごろ見えるかがビジュアライズされているため簡単に観測ができるようになります！
こちらは開発中に撮影したキャプチャですが、こんな感じです。

「ARきぼう予報」ただいま鋭意開発中！🚀

こんな感じで、ISSの軌道や通過時間の予測が見られるようになります！サイトの使い方は、10/6(水)18:20頃〜Twitter Spacesでも紹介する予定なので、みなさんぜひ、スマホ片手に参加してくださいね！📱🛰️ #きぼうを見よう pic.twitter.com/auVzFNiXW6
— KIBO宇宙放送局 (@KIBO_SPACE) 2021年10月4日

モックを作る

3D構築にはThree.js、AR機能はスマホのカメラ、位置情報、ジャイロセンサーを使用しています。
今回はISSの座標をAR上に表示するため、Three.js上での方角と現実世界の方角を合致させる必要がありました。
そのため、まず、シンプルに真北にキューブを表示するだけのモックを作成することにしました。

モックの完成品はこちらからどうぞ。
github.com

プレビューページ（PC非対応です）
https://yuko-katsuda.github.io/armock/index.html

3D環境のベースを作る

<!DOCTYPE html>
<html>
<head>
 <meta charset="utf-8"/>
 <script type="module">
 import * as THREE from '<https://cdn.skypack.dev/three>';

 window.addEventListener('load', init);

 var $view;

 var width = window.innerWidth;
 var height = window.innerHeight;

 function init()
 {
 $view = document.querySelector('#view');
 setup3D();
 }

 function setup3D()
 {
 const renderer = new THREE.WebGLRenderer({alpha: true, canvas: $view});
 renderer.setPixelRatio(window.devicePixelRatio);
 renderer.setSize(width, height);

 const scene = new THREE.Scene();

 const camera = new THREE.PerspectiveCamera(80, width / height, 0.1, 100);
 camera.position.set(0, 0, 10);

 const geometry = new THREE.BoxGeometry(1, 1, 1);
 const material = new THREE.MeshNormalMaterial();
 const box = new THREE.Mesh(geometry, material);
 box.position.set(0, 0, 0);
 scene.add(box);

 update();
 resolve();

 function update()
 {
 requestAnimationFrame(update);
 renderer.render(scene, camera);
 }
 }

 </script>

</head>
<body>
 <canvas id="view"></canvas>
</body>
</html>

以下のページを参考にしています。

簡単なThree.jsのサンプルを試そう - ICS MEDIA

キューブの座標を(0, 0, 0)に設定していますが、z:0 = 現実世界の真北にしたいので、キューブが常に真北に表示されるようになればモックの完成です。

デバイスの向きの取得

Three.jsのDeviceOrientationControlsを使用してデバイスの向きと3D上の世界を同期させます。

three.js docs DeviceOrientationControls

ですが、デフォルトのままだと、iOSでは起動時の向きがz:0に補正され、Androidでは起動するたびに0の向きが変わってしまいます。

絶対値で向きを取得するイベントに差し替える

deviceorientationabsoluteというイベントがあり、その名のとおり絶対値でデバイスの向きを取得できるAPIです。

Window.ondeviceorientationabsolute - Web APIs | MDN

まず、Three.jsのDeviceOrientationControlsクラスを複製して新しいjsを作ります。すべての内容を載せると長くなるので、ポイントのみ記述します。

なお、完成品のDeviceOrientationControlsクラスはこちらになりますので、先に載せておきます。
https://yuko-katsuda.github.io/armock/DeviceOrientationControls.js

複製したファイル内でdeviceorientationイベントを走らせているところを探し、そこをdeviceorientationabsoluteに書き換えました。
ライブラリのバージョンによって内容に若干違いはあるかもしれませんが、this.connect関数の中にあります。

変更前

this.connect = function () {

 onScreenOrientationChangeEvent(); // run once on load

 // iOS 13+

 if ( window.DeviceOrientationEvent !== undefined && typeof window.DeviceOrientationEvent.requestPermission === 'function' ) {

 window.DeviceOrientationEvent.requestPermission().then( function ( response ) {

 if ( response == 'granted' ) {

 window.addEventListener( 'orientationchange', onScreenOrientationChangeEvent );
 window.addEventListener( 'deviceorientation', onDeviceOrientationChangeEvent );

 }

 } ).catch( function ( error ) {

 console.error( 'THREE.DeviceOrientationControls: Unable to use DeviceOrientation API:', error );

 } );

 } else {

 window.addEventListener( 'orientationchange', onScreenOrientationChangeEvent );
 window.addEventListener( 'deviceorientation', onDeviceOrientationChangeEvent );

 }

 scope.enabled = true;

 };

変更後

this.connect = function () {

 onScreenOrientationChangeEvent(); // run once on load

 // iOS 13+

 if ( window.DeviceOrientationEvent !== undefined && typeof window.DeviceOrientationEvent.requestPermission === 'function' ) {

 window.DeviceOrientationEvent.requestPermission().then( function ( response ) {

 if ( response == 'granted' ) {

 window.addEventListener( 'orientationchange', onScreenOrientationChangeEvent );
 window.addEventListener( 'deviceorientation', onDeviceOrientationChangeEvent );

 }

 } ).catch( function ( error ) {

 console.error( 'THREE.DeviceOrientationControls: Unable to use DeviceOrientation API:', error );

 } );

 } else {

 window.addEventListener( 'orientationchange', onScreenOrientationChangeEvent );
 window.addEventListener( 'deviceorientationabsolute
', onDeviceOrientationChangeEvent );

 }

 scope.enabled = true;

 };

iOS Safariはdeviceorientationabsoluteに対応していません。
なので、以下のようにコードを書き換えました。

const ua = navigator.userAgent
if(/android/i.test(ua))
{
 window.addEventListener( 'orientationchange', onScreenOrientationChangeEvent, false );
 window.addEventListener( 'deviceorientationabsolute', onDeviceOrientationChangeEvent, false );
}
else
{
 window.addEventListener( 'orientationchange', onScreenOrientationChangeEvent, false );
 window.addEventListener( 'deviceorientation', onDeviceOrientationChangeEvent, false );
}

出来上がったDeviceOrientationControlsクラスをimportして、setup3D関数でコネクトします。

ライブラリのimport

 import * as THREE from '<https://cdn.skypack.dev/three>';
 import { MathUtils } from '<https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.module.js>';
 import { DeviceOrientationControls } from './DeviceOrientationControls.js';

setup3D関数

 function setup3D()
 {
 const renderer = new THREE.WebGLRenderer({alpha: true, canvas: $view});
 renderer.setPixelRatio(window.devicePixelRatio);
 renderer.setSize(width, height);

 const scene = new THREE.Scene();

 const camera = new THREE.PerspectiveCamera(80, width / height, 0.1, 100);
 camera.position.set(0, 0, 10);

 // DeviceOrientationControlsをコネクトさせる
 var controls = new DeviceOrientationControls(camera);
 controls.connect();

 const geometry = new THREE.BoxGeometry(1, 1, 1);
 const material = new THREE.MeshNormalMaterial();
 const box = new THREE.Mesh(geometry, material);
 box.position.set(0, 0, 0);
 scene.add(box);

 update();

 function update()
 {
 requestAnimationFrame(update);
 renderer.render(scene, camera);

 // コントロールを更新
 controls.update();
 }
 }

iOSでの向きを地球軸にする

iOSではThree.jsを実行した向きが0として補正されてしまいます。
なので、ページを表示した瞬間のalpha値をalphaOffsetに渡し、強制的に補正前に戻すようにしました。

 // DeviceOrientationControlsをコネクトさせる
 var controls = new DeviceOrientationControls(camera);
 controls.connect();

 // iOSのとき、一度だけalphaOffsetに補正値を渡す
 if(os == 'ios')
 {
 var deg = 0;
 var diff = null;
 var doneCalibration = false;

 window.addEventListener('deviceorientation', (e)=> {
 deg = e.webkitCompassHeading;
 if(deg != 0 && diff == null)
 {
 diff = deg;
 }

 if(!doneCalibration)
 {
 doneCalibration = true;
 controls.alphaOffset = MathUtils.degToRad( - diff );
 }

 }, true);
 }

カメラの取得

続いてカメラ映像の取得です。
Media Streams APIを使用してストリームを取得し、htmlのvideo要素に渡しています。

 function setupCamera()
 {
 return new Promise((resolve, reject)=>{
 window.mediaDevices = navigator.mediaDevices || ((navigator.mozGetUserMedia || navigator.webkitGetUserMedia) ?
 {
 getUserMedia: (c)=> {
 return new Promise((y, n)=> {
 (navigator.mozGetUserMedia ||
 navigator.webkitGetUserMedia).call(navigator, c, y, n);
 });
 }
 } : null);

 const mediaConstraints = {
 audio: false,
 video: {
 width: 1920,
 height: 1080,
 facingMode: { exact: 'environment' }
 }
 };

 window.mediaDevices.getUserMedia(mediaConstraints)
 .then((stream)=>
 {
 $video.srcObject = stream;

 $video.onloadedmetadata = (e) =>
 {
 $video.play();
 resolve();
 };
 })
 .catch((err) =>
 {
 reject();
 });
 });
 }

「MediaDevices.getUserMedia() 」について - Qiita MediaDevices.getUserMedia() - Web API | MDN

位置情報の取得

位置情報の取得にはGeolocation APIを使用しています。
getCurrentPositionというメソッドを実行すると、latitude（緯度）、longitude（経度）などの値が返ってきます。

 function setupGeo()
 {
 return new Promise((resolve, reject)=>{
 navigator.geolocation.getCurrentPosition((data)=>{
 resolve(data);
 },
 (e)=>{
 reject(e);
 });
 }
 catch(e)
 {
 reject(e);
 }
 }
 }

Geolocation.getCurrentPosition() - Web API | MDN

これで3つの機能の取得ができました。

デバイスの許可フローを作る

deviceorientationを取得するためには、ユーザーになんらかのアクションをさせ、そのイベント内で許可フローを実行しなければなりません。
また、カメラで取得した映像をJavaScriptから再生させるためにも事前のユーザーインタラクションが必要になるので、以下のようにボタン押下イベントを起点とする許可フローを作成しました。

 function init()
 {
 // html要素を取得
 $view = document.querySelector('#view');
 $video = document.querySelector('#video');
 $button = document.querySelector('#button');

 // ボタンをクリックするとonClickを実行
 $button.addEventListener('click', ()=>{
 onClick();
 });
 }

 function onClick()
 {
 // ボタン押下後、非表示にする
 $button.classList.add('hide');

 // 3D、カメラ、位置情報を順番に取得していく
 setup3D(()=>{
 Promise.resolve()
 .then( () => setupCamera() )
 .then( () => setupGeo() )
 .then( (data) => {
 console.log(data);
 })
 ;
 });
 }

ARきぼう予報では、ジャイロ、カメラ、位置情報の3種類すべてを使用しているため、それぞれの機能をPromiseで繋いでいます。

なお、モックでは端折っていますが、ユーザー側での拒否や端末の非対応など何らかのエラーが発生するとrejectに繋いでヘルプページに遷移するようにしていました。

これでモックの完成です。
このように、ジャイロ、カメラ、位置情報の3つを同期させ、さらに、ISSの位置情報や、地球の自転、公転による天体との位置関係を組み合わせることでARきぼう予報を実現しています。

youtu.be

どこまで機能するか？

ジャイロの精度が端末ごとにかなりぶれがあり、完璧ではないという問題がありました（特にAndroid）
比較的安定しているiOSも、deviceorientationのずれを補正するのに起動直後の値を使用しているため、AR実行時にスマホを持つ手が大きく揺れていたりするとずれてしまう可能性がありました。

デバイスのセンサーを取得しているため、デバイス側がずれているとどうしようもないわけです。そのような限界がある中で、ISSの観測ツールとしてARきぼう予報がどこまで機能するか？という不安がありました。
ちなみにISSは毎日見えるわけではありません。条件が合わないと1ヶ月近く肉眼で見えるタイミングがなかったりします。
なかなかISS観測をするチャンスがないまま、開発を進めていました。

開発版のチェック

きぼうを見ようチームのメンバーは関東と関西それぞれ住んでいるところはバラバラです。
AR機能がある程度動作するようになったころ、全国的にISSを観測できる好条件がそろった日があり、開発版をチームでチェックすることになりました。
なお、この時点で私はARを使ったISSの観測が一度もできていません。使い物にならなかったらどうしよう…とドキドキしながらチェックに臨みました。

結果、少しずれはありましたが、ARを使うことでこれまでよりも格段にISSの観測がしやすくなることがわかりました。
ISSは弱い光が自分の真上に近づくにつれて徐々に強い光へと変わっていくのですが、かなり弱い光の時点からISSを発見することができました。リアルタイムのISSの軌道がAR上に表示されているため、肉眼で確認するよりもずっと早くISSが昇ってくる位置の目星がつけられるのです。これなら誰にでも簡単にISSを見つけることができると確信しました。

ちなみにこの日、「みんなで #きぼうを見よう LIVE」というTwitter Spacesで全国の方とお話しながらISSを観測するイベントがKIBO宇宙放送局Twitterアカウントで行われていたのですが、LIVEの前に星出彰彦宇宙飛行士からこんなツイートがありました。

手を振りますねー！ https://t.co/iaRKZ4C4ho
— 星出彰彦 (JAXA宇宙飛行士) (@Aki_Hoshide) May 14, 2021

地上とISSは約400km以上離れています。地上からはISSは星の光のように見えます。
あの光の場所に人がいるんだなあと思うと、なんだか信じられないような不思議な感動があります。そして、いま私と同じように空を眺めている人たちが日本中にいて、会ったことはないけど同じ感動を共有してるってすごいことだと思いました。
（その感動は、「今見上げている人数」という機能に引き継がれました）

星出宇宙飛行士もそんな気持ちだったらいいなあと思いながら、いっぱい手を振りました！

youtu.be

そのときのTwitter Spacesの様子がこちらです。
全国のみなさんといっしょに空を渡るISSを探しながら、星出宇宙飛行士に手を振った、すてきな時間でした。

「みんなで #きぼうを見よう LIVE」はときどき開催しておりますので、ぜひAR機能を使って参加してみてください！肉眼で見えるISSは本当に綺麗です。
KIBO宇宙放送局のTwitterで随時お知らせ中です。

KIBO宇宙放送局 (@KIBO_SPACE) | Twitter

エンジニア募集してます！

そして、バスキュールではただいま新しい仲間を募集しています。
まだ誰も体験したことのないようなものを作る感動を味わってみたいという方、一緒に働きませんか？
ぜひぜひご応募お待ちしております！！ bascule.co.jp

Nuxt.jsを使用したスクロール連動の演出実装

2021-09-15T11:08:34+09:00

こんにちは、エンジニアの野島(@daumkuchen)です。

弊社で企画・制作した、⾃然エネルギーの爆発的普及を実現する新会社「PowerX」のサイトを先日ローンチしました。

https://power-x.jp/

⾃然エネルギーの爆発的普及を実現する新会社「PowerX」のサイトを企画・制作しました。

「洋上で発電した電力を蓄電し、船で陸地に運ぶ」という規格外なビジョンを持ったベンチャー企業のパワーとスケール感を、全面にプレゼンテーションするサイトになっています。https://t.co/s9e9uEXkfM
— Bascule Inc. - Project Design Studio (@Bascule_Inc) 2021年8月25日

こちらのサイトはフロントエンドをNuxt.jsで構築しており、その中でスクロール連動の演出実装にチャレンジしました。
そこから技術的な見どころを少しご紹介させていただきます。

サイトの見どころ

スムーススクロール + 無限スクロール

モック

完成

「スムーススクロール」については、ブラウザのデフォルトのスクロール機能は使っていません。
DOMのコンテナをjsでアニメーションすることによって擬似的にスクロールさせる、一般的(?)に実装されるスムーススクロールと同じような作りになります。

// amount : wheelやtouchmoveの量の値
// ease : 減衰値（例：0.1）
this.scroll.value += (amount - this.scroll.value) * ease;

gsap.set('.l-scroll-container', {
 y: this.scroll.value,
});

「無限スクロール」は一番下までスクロールするとmod関数によりスクロール値を0に戻す作りになっています。
カルーセルスライダーのループと同じようなロジックです。

const mod = (i, j) => {
 return (i % j) < 0 ? (i % j) + 0 + (j < 0 ? -j : j) : (i % j + 0);
}

// page_height : ページ全体の高さ
// clone_height : 無限にスクロールに見せるため1番上のsectionを複製して1番下に置く、その高さ
this.scroll.amount += (amount - this.scroll.amount) * ease;
this.scroll.value = mod(this.scroll.amount, page_height - clone_height);

まずこちらのスクロールの仕組みのモックを事前に作成し、技術的課題をチェックしたり、想定している演出の可否チェックなどを行いました。

スクロールと連動した演出の仕組み

各sectionごとにスクロール値を正規化してコンポーネントにpropsで渡しています。

<template>
 <Child
 :move="move" />
</template>

<script>
export default {
 props: {
 move: 0.0,
 },
 methods: {
 update(){
 requestAnimationFrame(this.update.bind(this));

 const value = -this.scroll.value;
 // min : sectionに入るタイミングのスクロール値
 // max : sectionから出るタイミングのスクロール値

 if (min <= value && max >= value){

 // sectionに入ったタイミングで発火！
 
 } else {

 // sectionに入っている間毎フレーム発火！

 // min、max、スクロール値を元に0~1に正規化した値を渡す
 const height = max - min;
 const scroll = (value - min);
 const move = scroll / height;
 this.move = move;
 }
 }
 }
}
</script>

実際はフラグ処理や分岐等でもっとコード量は多いので、正規化のロジックのみ取り出しています。
このように値をpropsに渡してあげることで、演出を各コンポーネント内で完結でき、作業の分担をしやすくしました。

「ここの仕組みがもっと知りたい！」などあれば、コミュニケーションとっていただけるとありがたいです！

困ったけど解決したこと

watchメソッドの最適化

モックを作り、本番環境を整え、一度全ての要素を入れ込んだ状態で最初にぶつかった壁はパフォーマンスでした。
ボトルネックを探した結果、上記で子コンポーネントに渡していたmoveをwatchしていたメソッドが怪しいと感じました。
フラグを設置して、明示的にON/OFFするようにしたところ、負荷が劇的に改善されました。
おそらくmoveが書き換わらなくても、watchメソッドが裏側で動作していたと思われます。

// BEFORE
export default {
 props: {
 move: {
 type: Number,
 default: 0.0
 },
 },
 watch: {
 move: function () {
 // 演出実装
 }
 }
}

// AFTER
export default {
 props: {
 move: {
 type: Number,
 default: 0.0
 },
 },
 data() {
 return {
 isUpdate: true,
 }
 },
 methods: {
 init() {
 this.frameUpdate();
 },
 frameUpdate() {
 requestAnimationFrame(() => this.frameUpdate() );
 if (!this.isUpdate) return;
 this.isUpdate = false;
 // 演出実装
 }
 },
 watch: {
 move: function () {
 this.isUpdate = true;
 }
 }
}

今回はwatchメソッド内で重い処理を走らせていたので気づきましたが、普段は中々気づきにくいところかもしれません。

改善したいこと

nuxt generate後に生成されるhtmlのmetaが書き換わらない

/pages/配下で指定したページのmetaの内容が、書き出されたhtmlに反映されず、nuxt.config.jsの内容のままになっていることが発覚しました。
色々調査しましたが直接的な原因は分からず。
結局nuxt generate後に書き出されたhtmlをnode.jsで直接書き換えることになりました。

const LIST = [
 {
 'ja': /旧タイトル/g,
 'en': '新タイトル',
 },
 {
 'ja': /旧ディスクリプション/g,
 'en': '新ディスクリプション',
 },
 {
 'ja': 'lang="旧言語設定"',
 'en': 'lang="新言語設定"',
 },
 {
 'ja': '<meta data-n-head="1" data-hid="og:url" property="og:url" content="旧シェアURL">',
 'en': '<meta data-n-head="1" data-hid="og:url" property="og:url" content="新シェアURL">',
 }
];

function replace(path, list) {
 const data = fs.readFileSync(path, 'utf8');

 let result = data;
 list.forEach(e => {
 result = result.replace(e.ja, e.en);
 });

 fs.writeFile(path, result, 'utf8', function (err) {
 if (err) {
 throw err;
 }
 });
}

replace('./dist/index.html', LIST);

今でも明確な答えは分からずじまい... 困った...困った...

...！！！

そんな答えの分かるエンジニアをバスキュールは探しています

使うフレームワークは自分で決められる！個人の裁量が大きいバスキュールに来てみませんか！？フロントエンドからバックエンド、肩書きの垣根を超えて活躍したい方はぜひ一度お話ししましょう！

bascule.co.jp

ExoplanetLanderのゲーム開発と、そこに至るまでの話

2021-06-28T17:59:18+09:00

前回のぷとしくん（タケダ）の記事に続き、今回も「ExoplanetLander」の開発について。

前回は機材周りの話が中心だったので、今回は僕（ワダ）が担当したゲーム部分の話を中心に書いてくことにします。

最初に、このコンテンツを作るに至った経緯について簡単に触れておきます。
（以下、文体を変えます）

元々は、人材募集に難航していたので、まず会社のことを知ってもらうためにPRコンテンツを作ろう。というのがことの発端。で、PRコンテンツを作るにあたって、オフィスの移転を目前に控えていることもあって、いまのオフィスを使って何かがしたいということになった。

そこで

オフィスでAR
オフィスでデジタルツイン
オフィスにレーザーで照射

みたいな話があって、レーザーで何を照射するのかって話でLunarLanderがネタとして上がったんだけど、レーザーが1台しかなくて全然描画できなかったのと、安全面的にレーザー常設はやっぱり厳しいなって話でそれもナシに。

オフィスでARは、あんまりオフィス内が丸見えなのも困るから水没させようって言ってこんなことをしてた。

#ExoplanetLander このコンテンツを開発するに至る前に、何をするかっていう段階であがってた別案のテスト。オフィスの中でARで何かしようとしてた。
放置された例の筐体がひっそりと佇んでるのが写り込んでる。後にここがビカビカすることになる。 pic.twitter.com/fRwyXd7XOU
— Michiyasu Wada (@seyself) 2021年6月25日

前々回の記事にあったTOIOのやつも実はその過程で生まれたもの。 blog.bascule.co.jp

レーザーの話は、最初Webカムでアクセスして自分の姿が他人のオフィスに勝手に写しだされてたらそれだけで面白いんじゃないか。みたいなノリで話が先行し、やってたのがこれ。

#ExoplanetLander 何の使いみちも無く興味本位で買ったレーザーをなんとかコンテンツに使えないかと、Webカメラ越しに遠隔の映像を壁に照射しようとしたりも。（なぜ脱いでるのか。。。） pic.twitter.com/QmAoaMJANt
— Michiyasu Wada (@seyself) 2021年6月25日

レーザーは、上記で使っていたのは LaserCube だけど、僕が使ってたのは LightingCraft A600RGB + EtherDream2。いつの間にか EtherDream3 が出てる。

レーザーは取り扱い要注意なので、利用の際はあくまで自己責任で。 github.com

閑話休題

そんなこんなで最終的に目についたのがあの筐体で、この中にLunarLanderを入れて、筐体を遠隔でジャックしてゲームプレイできたら楽しそう。
よその会社のコーポレートサイトの、しかも採用ページで、さらにその会社のオフィスにまで勝手に入り込んでゲームして遊ぶとかなかなか無いよね。
ってなって今に至る。

機体の作成と衝突判定

まずは失敗したときの巻き添えシステム

開発話②：難しいという声を多く頂いていますが、最初に作ってみたらほぼこの難易度だったので後はこれを崩さないように周りを固めていきました。でも実は公開前の社内テストで一部理不尽な仕様に非難もあったので少し難易度は下げました。ちなみに一番最初にやったのは誘爆の実装。 #ExoplanetLander pic.twitter.com/5w368h1YUy
— Michiyasu Wada (@seyself) 2021年6月20日

衝突判定はいたってシンプルで、機体の線は全部 Sprite の矩形で構成されていて、その矩形それぞれに BoxCollider2D が設定されてる。

機体の動きは、いったんキーボードの入力をそのまま受け付けるようにしておいて
あとでキー入力をそのままWebSocketからの入力に置き換えた。

ステージの作成

最初はぷとしくんが描いたXDのラフが元
イスカンダルもナメックもめっちゃ簡単。
（今見るとぷとしくんの良心がとてもまぶしい・・・）

それを僕がイラレに持っていって、パスを調整したのがこれ悪意しか感じられない。。。

このイラレで編集したパスをSVGで保存して、それをUnityで読み込んで描画。 github.com

これを使って、こんな感じで矩形をパスに沿って繋いでいってる。
この地形の線も、機体同様に BoxCollider 付きの Sprite をひたすら繋いだものになってるので、機体が当たれば同様に OnTriggerEnter で衝突判定が受け取れる。 gist.github.com

遠隔での操作性

遠隔での操作性については割と早い段階からテストはしていて確証はあった。
前回の記事にも最初に少し触れていたけど、ぷとしくんは東京、僕は奈良なのでテストする時はZoom越しにテストしていて、特に操作に支障はなかったのであとは何で配信するか。
で、今回は配信の解像度や料金を比較してAgora.ioを使った。

ここではAgora.ioについての詳細は省くけど、tokenの発行等で参考にさせてもらったのはこちら

＜参考リンク＞

Agora.io はUnity用のSDKも配布してるけど、今回は配信もWeb版を使用している。

開発のコミュニケーションもSlackとZoomで、ゲームの基本操作までの実装は3日くらいで、あとはこれを触りながら他の仕様とか絵を決めていったので、開発期間のほとんどが複数人でこれをわいわいプレイしながらあーだこーだ言ってた気がする。

みんなでやったら楽しい

テストプレイ時はこんな感じで社内のみんなでわいわいやってました。 youtu.be

誰かと一緒にプレイするとまた楽しみ方が変わってくるので
仕事終わりにお酒を飲みながらでも、Zoomでご家族、ご友人と一緒に楽しんでいただければ幸いです。
そして着陸に成功したら、そのまま勢いで応募しちゃってください。
未知の領域に挑んでやろうという気概を持った方の応募お待ちしています！ bascule.co.jp

『Exoplanet Lander』公開しました。

2021-06-23T00:13:39+09:00

エンジニアのタケダ(@neko_300YEN)です。

先週『Exoplanet Lander』というWebコンテンツをリリースしました。

弊社オフィスにあるアーケードゲーム筐体のディスプレイに映し出された着陸機を操作して、目的地に着陸させるというゲームです。

ゲームが動いているのは実機なんですが、それを操作するのはネット越しの外から繋がっている人で、ZOOM的なもので現場の映像を見ながら繊細な操作を必要とするゲームができるのか？果たして面白いのか？

そんなことを実験的にやってみたというのがこのコンテンツです。

使った機材とか実装について書いていきます。

現代に蘇る『Lunar Lander』

『Exoplanet Lander』はオリジナルというわけではなく、ゲーム自体はそもそも1979年にリリースされた『Lunar Lander』というアーケードゲームがベースになっています。

LunarLanderの良いところを踏襲しつつ、現代らしくアップデートしてみよう！！

みたいな信条を持って下記の要素を付け足してみました。

マルチユーザー対応
リモート参加
リアルな場で起こるインタラクティブな演出

構成

今回メインで動いていたのは自分含めたエンジニア2人。

自分は配信まわり、Web実装全般、照明とか筐体まわり。

奈良に住んでいるもうひとりのエンジニアがサーバーの実装と筐体内のゲームをUnityで作りました。

アーケードゲーム筐体に映像を映す

筐体はこちら

https://www.amazon.co.jp/Arcade1Up-%E3%82%B9%E3%83%9A%E3%83%BC%E3%82%B9%E3%82%A4%E3%83%B3%E3%83%99%E3%83%BC%E3%83%80%E3%83%BC-SPACE-INVADERS-%E6%97%A5%E6%9C%AC%E4%BB%95%E6%A7%98%E9%9B%BB%E6%BA%90%E7%89%88%EF%BC%89/dp/B07KPHF3C4/ref=sr_1_4?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=arcade1up&qid=1624358543&sr=8-4www.amazon.co.jp

どうしてこれが3つもオフィスにあるのかは謎ですが、たぶん代表の私物だから壊れても大丈夫◎

キルアがバラシ屋ジョネスの心臓をくり抜いたかの如く、中から基盤をサッと抜き取ります。ｶｴｼﾃ…。

あとは下記のインバーターを取り付ければ完成！

HDMI入力できる17インチの液晶ディスプレイとなります。これを3つぶん。

https://store.shopping.yahoo.co.jp/truejp/a-B08C37NB29-20210521.htmlstore.shopping.yahoo.co.jp

中継カメラ

今回カメラふたつ使ってます。

ゲーム画面映像 : SIGMA fpをTytpe-CでPCと接続。UVCでAgoraに映像配信。
俯瞰映像 : Canon5Dの画面をHDMIで出力。キャプボで取り込んでOBSからYouTubeに配信。

Agoraの方はHDで配信しています。 レイテンシー200~300msというところでしょうか。

音質はだいぶ悪いです。デフォルトの状態だと恐らく人間の声の周波数ぐらいを境にローをごっそり削られます。ノイズ抑制の機能でしょうか？ AGCやANSもOFFの状態にしてもあまり変わらず。

Agora Web SDK API Reference - Video Call - Agora Documentation

"high_quality"で配信しているのですが全然音質良くない。何か実装が間違っているのかも。。。

また、約1ヶ月近くずっと中継し続けないといけないので、機材の痛みも気になるところです。

なので、カメラも代表の私物を利用させてもらっています◎

あとSIGMA fpはUVCモードで使っている時に電源が切れるとフォーカスがデフォルトの状態に戻ってしまいます。死ぬまで電源を落とさないように下記の外部電源を購入しました。

https://www.yodobashi.com/product-detail/100000001005177981/

照明

制御基盤 + 電源装置

別案件で作ったやつの流用ですが、制御基板はこんな感じ。これをゲーム筐体の中に入れています。

5Vのスイッチング電源と分電回路。 ArtNetでデータを受けてDMX信号とLEDを光らせるための基盤「Advatek社PixLitex16 mk2 」と、ArduinoとW5100モジュールが一緒になったMCUボード「KEYESTUDIO KS0304」を使っています。何故、制御基板を2つ使うことになったかというのは後述します。

Advatek社 PixLite16mk2

コレ便利。ArtNetで送った信号をLED16ポート+DMXout4ポートで出力できます。設定アプリも良くできているので、今回のようなサッサと光らせたい時に最適です。

5VフルカラーLEDで一般的なWS2811~WS2815とかSK9822とかいろんなチップに対応しています。

一点ダメな点としては、5ポート以上使うとだんだん出力電圧が下がってLEDがジカジカし始めます。 5Vだから？？

16ポートフルで使える方法あったら教えて下さい。

KEYESTUDIO KS0304

コレ便利。売り切れだけど。

https://www.amazon.co.jp/keyestudio-KEYESTUDIO-Arduino%E7%94%A8Ethernet-W5500%E3%82%A4%E3%83%BC%E3%82%B5%E3%83%8D%E3%83%83%E3%83%88%E9%96%8B%E7%99%BA%E3%83%9C%E3%83%BC%E3%83%89%EF%BC%88Poe%E3%81%AA%E3%81%97%EF%BC%89/dp/B079G4WDGW?ref_=ast_sto_dp

LEDについて

こちらも別案件で使った機材の余り物のSK6812のLEDテープ。 RGBWの4chです。

粒の中に黄色い部分があってそこがWhite。これがものすごく明るくなります。

なので、例えば赤色に光らせたいと思って、R=100%、G=0%、B=0%、W=33%とか、あるいはガンマ補正した値を入れてしまうと、白にうっすら赤みがあるかなぁ・・・くらいのほぼ白になります。

今回の様にゲーセンっぽい原色強めの雰囲気を作ろうとしても普通にRGBの各値からWを計算してしまうといい感じになりません。ゲームの中で機体がクラッシュした時などにフラッシュ的な演出も入れたかったので、RBG=100%に近づいた時にだけW=100%になるようなイレギュラーな制御をするようにしました。ソフト側で処理しても良かったのですが、今回はArtNetは3chのまま受けて、Arduinoの中でWを足してLEDに信号を流すような形にしました。

PixLite16で完結しなかったのはそのためです。

実際のコードはこちら

github.com

UV Lightについて

筐体の装飾を際立たせるために、DMX制御できるUVライトを2灯つけています。

www.gantom.com

12V動作でchogoriという防水コネクタがついています。

DMXチャンネルについては以下の通り。

1ch - Master Dimmer
2ch - Red
3ch - Green
4ch - Blue
5ch - Amber
6ch - Cool White
7ch - Lime
8ch - UV

ピンアサインはこちら。[自分用メモ]

照明制御PC

ユーザー参加時、機体のブースト時、クラッシュ時、ランディング成功時など、ユーザーのインタラクションに合わせて、LED + 警告灯 + UV Lightを良い感じに光らせます。

裏側はこんな感じだよ#ExoplanetLander pic.twitter.com/92vBpOrH1m
— 𝕟𝕖𝕜𝕠 𝟛𝟘𝟘𝕐𝔼ℕ (@neko_300YEN) 2021年6月18日

Unityから送出されたOSCをMaxで受けて、それをトリガーにVezerのタイムラインを再生し、アニメーションをLED制御アプリにOSCで送ってArtNetを送出しています。今回は大雑把にしかアニメーションしてないし、Vezerの方から直でArtNetを送っても良かったかも。

WinにもVezer的な細かいOSCシーケンス組める使い勝手の良いソフトはないでしょうか。。。

誰か知ってたら教えてほしいです。

imimot.com

求む、ヒーロー！！

弊社ではただいまエンジニアやデザイナーを強く募集しております！！

ゲームとか宇宙が好きな方、工作が好きな方、企画から考えて一気通貫で制作したい方。

ポディション問わず様々な方と出会えることを望んでおります。

ゲームをクリアすると応募フォーム出てくるので、是非そこから応募してください！！よろしくお願いいたします。

↓↓ チャレンジしてみてね ↓↓

Socket.ioでデバイスを繋いでアナログメタバースを作る

2021-06-10T11:13:14+09:00

エンジニアの桟(@katapad)です。

PC・スマホだけでなく、さまざまなデバイスとやりとりするにはSocket.ioやOSCのようなリアルタイムメッセージ通信が必要になる。いつもSocket.ioの書き方を忘れるので、2021年におけるSocket.ioの実装例をここに残しておく。

小さなサンプルを作るだけならつまらないので、なんらかの体験のプロトレベルのものを作ることにした。

TOIOをリモートから操作できるアバターにし、会社でマルバツクイズをして、不正解なら落とし穴が発動する。というアナログメタバースを会社ブログ用に作ってました。
映像では謎会社バスキュールにまつわるクイズをやってます。
ブログのリンクは後ほどぶらさげます#madewithunity #toio #gamedev pic.twitter.com/wCB91Hv9Dg
— 水たまりの水を飲んだことがある桟よしお (@katapad) 2021年6月10日

謎の会社であるバスキュールをアナログかつバーチャル訪問するサンプルを作る。落とし穴付きで。

バスキュールが謎会社すぎるとの声をたくさん聞くようになったので、気軽にバーチャル会社訪問でもしてくれたらなあという動機で作ってみる。

TOIOでバスキュール社内のリアル空間を動き回ってもらう

コロナ禍で注目されたどうぶつの森やフォートナイトといったメタバース。それをアナログに置き換えるとどうなるのか？というテーマを掲げ、ユーザーがリモートでアバター(TOIO)を動かせるようにし、バスキュール社内に設置したリアル空間を動き回ってもらう。

TOIOをアバターに

ブラウザでリモートからTOIOを操作して社内の空間を歩き回ってもらう

○✗クイズの落とし穴をObnizで作る

会社を知るには○✗クイズというのが鉄板(？)である。さらに鉄板を重ねるならば、不正解時には床を落とすことも必要だろう。ここではObnizでサーボモーターを制御し、TOIOを落とし穴にハメるギミックを作る。

このようにして、バスキュール社内をウロウロして社内の空気に触れながら、クイズで理解を深めてもらい、床から転落してもらうといった、誰も見たことのない体験をしてもらうことにした。

構成

ブラウザの画面も載せる(コントローラー、落とし穴とか)

Node.js
- Socket.ioサーバーをたてる
- toio.jsでTOIOを制御する
ブラウザ
- TOIOを操作する
- 落とし穴を操作する
Unity
- TOIOの位置情報を取得
- AR的に情報をオーバーレイする
デバイス
- Obnizでサーボを制御し、床を落とす
- ObnizはSocket.ioを介さずブラウザから直接操作することもできるが、最大接続数の制限があるのでサーバーで一括管理した。

といった連携をSocket.ioでやっている。

使ったもの

Socket.io v4
- Node.js
- JavaScript (Browser)
- Unity (Best HTTP/2)

なお、この試作には入っていないが、PythonでもSocket.io v4系が使えるライブラリがある。

そもそもSocket.ioで何ができるの？

主にWebSocketを用いてリアルタイムで双方向メッセージングをする技術。チャットなどが最も適当な例に当たる。

Socket.ioにはWebSocketのみでは実現できない便利機能がたくさんある。

room, namespace
- room: 同じ空間にいくつか部屋が分かれているイメージ
  - 空間に一斉にメッセージ可
  - 特定の部屋のみにメッセージ可
- namespace: 空間がそもそも違う
接続が切れても自動で再接続してくれる
メッセージが届くまでリトライしてくれる
volatileを使うと、送りすぎて不要になったメッセージを捨ててくれる

他、簡単に扱えるメッセージング技術としてはOSCもあるが、ブラウザではUDPが使えないためWebSocketで実装されたOSCのライブラリを使う必要がある。(WebRTCを使うとUDPが使えるが、PeerToPeer接続が面倒)

最近はブラウザでも気軽にUDPが使えるWebTransportなる技術が作られてる最中なので、NodeやUnityなどで使える日を気長に待とう。

サンプルコード

Node.js Server

全部書くと長くなるので、かいつまんで書いていく

// fastifyでサーバー作成
const fastify = require('fastify')({ logger: true })
fastify.register(require('fastify-cors'))
fastify.register(require('fastify-socket.io'), {
 allowEIO3: true, // Socket.io v3も対応させる
 cors: {
 origin: "*",
 methods: ["GET", "POST"],
 allowedHeaders: ["Origin, X-Requested-With, Content-Type, Accept"],
 }
})

const start = async () => {
 try {
 await fastify.listen(8080, '0.0.0.0')
 fastify.io.on('connect', socket => {
 // クライアントが接続時にクエリを投げるようにしたので、クエリにあわせてroomにjoinさせる
 switch (socket.handshake.query.client) {
 // ブラウザのTOIOコントローラー
 case 'controller':
 socket.join('controller')
 break
 // TOIOを制御する別のNode.jsプロセス
 case 'toio':
 socket.join('toio')
 break 
 //.....
 // というような部屋の割り振り記述が続く
 //.....
 }
 // ブラウザからTOIOを動かす指示がきたら、TOIOのroomに揮発メッセージで送る
 socket.on('move', data => {
 socket.to('toio').volatile.emit('toioMove', data)
 })

 // TOIOから自己位置の情報が来たら、ブラウザとUnityに揮発メッセージで送る
 socket.on('toio/position', data => {
 socket.to('controller').volatile.emit('toio/position', data)
 socket.to('unity').volatile.emit('toio/position', data)
 })
 })
 } catch (err) {
 fastify.log.error(err)
 process.exit(1)
 }
}
start()

JavaScript Client

以下はブラウザからTOIOを操作する画面のコードをかいつまんだもの。

ブラウザからのメッセージを受けて、実際にTOIOデバイスを操作するのはtoio.js を使っている。こちらもだいたい同じようなコードになる。

import { io } from 'socket.io-client'
const SOCKET_HOST = 'http://localhost:8080'

class SocketManager {
 connect() {
 // Socketの
 this.socket = io(SOCKET_HOST, { query: { client: 'controller' } })
 this.socket.connect()
 this.socket.on('connect', (socket) => {
 console.log('connected')
 })
 this.socket.on('toio/position', (data) => {
 // TOIOデバイスから来た自己位置を取得
 })
 }

 disconnect() {
 if (!this.socket) return
 this.socket.off()
 this.socket.disconnect()
 this.socket = null
 }

 // TOIOを動かすメッセージを送る。送り過ぎたら不要になるのでvolatileで送る。
 move(left, right, duration = 100, ottikiId = 0) {
 this.socket.volatile.emit('move', { left, right, duration })
 }
}

export default new SocketManager()

Unityのコード

Socket.ioを実装したライブラリがGithubにいくつも上がっているが、だいたいが開発停止している。

ただひとつ、Best HTTP/2 というアセットが Socket.io v3に対応している。

サーバーをv4にしても動作していた
namespace, room対応
型を渡すと On時にパースしてくれるようになった
volatile にも対応

// Connect
SocketOptions options = new SocketOptions();
options.AdditionalQueryParams = new PlatformSupport.Collections.ObjectModel.ObservableDictionary<string, string>();
options.AdditionalQueryParams.Add("client", "unity"); // Connect時にパラメータを渡せる
_manager = new SocketManager(new Uri("http://localhost:8080"), options);

// 受信
// 型を渡すとパースしてくれる
_manager.Socket.On<CubeInfo>("toio/position", (CubeInfo data) =>
{
 Debug.Log($"CubeInfo: {data.index}, {data.x}, {data.y}, {data.angle}");
});

// 送信
_manager.Socket.Emit('hoge')

アナログメタバースの知見

こんな小さな実験でもいくつかの知見が得られた。

アナログアバターに魂が乗る

アバターを撫でる

リモートユーザーから「リアルに現場にいるひとにからアバターを撫でられるとどうなるのか？」との問いがあった。撫でられると「ちょっとうれしい」らしい。逆に横から叩いてなぎ倒してみると、やはりつらい思いがあったらしい。実在する人物から叩かれると心理的な影響が大きいのかもしれない。ゲームのメタバースで同じことをしても、ここまでの感情になるのだろうか？

リアル側の人間がリアルのアバターを見ると、言葉は通わせないが意思疎通はできる小動物とみなせる

ボールを持ってきてもらう

アバターにボールを持ってこさせるという実験をした。リアル側の人間から見ると、きちんと意思の疎通ができる小動物と遊んでいる感覚があった。だがそれは人間でも犬でもない、別の生物。珍妙このうえない気持ちになる。

まとめ

Socket.ioはすごく簡単かつ、確実にメッセージを届けられるライブラリ。OSCと併用するともっと大量のメッセージのやりとりもできるようになる。

エンジニア募集中

バスキュールではコードを書くだけではなく、自分が信じるおもしろさを考え、実現するエンジニアを募集しています！フロントもバックエンドも募集中。

bascule.co.jp www.green-japan.com

で、もうすぐ別のおもしろコンテンツが出ます

まもなく、こんなモッククオリティではない、バスキュールらしいおもしろコンテンツがリリースされます。乞うご期待！

参考リンク

fokaさんのUnityとTOIOを連動させる記事
WindowsのUnityからBLEアプリ経由してtoioで遊ぶ - Qiita

Obnizでサーボ動かしてる記事
kintoneで反応速度ゲームを作ってみた

Detectronでおしゃ文字をつくる

2019-04-09T14:00:00+09:00

エンジニアの丸山（@maruware）です。

1年ほど前にデイリーポータルZで「現実化したフォント」がおしゃれなのでマスターしたい :: デイリーポータルZ という記事が掲載されていました。

こういうの（記事内より引用)

おしゃれですね。記事内ではこれを"おしゃ文字"と名付けていました。

一方でDeep Learning的な研究の進歩が著しい昨今、セマンティックセグメンテーション（タグ付きのマスクを検出するようなもの）の分野も盛んに研究されていて、Mask R-CNNなどすごい精度が上がってきています。

(Detectronより引用)

(matterport/Mask_RCNN より引用)

これがあればおしゃ文字が自動でつくれるんじゃないか、ということで

先日、NIHONBASHI SAKURA FESTIVALというイベントの中のPhoto Sessionという枠で「写真家が現地で記念撮影をしてくれて、それをおしゃ文字化する」という形で実施してみたので紹介します。

Detectronを使う

DetectronはfacebookがOSSとして公開しているセマンティックセグメンテーション用のライブラリです。あまりライブラリとしてのAPIやドキュメントは整備されていないためコードを追っていく必要があります。

（記事の最後におしゃ文字部分とまとめてjupyter notebookのサンプルのリンクを記載しました）

検出処理を実行するとバウンディングボックス、セグメント、クラス（物体のカテゴリ）が得られます。

モデルの一覧はMODEL_ZOO.mdにあり、学習済みのモデルデータも提供されています。今回はいくつか試した結果、End-to-End Faster & Mask R-CNN BaselinesのR-101-FPN 2x を使用しました。

検出処理の時間はGTX 1070やK80を積んだマシンで0.2〜0.3秒くらいでした。初回実行時のみ2〜3秒ほどかかります。

おしゃ文字をつくる

今回はイベントの趣旨から、主に記念撮影の被写体である人間を前景としてマスクのターゲットにします。

ざっくりした流れとしては

Detectronで検出
検出結果のリストから人間クラスのマスクのみ抽出
元画像からマスクで抜いた前景画像を作成
文字を描画したテキスト画像を作成
元画像、テキスト画像、前景画像と重ねて合成

というものになります。

描画まわりはpythonのImageMagick bindingライブラリのwandを使用しました。最初はPillowを使っていましたが、カーニングを調整することができないようなのでwandに移行しました。

アプリケーションとして実装する上で得られたTipsを以下で紹介していきます。

Tips 1. 後ろの方にいる被写体ではない人を除外したい

例えばこちらのような開けた場所では後ろの方に小さく人が写ります。文字の上に重なるとレイヤー感がおかしく見え、不具合のように見えます。

この問題を解決するために、

面積で閾値処理: 1番大きく検出されたバウンディングボックスの面積との比率で判定
Y座標で閾値処理: バウンディングボックスの下端を比較して判定
深度推定をして閾値処理: 別途、2Dによる深度推定を行って判定

といった手法を検討しました。

1は子供連れの方で誤る可能性、3は試したもののまだ現実的ではなさそう、ということで2を採用しました。

ただし、幼児を抱いた状態で幼児が除外される、などが起きる懸念があります。

Tips 2. 被写体が持つ手荷物もいっしょに抜きたい

いい例がなかったのでフリー素材からですが（つまりレアケースとも言えそうですが）、被写体がかばんを持っていてその上に文字が重なると不具合のように見えます。

Detectron（正しくはデータセットのcoco）ではハンドバッグも対象クラスになっているので、「被写体と見なした人のセグメントと交差するハンドバッグのセグメントはマスクに含む」と判定をすることで対応しました。

今回の場合は事前に手荷物を預かるようなオペレーションもできましたが、一応かばんを持っていても抜けるように対応しました。

Tips 3. 雨が降って傘を持っている可能性がある。傘も抜きたい。

今回は屋外で撮影が行われるため、当日に雨が降り傘をさしている可能性があります。傘もかばんと同様に人と同じレイヤーに当たるので抜き出します。

幸い、傘もDetectronの対象クラスなので検出されます。

ただ、

傘は人をくり抜いたような形のセグメントになり、ときどき交差しないことがある
後ろの人の傘が被写体の人と交差することがある

ということでかばんと同様の交差判定では対応できませんでした。

そこで、基本的には傘は頭を覆うように写るため、「バウンディングボックス内に被写体の上端を含む傘」を対象とするようにしました。

ヒューリスティックであまりイケてないですが、雨天はイレギュラーということでお茶を濁すことにしました。

その他

文字組みについて

デザイナーと相談ながら調整した結果

文字の30%が人に重なっているくらいがちょうどよい
文字のサイズは基本は画像の横幅いっぱいに大きく表示するのが良い
1〜2文字の場合は画面幅合わせだと大きすぎるので調整
画として美しい文字数は3 or 4文字。6文字までがきれいに見える限界。

という結論になりました。

結果

マスクを人力で用意するのはしんどいので定量的な評価はできておらず、目視での評価になりますが、概ね違和感なくおしゃ文字することができました。

ただ、いくつか課題が出ました。

2列に並んで撮影するとTips 1で行った処理で後列が除外される

足まで写っていないときにセグメントが上半身のみになってしまい、除外されてしまいました。2列に並ぶのは記念写真ではあるあるだと思うのでもうちょっと工夫が必要そうです。

幼児を抱いているとTips 1で行った処理で幼児が除外される

予想通り、幼児はTips 1の処理で除外されてしまいました。予想外に幼児を連れた方が多く参加されてて申し訳ない気持ちになりました。

また、これは想定外だったのですが、幼児を前で抱えると誤検出が増えることがわかりました。

大人の足が幼児と同一人物として検出されています。他にもこういった例が見られました。cocoの学習データにこういったサンプルが少なさそうなのでこういった例を拾うのはむずかしそうです。

幼児対策として

幼児は横に抱いてもらう
大人は上半身のみで撮影する

とカットで逃げることで対処してもらいました。

写真集

以下、写真集です。

暗くても抜ける（すごい）

おわりに

テクノロジーの無駄遣いという感もありますが、AI的なものをエンターテイメント活用できて面白かったです。記念撮影という形で試せたことも、

写真のコントロールがこちらでできる
枚数も少ない（GPUインスタンスいっぱい立てるとお金がかかる）
1組に複数回の撮影ができるため、失敗してる写真があってもおもしろくらいでごまかせる

といった点でよかったです。

まだ人力でPhotoshopなどで抜くのに及ばない課題はいろいろありますが、撮ったら待たずにすぐに見れるのは体験として良いし連写に対応できるのも長所かなと思います。

そのうちプリクラに載るかもしれないですね。

今回ご協力いただいた写真家の五十嵐絢也さんにはむずかしい要求にも快く応えていただき良いおしゃ文字写真をつくることができました。

jupyter notebook にコードのサンプルもアップしたのでよかったら見てみてください。

AfterEffectsをサーバーサイドで使って動的に動画を生成する

2017-09-12T10:00:00+09:00

エンジニアの丸山（@maruware）です。
7月末に開催されたWRCフィンランド戦でToyota Gazoo RacingさんとEchoCamというコンテンツをやっていました。
そのときに、AfterEffectsによる動的動画生成をしていたのですが、あんまり日本語の記事がなさそうなので多少参考になるかなということで今回はそちらを紹介したいと思います。

EchoCamとは

↑の紹介動画の通り、
ユーザー（観戦者）が撮影した写真の時刻とドライブレコーダーの時刻を同期して、動画を生成、ユーザーに届ける
というものです。

図で書くとこんな感じ。
その中の動画生成にAfterEffectsを使っています。紹介動画の40秒あたりからが生成される動画です。

AfterEffectsを使った動的動画生成

①aerenderでAfterEffects自動化

AfterEffectsにはCLIから実行できるようにaerenderという実行ファイルが含まれています。
詳しくは↓のAdobe公式ガイドをご覧ください。

helpx.adobe.com

②AfterEffects内のアセットの動的差し替え

ユーザーの投稿それぞれに動画を生成したいので、画像・動画・テキストなどを差し替えます。
以下の記事が英語ですが参考になるかと思います。

www.themarketingtechnologist.co

基本的には

画像や動画はフッテージとして配置してファイルを差し替えればOK
テキストはJavaScriptのファイルを参照してExpressionで処理すればOK

です。
外部ファイルは$.evalFile(path)としてevalするしかないようなので
以下のようなjsファイルを実装しておくような形になります。

var model = {
 "baseTime": 1496984724659,
 "left": 100,
 "name": "Taro",
 "right": 3740,
 "ssName": "ss2",
 "top": 320,
 "window": {
 "h": 1080,
 "w": 1920
 }
};

ここで1つ面倒なことがあって、$.evalFile(path)で参照できるパスは絶対パスじゃないといけません。
開発時にgitで管理するときのポータビリティ的にも運用時の配置的にも使いづらいです。

③nexrenderでポータブル化

nexrenderというありがたいライブラリがあります。
github.com

Node.js製です。
今回は使っていませんがサーバーとして起動する機能もあるようで多機能です。
（ちょろっとContributeしたりもしています）

nexrenderを使うことで、

AEのプロジェクトファイルとそのアセットをセットにして宣言的に定義できる（フォーマット化されている）
アセットのソースをリモートのURLまたはローカルのパスで指定できる
②で問題だったjsファイルの絶対パス問題が解決できる

というよさがあります。
AEのプロジェクトファイルはaepx（XMLファイル形式）にする必要があります。

jsファイルの絶対パス問題はけっこうな力技で解決していて、

aepx内にバイナリで保存されているExpressionをBufferでデコード
正規表現でパス文字列を検索して置換する
再度バイナリ化してaepx内に設定

ということをしています。
このあたりの処理が少しゆるいようで

通常のjsの式がパスとして解釈されることがある（カッコの位置がけっこう影響する）
Expression内に日本語などマルチバイト文字を含んでいると壊れる

という不具合があり、注意が必要です。
せっかくバグ踏んだので時間があるときにパッチかこうかなと思います。

④いろいろ動かす

Expression内で動的な値を読み込むことができるので、
Expressionでできることは動的にすることができます。

例えば、EchoCamでは"位置"のExpressionに

$.evalFile('/your-project-path/model.js');
var dx = (model.left + (model.window.w / 2.0));
var dy = (model.top + (model.window.h / 2.0));

easeIn(time, 9.0, 10.0, [dx / 2, dy / 2], [960, 540])

と設定、またスケールも対応したExpressionを設定して
「特定の位置に向かってズーム」をしています。

また、時刻のカウンタを

$.evalFile('/your-project-path/model.js');
var baseTime = model.baseTime;
var frameCount = timeToFrames();
var msec = frameCount * 10 * 100 / 99;

var curr = new Date(baseTime + msec);

var h = ((curr.getUTCHours() + 3) % 24).toString();
var m = ('00' + curr.getMinutes()).slice(-2);
var s = ('00' + curr.getSeconds()).slice(-2);
var ms = ('000' + curr.getMilliseconds()).slice(-3);

h + ':' + m + "'" + s + '"' + ms;

のようにして回したりしています。

おわりに

動的動画生成にはよくffmpeg+ImageMagickを使いますが、そちらと比較して

凝った演出がやりやすい
デザイナーや映像クリエイターと分業しやすい

といったメリットがあります。
一方、デメリットして

処理時間がかかる（GPUそこそこのマシンで30秒の動画生成に2分くらいかかったりする）
AEのライセンスが必要
WindowsまたはMacをレンダリングサーバーとして用意する必要

といったあたりがあります。

EchoCamのようにユーザー数が限られていたり、札束をぶちこめるようなときには選択肢の1つとして検討してみてはいかがでしょうか。

GearVR用Android端末の初期設定を自動化した話

2017-07-03T11:20:14+09:00

Androidのセットアップ、実は自動化できます。

VRエンジニアの桟(@katapad )です。
以前、GearVRを使った案件で、数十台の端末セットアップを自動化しました。Googleアカウントなどのパスワードをちまちま入力するの、めんどくさいですよね。iPhoneのようにバックアップからリストアできたらよかったのですが、うまくいかずにガリッとやっちゃいました。

↑自動でGoogleアカウントを設定している様子

詳しい実装を書くとめちゃくちゃに長くなるので、ここでは要点だけを書きますね。

Android SDKのadb shell機能を使うと、わりとやりたい放題できる

shellが用意されており、PC側からそれなりに操作できます。

キーボードイベントを発生させる
タップ・スワイプイベントを発生させる
- ロングタップもOK
各種設定画面を開く
画面のキャプチャを撮る

これを「設定画面を開いて」-「チェックマークあたりをタップして」という具合に、チマチマと設定していきます。

さらにAndroid NDK (Native Development Kit)を入れていじくると、Androidの画面をストリームで取得したりができるようです。

できたこと: アカウント・パスワード入力自動化、設定自動化

Googleアカウントの設定、wifiパスワード入力などのテキスト入力
設定画面での設定を自動化
- ディスプレイの自動オフを10分にする
- GearVRサービスで開発者モードをオンにする
- など
上部ドロワーメニュー内の設定のOn/Off操作
↑ Androidのスクショ撮ってPCに渡してOpenCVでテンプレートマッチング→どこタップするか判定→OnにしたりOffにしたりする

Googleアカウント設定の例

けっこう泥臭くやります。

#!/usr/bin/env zsh
# キーが数字だとよくわからんので変数にいれる
KEY_HOME=3
KEY_TAB=61
KEY_ENTER=66
KEY_DOWN=20
KEY_EVENT="shell input keyevent "
PRESS_KEY_ENTER=$KEY_EVENT$KEY_ENTER
PRESS_KEY_TAB=$KEY_EVENT$KEY_TAB
PRESS_KEY_DOWN=$KEY_EVENT$KEY_DOWN

# USBで繋がってる端末ID
DEVICE=$1
S="-s $DEVICE"

ID="your_google_account"
PW="your_password"


# Google アカウント設定画面開く
adb $S shell am start -a android.settings.SYNC_SETTINGS
sleep 1.5

## [アカウント追加] - [追加]を選択
adb $S $KEY_EVENT $KEY_DOWN $KEY_DOWN $KEY_ENTER
sleep 1.5

echo "アカウント追加 選択するもの画面"
# 6回下キーを押してエンターを押す
_TMP_KEY=" "
for i in `seq 0 5`
do
 _TMP_KEY="$_TMP_KEY $KEY_DOWN"
done
echo "$KEY_EVENT $_TMP_KEY $KEY_ENTER"
adb $S $KEY_EVENT $_TMP_KEY $KEY_ENTER
sleep 3

echo "アカウント入力画面"
_TMP_KEY=" "
# タブを二回をして入力フォームを選択
for i in `seq 0 2`
do
 _TMP_KEY="$_TMP_KEY $PRESS_KEY_TAB"
done
adb $S $KEY_EVENT $_TMP_KEY
sleep 0.3

# Googleアカウント名を入力
adb $S shell input text $ID
sleep 0.3
adb $S $PRESS_KEY_ENTER
adb $S $PRESS_KEY_ENTER

sleep 3

## パスワード入力画面
adb $S shell input text $PW
adb $S $PRESS_KEY_ENTER

sleep 1

echo "終了"

できなかった

Bluetoothのオフ
- https://developer.android.com/reference/android/bluetooth/BluetoothAdapter.html?hl=ja
- BluetoothはOnにしかできない
- ならばAndroidアプリを作ってjava側からオフにしようとしたが、そもそもオフにするAPIがなかった。

最終的にこれだけ自動化できた

最初に開発者モードにするところだけ手動で設定する

開発者モードON
USBデバッグON

以下は自動化できた。

アカウント設定
- Googleアカウント設定
- Oculusアカウント設定
もろもろ端末設定
- wifi設定
- いろいろオフ
  - Bluetooth オフ
  - 端末同期オフ
  - NFC オフ
- 通知をミュートモードにする
- 開発者モード
- 画面スリープにするまで10分
インストール
- つくったGearVRアプリのapk
GearVR 設定
- GearVR開発者モードにする
  - [アプリケーション管理] - [GearVR Service] - [ストレージを管理] - [VR Service Ver]を7回タップ

最終的には費用対効果を考えよう

Androidを2-3台しか設定しないのであれば手動設定のほうが早いですよね。

今回は数十台だったので、手作業ではミスが発生しがちなのと、自分のモチベーションが底をつくため自動化を選びました。

参考

ADB Shell メモ - Qiita
- できることがザッと書いてある
Android Debug Bridge | Android Studio
- 公式doc
パソコンからAndroid端末を操作する時に使えるコマンド(ADBなど) | AndMem
- コマンド解説
【デバッグ接続】タッチやキー入力などの操作を自動化する「input」コマンド | あんどろいどスマート
- 具体的なinputコマンドの書きかた
Android adbを使いこなす | TechBooster
- PCと接続している端末の取得のしかた

流星放送局の流星演出と映像合成

2017-05-15T10:00:00+09:00

こんにちは、エンジニアの岩渕（@buccchi）です。

去年12月のふたご座流星群ピークの夜に放送された「流星放送局」では流星を感知できるシステム“Meteor Broadcaster”からの通知を受けて生放送画面にみんなの願い事をリアルタイムに合成して降らせるということをやってました。今回はこの演出部分について説明します。

構成

番組中はドラマとライブ（アーティストライブ、トーク）がありました。それぞれに対応するため2種類の構成を用意しました。

ドラマ時の機材構成

ドラマは5分程度のものが5話ありました。
事前に画角とカットが切り替わるタイミングがわかっているので、各カットに応じたパースや大きさで流星を降らせることができる様に、1話ごとに決めカットを3つと、汎用的に使えるヒキ・ヨリ・ミドルのカットを3つ、それと非表示用のカットを1つの計7カットを用意してこれをドラマのタイムコードに合わせて切り替えていました。
最終的なカット数は530超。
また、参加者数や流星感知時のテロップ表示はAnimateで実装し、QUMO2というシステムで合成していました。

BSジャパン（六本木）機材構成

ライブ時の機材構成

生放送用のカメラ3台にUnityマシン3台を割り当てていました。

河口湖中継車機材構成

合成方法

流星演出はUnityで実装。ブルーム発光しているのでこれを加算合成をすれば綺麗に表示できると思っていたのですが、加算合成はTV放送ではなかなか難しいらしく断念、代わりにフィルキー合成という方法で行いました。
Unityの画面を単純にフィル映像として使うとどうしても半透明部分が黒ずんでしまうので、いくつかのパターンを試して、フィル映像は白ベタでキー映像をUnityで生成するという方法を選択しました。

Unityの映像をBlackmagicへ送る

Unityの映像は SyphonUnityPluginというのとBlack Syphonというのを使ってBlackmagicへ送っていました。
ただし

描画タイミングの同期が取れていないのかちょっとカクつく。
Unity側でカメラを切り替えると設定が外れる。
再設定後に同期がとれるまでノイズが流れる。

という問題もあったので今後同じ様なことをやる場合には別の方法を探る必要があそうです。

流星演出

ライブのカメラ位置や画角が確定するのは放送当日で、そこから最終調整をしなければいけない状況だったため、落下範囲や速度をすばやく設定できる様にエディタ拡張を用意しておきました。

流星落下アニメーション

文字はDOTweenで1文字ずつバラバラに制御。
消滅時のパーティクルは、文字の最終ノードにエミッターを設定。
地面を照らす光はライトだと重いので板ポリで表現。
文字間を繋ぐ線はLineだと細い場合に潰れてしまうので、板ポリに左右に余白をもたせたテクスチャで。

流星の落下範囲やもろもろの設定

以下のパラメータをエディタ上で変更できるようにしていました。

落下エリア
文字が発生する距離
文字が静止する距離（画面内のいい感じの高さで静止させて文字が読めるように）
文字が静止後に滑る距離（静止後もゆっくりスクロールし続けることで長文も読めるように）
文字が静止後に滑る時間
進入角度
願いの文字サイズ
着地時の光のサイズ
衝突時のエフェクトの有無（落下地点が画面外の場合に処理を省略するため）

落下地点を完全なランダムにしてしまうと流星が重なりすぎて読めなくなったりするので Random.InitState(int seed) を適当なタイミングで叩いて各カットの初回の落下位置を固定していました。
落下範囲を極端に狭めることで「ダルマの頭に落とす」みたいなことも可能になってます。

パースマッチング

パースはBlender上でBLAMというアドオンを使って合わせていました。
ただしBlenderは右手座標系で水平画角、Unityは左手座標系で垂直画角という違いがあるのでこれを変換する必要があります。

Blender画角（水平）をUnity画角（垂直）に変換

public Camera cam;
public float blenderFov = 62.4f; // Blender側の視野角

private void ConvertFovFromBlender(){
 float fov = 2f * Mathf.Atan(Mathf.Tan(blenderFov * Mathf.Deg2Rad / 2f) / cam.aspect);
 cam.fieldOfView = fov * Mathf.Rad2Deg;
}

ドラマ決めカット一覧

ドラマ用に最終的に用意した決めカットは15種類。これ以外のカットは汎用カットからシーンに合ったものを割り当てていました。

スマホ
ミュージシャンの妹
オウム返し
あれから
風景が変わる

おわりに

流星という自然現象をキーにしているため、これだけ用意しても使われることのないカットが多くを占めてしまうのですが、それでも新しい体験を作るためにやる価値は十分あったと思ってます。

Locustを利用したMQTT over WebSocketの性能テスト

2017-05-09T13:59:20+09:00

はじめまして。バックエンドエンジニアの会津（@ido）です。

2016年に携わった案件「流星放送局」ではサイトを訪問している大量ユーザーにプッシュ通知を行う必要がありました。

Websocketサーバ実装といえばSocket.IOなどがありますが、昨今の流行りに乗って自前で開発はせずサーバレスでフルマネージメントなAWS IoTのMQTT over WebSocketを利用して実装しました。

疎通まではコンソールからAWS IoTの設定するだけの簡単なお仕事なのですが、大量のWebsocket接続へのプッシュ通知がどの程度遅延するかを計測するというなかなか骨の折れそうな性能テストをしなければなりません。ただ流石にこんなニッチな性能テストができるサービスは存在していなかったので、Locustを利用してテストを行いました。

なぜLocustなのか

普段Pythonばかり書いているのでテストシナリオはPythonで書きたい、間違ってもXMLなんて書きたくない。
接続するWebsocketクライアント数を手軽に変更したい、スケーラビリティ大事。

以上の2点からLocustを選びました。

ちなみにLocustは日本語訳でイナゴです。イナゴを大量発生させて操れるなんて気分はモーセですね。

テストを行う

ANSIBLE + Packerを使ってLocustのマスター・スレーブ2種類のAMI作成
TerraformでLocustクラスターを構築（今回スレーブは最大200インスタンス起動）
マスターのWebGUIから接続数を設定して実行
ローカルPCまたはAWS IoTコンソールからMQTT BrokerにPublish
マスターのWebGUIで性能確認

大まかに書くと以上の手順でテストを行いますが、構築などの詳細を書くと膨大になるため割愛。（リクエストあれば書くかも）テストシナリオとテストPublishを行うコードは以下のとおりです。

locustfile.py

# -*- coding: utf-8 -*-
from __future__ import division, print_function, absolute_import

import json
import time
import uuid

from locust import TaskSet, task, Locust
from locust.events import request_success

from AWSIoTPythonSDK.MQTTLib import AWSIoTMQTTClient

CA_FILE_PATH = './rootCA.pem'
QoS = 1
AWS_ACCESS_KEY_ID = 'XXXXXXXXX'
AWS_SECRET_ACCESS_KEY = 'XXXXXXXXX'
ENDPOINT = 'XXXXXXXXXX.iot.ap-northeast-1.amazonaws.com'
TOPIC = '/ryusei/notification'


def on_recive(client, userdata, message):
 payload = json.loads(message.payload)
 elapsed = time.time() - payload['started_at']
 request_success.fire(
 request_type='Recive Notification',
 name=message.topic,
 response_time=elapsed,
 response_length=len(message.payload),
 )


def get_client():
 client = AWSIoTMQTTClient(clientID=uuid.uudi4().hex,
 useWebsocket=True)
 client.configureIAMCredentials(AWSAccessKeyID=AWS_ACCESS_KEY_ID,
 AWSSecretAccessKey=AWS_SECRET_ACCESS_KEY)
 client.configureCredentials(CAFilePath=CA_FILE_PATH)
 client.configureEndpoint(hostName=ENDPOINT,
 portNumber=443)
 client.configureOfflinePublishQueueing(-1)
 client.configureDrainingFrequency(2)
 client.configureConnectDisconnectTimeout(10)
 client.configureMQTTOperationTimeout(60)
 return client


class AWSIoTTaskSet(TaskSet):
 bufsize = 5000

 def on_start(self):
 client = get_client()
 client.connect()
 client.subscribe(TOPIC, QoS, on_recive)

 while True:
 time.sleep(1)


class AWSIoTUser(Locust):
 task_set = AWSIoTTaskSet
 min_wait = 100
 max_wait = 100

publish.py

# -*- coding: utf-8 -*-
from __future__ import division, print_function, absolute_import

import json
import time
import uuid

from AWSIoTPythonSDK.MQTTLib import AWSIoTMQTTClient

CA_FILE_PATH = './rootCA.pem'
QoS = 1
AWS_ACCESS_KEY_ID = 'XXXXXXXXX'
AWS_SECRET_ACCESS_KEY = 'XXXXXXXXX'
ENDPOINT = 'XXXXXXXXXX.iot.ap-northeast-1.amazonaws.com'
TOPIC = '/ryusei/notification'



def get_client():
 client = AWSIoTMQTTClient(clientID=uuid.uudi4().hex,
 useWebsocket=True)
 client.configureIAMCredentials(AWSAccessKeyID=AWS_ACCESS_KEY_ID,
 AWSSecretAccessKey=AWS_SECRET_ACCESS_KEY)
 client.configureCredentials(CAFilePath=CA_FILE_PATH)
 client.configureEndpoint(hostName=ENDPOINT,
 portNumber=443)
 client.configureOfflinePublishQueueing(-1)
 client.configureDrainingFrequency(2)
 client.configureConnectDisconnectTimeout(10)
 client.configureMQTTOperationTimeout(60)
 return client

def main():
 client = get_client()
 client.connect()
 client.publish(TOPIC, json.dumps({'started_at': time.time()}), 1)

if __name__ == "__main__":
 main()

おわりに

Locustでの性能テストを繰り返すことでAWS IoTの特性を知ることができ、TVの放送本番までには満足できる結果を得られるまでチューニングを行いました。みなさんもLocustを使って強力かつ楽チンな性能テストライフをはじめてはいかがでしょうか。

マッチムーVJ

2017-04-26T19:55:13+09:00

こんにちわ。エンジニアのビジュアル担当、渡邊(@_nabe)です。

今回はバスキュールとは全く関係ないんですが、趣味で北千住デザインという名義でthreejsを使ってブラウザVJをやっていまして、今回はそのVJネタのひとつを説明します。

やったこと

ARみたく、実写と動的なCGを組み合わせてVJをしたいと考えた（こういう合成をマッチムーブというらしい）。ただARは現状では精度が低かったり、リアルタイムが前提の表現なので、映像作品とみたときイマイチな場合がある。そこで、実写映像をあらかじめ撮影して別のソフトで3Dトラッキングし、それにWebGLで描画された音に反応するアニメーションをオーバーレイさせるという方法をとってみた。静的な映像と動的な映像のハイブリットといった感じ。

こんな感じで、背景はふつうのリニアな映像、手前の動いている物体は、音に合わせてリアルタイムに変形している。

どなたかが録画してくれていた動画↓

キマイラ #BRDG7 @ 渋谷WWW X

DE DE MOUSE🐭 x HEXPIEXLS with 北千住デザイン✨

これヤバすぎて🐼顔が凄くにやけた☺️☺️☺️ pic.twitter.com/775uMeOcBh
— KG (@keiji_307) 2016年9月18日

トラッキングのやり方

実写のトラッキングにはCinema4d Studioを使った（会社にあったから）。やり方はこの辺を見ればわかる。トラッキングができたら、Cinema4DはPythonを使える機能があるので、それを使い、毎フレーム、カメラの座標・回転（クォータニオン）・FOVをjsonに書き出す。ただcinema4dとthreejsは座標系が違う（左手・右手）ので書き出す際注意が必要。

Cinema4dのPythonのコードはこんな感じ https://gist.github.com/kitasenjudesign/d739c6123e0b55bc77445d2db6f608d1

書き出したJSONはこんな感じ

 "frames": [
 {
 "fov": 32.70611613573759, 
 "frame": 0, 
 "q": [
 0.01175325347189373, 
 0.9667209890999054, 
 0.04514531549377907, 
 -0.25154381478281923
 ], 
 "x": -141.4472256273544, 
 "y": 68.24724022421263, 
 "z": -198.63611330979802
 },...

これをthreejsに持っていき、映像の再生時間と合わせて、毎フレーム、PerspectiveCameraのパラメータを更新すれば良い。

※AfterEffectsでも同様のことができるようです。他の3Dソフトでもできると思う。 https://medium.com/@Jam3/mtchmv-a54624f6232#.jwdrxnan1

Video再生

WebGLのキャンバスの背景を透明にして下にVideoタグを敷くという方法もあるが、今回はポストプロセスもかけたかったのでVideoをCanvasにキャプチャしてthreejsの中の板ポリに貼り付けた。（やり方はググれば出てくる）その際、板ポリはカメラに関係なくずっと正面を向いていてほしい。毎フレーム、板ポリをLookAtするという手段もあるが、めんどいので、以下のようにシェーダーを書いた。

geo = new THREE.PlaneBufferGeometry(2, 2, 1, 1);
mat = new THREE.ShaderMaterial({
 vertexShader: _vertexShader,
 fragmentShader: _fragmentShader,
 uniforms: {
 texture: { type: 't', value: _texture } 
 }
});
mesh = new THREE.Mesh(geo,mat);

varying vec2 vUv;
void main()
{
 vUv = uv;
 vec4 hoge = vec4(position, 1.0);//マトリックス計算しない
 hoge.z = 1.0;//最背面のz=1に。
 gl_Position = hoge;
}

uniform sampler2D texture;
varying vec2 vUv; 
void main()
{
 //テクスチャを書き出してるだけ
 gl_FragColor = texture2D(texture, vUv);
}

影

影もつけたい。ShadowMaterialっていうのを使うと透明なPlaneに影だけ落としてくれる。 http://stackoverflow.com/questions/35710130/shadow-catcher-in-three-js-shadow-on-transparent-material

クリッピング

地面から飛び出してくるような演出もしたい。3Dオブジェクトをクリッピングせねばならない。シェーダーを自分で書いても良い（たとえばy<0ならdiscardするとか）。けれど、めんどうなので、これもthreejsのクリッピング機能を使う。 https://threejs.org/examples/?q=clipp#webgl_clipping

おわりに

世にある大概のマッチムーブは実写とCGの合成が違和感ないように、なじむ方向に作るのだけれど、今回のように実写としょぼいCGを組み合わせてみたら、それはそれで違和感が生まれて面白い。3Dトラッキングの精度はそれなりに必要だと思うけど。

今後もよいネタあれば、発信していきます。

あと今エンジニアを募集してますーー。 www.bascule.co.jp

インスタレーションを支えるバックエンドの話

2017-04-11T10:00:00+09:00

こんにちは、丸山です。
12月に開催されていたCOFFEE MOMENT ENSEMBLE（以下、CME）や願いの森というインスタレーションイベントでバックエンドを担当しました。

CME動画

願いの森動画

この記事では『インスタレーションを支えるバックエンドの話』というテーマでCMEを具体例としてお話します。

構成

全体の構成は以下のようになっています。

スマホアプリ→Nestle内のAppサーバー→CME Appサーバー→店舗内機器
という流れで"コーヒーを淹れた"というイベントが伝播されます。
CME Appサーバー以降がバスキュールの担当範囲になります。

Appサーバー

Appサーバーは主にWeb APIとWebSocketを実装しています。

“コーヒーを淹れた"というアクションに対してイベント発火とメインビジョン用の統計処理を行っています。統計は都道府県別ランキング、時間帯別の小計、人気のメニューなどがあります。

インフラは素朴にALB, EC2, RDS, ElastiCache(Redis),S3という構成で、
Webアプリは主にRailsを、WebSocketまわりでNode.jsを使っています。

クリエイティブ系におけるRails最高

私は負荷、外部要因などを気にしなくていい案件ではデフォルトでRailsを使っています。
RailsというとWebサービスで使われているイメージがありますが、インスタレーションを含めクリエイティブ系においてRails（と周辺gem）は最高に使いやすくて、

クリエイティブ系は基本的にアプリを使い捨てていくのでセットアップ機会が多い。Railsはセットアップ時間が短くて最高。
画像や動画などのメディアを扱うことが多く、基本的にS3にあげる。carrierwave最高。
ユーザー用に画像や動画の動的生成をよくするのでジョブキューをよく使う。sidekiqよくできてて最高。
管理画面が基本的に必要。これも使い捨てなので手間をかけたくない。ActiveAdmin楽さとカスタマイズ性のバランスが最高。
いつもJSON APIを組むがフロントエンドのメンバー用にドキュメントが必要。これも使い捨てなので手間をかけたくない。grape-swagger API実装がそのままドキュメントにつながって楽だしドキュメント更新忘れがち問題も起きにくくて最高。

ということで、最高です。

クリエイティブ系は常に新しいことをやっていきたいという意識なのでそこに集中したくて
それ以外はとにかく楽をしたい、というところでRailsと周辺gemは熟れてるし強いなと感じます。

現場ハブ

CME Appサーバーと店舗内の各機器をつなぐ、中継であり中央指令的なPCを現場ハブと呼んでいます。現場ハブはNode.jsで実装しています。

Appサーバーに対してはWebSocketのクライアントとして、店舗内の各機器に対しては適したプロトコルに応じてWebSocket、OSC、UDPで通信しています。
現場ハブの特徴としてFSMをベースに実装している点があります。
イベント系ではよくFSMを使っているのですが、割とおすすめなのでここではFSMに絞って紹介します。

状態遷移とイベント発火の多いインスタレーションにFSM

FSMでググると空飛ぶスパゲッティ・モンスター教がトップに出てきますが、そちらではなく有限オートマトンの方です。 wikipediaにはいろいろ小難しいことが書いてありますがコードを見た方が早いかと思います。
Node.jsにもいろいろFSMの実装がありますがMachina.jsが個人的には好みでよく使っています。
サイトに載ってる車の例のように、FSMを使うと状態遷移と各状態において操作をしたときの処理をキレイに分けることができます。

今回の案件では

default - 定常状態
dispStats - 統計表示状態
performing - 演奏状態
suspend - 緊急時の中断状態

という4つの状態を定義しました。
CMEでは例えば

演奏開始命令がサーバーから飛んできたときに
- 定常状態なら演奏を開始する
- 統計表示状態なら表示が終わるまで待機して終わってから演奏開始
- 演奏状態なら何かがおかしいのでエラーログに記録する（演奏は待ち行列で管理しているのでキュー処理が間違っているなど）
- 中断状態なら中断が解除されるまで待機
ピタゴラ装置から演奏完了イベントが飛んできたときに
- 定常状態なら何かがおかしいのでエラーログに記録する（演奏をタイムアウトして定常状態に強制的に戻したあとに飛んできたなど）
- 統計表示状態も同上
- 演奏状態なら状態を定常状態に戻す
- 中断状態なら無視する

といったようなことをしていて、これをif文で書いていくと死ねます。（↑では2つの処理を例にしているけど、これが5〜20個くらいある）
インスタレーション系だとだいたいこんな感じになるんじゃないかと思います。

FSMでこれを記述するとif文で書くときと構造が逆になる（状態をインターフェース、各状態をその実装クラス、各処理がメソッドになってポリモーフィズムするような感じ）ため、すっきり書けるし分岐し忘れのようなことも防ぐことができます。

分岐し忘れについてはMachina.jsだと

{
 //...
 performing: {
 '*': function (eventName) {
 logger.error('nohandler', eventName, this.state);
 }
 },
 //...
}

のようにワイルドカードで処理を定義しておくと未実装の場合のハンドリングをすることもできます。

まとめ

インスタレーションを支えるバックエンドでは、新しい体験づくりを支えるスピード感と安定感を心がけています。
バスキュールではインスタレーションイベントに力を入れており、フロントエンド、バックエンド、デバイスなど問わずインスタレーションしたい仲間を募集しています。

バスキュール技術ブログ

宇宙に浮かぶひまわりの目からいろんな地球を見る

春夏秋冬

日食

地上から見た日食

宇宙から見える日食

カルマン渦列

モーニンググローリー

地上から見たモーニンググローリー

ひまわりから見たモーニンググローリー

(What's the Story) Morning Glory?

森林火災

知らないことを知ること

22Kの地球タイムラプス映像をグリグリする

#アースデイライブ2024

地球映像でコンテンツを作ろうと思ったきっかけ

インタラクティブに地球映像をズームする

システム構成

映像ファイルがデカすぎる問題

TouchDesignerのFloating Cloud Licensesが外れる問題

ライブ系のプロジェクトで焦らないために・・・。

UnityでiPadをバーチャルカメラにしてイベント本番で使うときの問題点を解決した話をしますね

バーチャルカメラを振り回していい感じのメタバースの映像を撮る

前提条件: パブリックビューと管理画面をマルチディスプレイで出力

iPadバーチャルカメラとフルスクリーンの落とし穴

Live CaptureがUnity Editor専用でビルドすると動かせない (裏技で動かせるらしい)

じゃあビルドせずにUnity Editorで無理やり使おう！

Unity Editorをフルスクリーンにするアセット

問題1: Unity Editorでマルチディスプレイをすると、マウス座標が各ディスプレイで共通になって、めちゃくちゃになる

解決策: 対症療法で管理画面にロック機能をつけた

問題2: フルスクリーン時に画面キャプチャーすると、意図しない画面がキャプチャーされる

解決策: フルスクリーンガチャをする

問題3: PhotonでシーンをロードするとLive Captureが外れる

解決策: iOSのタスク切り替えを一瞬やると戻る

まとめ

おもしろがって作れる人材募集中！

オカシなツリーを飾る技術とチャレンジ

チャレンジしたこと

技術選定

セキュリティ対策

役に立ったこと

気をつけたこと

リスクを常に考える

チャレンジした結果

成長機会を求めている方をバスキュールは探しています

「#きぼうを見ようAR」逆ジオコーディングを作った話

逆ジオコーディングとは

取得の流れ

周囲の都道府県を選出・表示

エンジニアを募集しています

ARきぼう予報を作って宇宙飛行士に手を振った話

ISS観測について

モックを作る

3D環境のベースを作る

デバイスの向きの取得

絶対値で向きを取得するイベントに差し替える

iOSでの向きを地球軸にする

カメラの取得

位置情報の取得

デバイスの許可フローを作る

どこまで機能するか？

開発版のチェック

エンジニア募集してます！

Nuxt.jsを使用したスクロール連動の演出実装

サイトの見どころ

スムーススクロール + 無限スクロール

スクロールと連動した演出の仕組み

困ったけど解決したこと

watchメソッドの最適化

改善したいこと

nuxt generate後に生成されるhtmlのmetaが書き換わらない

そんな答えの分かるエンジニアをバスキュールは探しています

ExoplanetLanderのゲーム開発と、そこに至るまでの話

閑話休題

機体の作成と衝突判定

ステージの作成

遠隔での操作性

＜参考リンク＞

みんなでやったら楽しい

『Exoplanet Lander』 公開しました。

『Exoplanet Lander』公開しました。