【CEDEC2019 】5G時代に対応した『モノビットエンジン5G』を初公開！ HoloLens対応した通信クラウド最新情報も！

5G時代に対応した『モノビットエンジン5G』を初公開！
HoloLens対応した通信クラウド最新情報も！
モノビットエンジン株式会社
代表取締役社長安田京人
CTO 中嶋謙互

■会社紹介
関連会社
㈱モノビット㈱AVOCADO
■設立 2018年7月（モノビット社から事業独立・分社化いたしました。）
■代表取締役安田京人
■取締役本城嘉太郎
中嶋謙互
■神戸本社
兵庫県神戸市中央区神戸市中央区京町78番地三宮京町ビル 3階 A号室
■東京支社
東京都新宿区新宿1丁目9−2 ナリコマHD新宿ビル４F
モリカトロン㈱
スマホゲームやVRなどの受託開発を行っております。「地元でゲームを作ろう!」がコンセプト日本初のゲーム専用AIの会社です。

1980年横浜生まれ。
システムエンジニアを経て、コンシューマゲーム開発にプログラマーとして6年間従事。
携帯ゲーム機から据え置き機まで、アクションを中心に格闘ゲームやスポーツゲーム等
様々なタイトル開発に関わる。その後、ネットワークゲーム時代の到来を予見し、その
分野で展開を試みる株式会社モノビットへ入社モノビットではプログラマー責任者兼ミ
ドルウェア事業部長として、リアルタイム通信の研究開発に従事し、統合サーバパッ
ケージ「モノビットエンジン」の開発ディレクションとエヴァンジェリストとしても活
動。 2018年7月「モノビットエンジン株式会社」代表取締役に就任。 CEDEC、GTMF、
Unite等講演多数。
安田京人
モノビットエンジン株式会社代表取締役
■自己紹介

1974年京都に生まれ、小学生の時からゲームプログラミングを始める。
96年、世界初のJavaアプレットを用いたMMORPGを制作、複数のMMORPGを成功させた後、
2001年にはオンラインゲーム用ミドルウェアVCEを開発。約50社で利用され、
日本のオンラインゲームの黎明期を創出した。
その後、国民的人気シリーズのMMORPGをはじめ、様々なネットワークゲームの開発に従事。
また、シンラ・テクノロジー社ではクラウドゲーム用SDKの開発を主導。
著書に「オンラインゲームを支える技術－壮大なプレイ空間の舞台裏」（技術評論社）、
CEDECなど講演実績多数。
中嶋謙互
モノビットエンジン株式会社 CTO
■自己紹介

• モノビットエンジンのご紹介
• モノビットエンジン５Gの概略
• Monobit Reliable Udp（MRU）詳細
• モノビットエンジンクラウドVR/AR採用事例
• HoloLensを用いたマルチプレイコンテンツ開発TIPS
■アジェンダ
※本日のスライドは後日公開されますので、メモや撮影などは不要です。

ネットワークの知識がなくても
マルチプレイが実装可能
モノビットエンジンとは？一言で言うと

しかも20人接続までなら永久に無料！
一言で言うと

こんな方にオススメ
ゲーム作ろっと！
対戦プレイも入れたい！
でもネットワークを今から勉強するのは・・・。

サクッと作れないかなあ。
マ
ル
チ

あ、モノビットエンジンがあるじゃない！

しかもクラウドサービスもあるから
サーバを立てなくてもOK！
まずはモノビットエンジンとクラウドサービスをご紹介！

スマホ/家庭用ゲームやVRコンテンツで、マルチプレイを簡単に実現できる、リアルタイム通信ミドルウェアで
す。主に4つの製品ラインナップで展開しています。2017年にVer2.0に進化しました！
１，Monobit Revolution Server （略称：MRS）
MMORPGや、多人数MOアクションゲームにも対応出来る処理速度とレスポンスを
追求した、高速ゲームサーバです。シンプルなAPIで超高速通信かつ大規模同時接
続を実現します。
２，Monobit Unity Networking 2.0 (略称：MUN)
Unityに特化した通信ミドルウェアです。マッチング、ルーム、通信リレーの機能が
標準で用意されており、ネットワークの知識がなくてもマルチプレイを実装可能。
MRSと連携して、サーバにもC++/C#でコードが書けるように進化しました。
３，VR Voice Chat
VRコンテンツに「ボイスチャット機能」を手軽に実装できるUnity専用の無料
アセットです。MUNを搭載し、正確な物理同期・音声同期の実現が可能です。
xRデバイスへの搭載実績もあり、様々な業態にて利用されています。
本日の
メインテーマは
こちら！
■モノビットエンジンVer.2.0シリーズ
４，モノビットエンジンクラウド
ＭＵＮをバックエンドに搭載し、マルチプレイゲームをＵｎｉｔｙ上で簡単に実現
するクラウドサービスです。また、MUNの「VR Voice Chat」も標準で利用可能と
なっています。

■モノビットエンジン採用実績
xR 採用事例は
後半にご紹介！

モノビットエンジンの
クライアントアセットである
MUN (MonobitUnityNetworking)のご紹介

Unity特化型の通信エンジン
Unity5.x、Unity2017.x
Unity2018.4、Unity2019
■ MUN(Monobit Unity Networking)の特徴

●多彩な機能が多様なプラットフォームで利用可能
- サーバ接続/切断、オフラインモード
- ロビーやルームに対する入室/退室制御、ロビーとルームの状態取得
- プレイヤー情報の取得（サーバ内検索, プレイヤーパラメータの設定と取得）
- RPCによる、任意のクライアントに対する情報送信および受信
- シーン内オブジェクトの位置・姿勢・アニメーション等の同期
- 各種条件に応じた、マッチメイキング制御
- ノンプログラミング通信制御 etc...
※すべて単一のコンポーネントやAPIで実装可能
ブラウザゲーム開発でもMUNが使用可能
MUNで提供されている機能一覧
利用可能なプラットフォーム

●すべての通信ロジックを、クライアント側オンリーで実装可能
- 『サーバサイドの構築なしでリアルタイム通信を実現したい』というご要望に対応
- 通信ロジックも含め、オンラインゲームのすべての制御をクライアント側でコーディング可能！
※MUNサーバはbroadcastでリレー配信する役割を果たします
- クライアントコードをそのままサーバに移植して、簡単にチート対策！
- MUN標準機能のサーバのソースコードを公開中。VisualStudioでカスタマイズ可能。
●必要に応じて、サーバにコードを書くことも可能！
サーバとクライアントでコードを自在に配置可能
MUN リリース当初からの設計思想を実現
MUN2.0より、MRSと連携してC++/C#言語でサーバ開発が可能になりました！

- MUNサーバ側は、TCP/UDPの通信ポート双方で待ち受けしている
- 同一認証のMUNクライアントであれば、TCPの接続クライアントとUDPの接続クライアントを
同一ルームに接続させることも可能
●TCP, UDPの通信プロトコルの利用
- MUNの内部処理で行われる送受信（ロビー/ルームの入退室など）の通信をUDPで行なう場合、
すべて RUDP で伝送される
- RPC（リモートプロシージャコール）、およびオブジェクト同期通信のみUDP/RUDP の個別設定が可能
速度を重視するか信頼性を重視するか、
場面によって最適な通信プロトコルを選択可能
MUNにおける UDP/RUDP接続プロトコルについて
MRSに基づき、TCP/UDPの通信プロトコルをサポート

バージョンアップしたモノビットエンジン
『モノビットエンジン5G』

2020年には第5世代となる「５G」の運用が本格化され、
2024年末には人口の97%をカバー率を目指しています。（※１）
■「 Monobit Reliable Udp β版（MRU) 」が生まれた理由！
※１：総務省資料 http://www.soumu.go.jp/main_content/000613734.pdf

■ 「Monobit Reliable Udp β版（MRU)」が生まれた理由
5Gは『高速大容量』『低遅延』『同時多数接続』の
3つの特徴を持ちます。
参照「2020年に本格導入！5Gが創る新しい未来を東工大・阪口教授が解説！（前編）」
https://www.oro.com/ja/technology/013/
同時多数接続で
コンテンツの
あり方が変わる？
タイムラグは
1/10

■ Monobit Reliable Udp β版（MRU)
５Gの通信速度を最大限に活かせる
RUDPの通信アルゴリズムを一新！
MRSのRUDP通信プロトコル、
「Monobit Reliable Udp β版（MRU)」
を搭載したバージョンを、
先日公開いたしました！
http://www.monobitengine.com/
MRSが
バージョンアップ！

■「Monobit Revolution Server」の新プロトコルを公開！
今後通信コアとしてMRSを利用している「MUN」や「VR
VoiceChat」でもMRUが選択できるようになります。
http://www.monobitengine.com
/

■ Monobit Reliable Udp β版（MRU) 詳細
MRU : Monobit Reliable UDP
〜5G世代のモバイルゲームに最適な通信プロトコルを目指して〜
• モノビットエンジン取締役CTO
• 中嶋謙互
• Twitter @ringo
• https://github.com/kengonakajima

■ Internet Protocol Stack
https://www.w3.org/People/Frystyk/thesis/TcpIp.html
ハードウェア
1個1個のパケットを
マシンまで届ける
マシンの中のプロセスや
ソケットにデータを届ける
それぞれのアプリケーション

■ IPv4, IPv6の基本動作
引用元: atmarkit

■ WeBの発達
• インターネット黎明期: 1994年より前
– サーバーのリモート操作(telnet/ssh)や電子メール、FTPのために、データを正しい順序
で確実に届ける方法が必要だった。 TCPがこのために普及し、標準になった。
• ウェブ普及期: 1994年〜2005年
– TCPの上に実装されたHTTPがウェブの発展を支えた。
• モバイル普及期: 2005年〜
– 特にモバイルにおいて、HTTP(TCP)の遅さやIPアドレス変化が問題になった。
– WebSocketのようなつなぎっぱなしアプリではさらに問題が悪化した。
• TCP限界期: 2012年〜
– TCPを今さら捨てることはできないので、UDPをうまく使って、TCPの問題を解決する
ための挑戦が始まった。 Google社がSPDYを提案した。その後QUIC、HTTP3と概念と
仕様の発展が続く。

http://itpro.nikkeibp.co.jp/atcl/column/17/040400119/040400003/
■ TCP改善の歴史
• 1981年の使用開始から現在に至るまで改善の連続。。！

■ TCPの時代分け
• 1980年代 : TCP登場、telnetでマシンを遠隔操作
• 1990年代 : メールやHTTPなどで大ブレイク
• 2000年代 : モバイルで長時間のストールを防ぎたい！
• 2010年代 : 動画や音声を高速送信したい!

■ ゲームにおける通信の歴史
• シリアル通信時代: 1990年台前半まで
– ゲームの通信は、RS-232Cを使ってPCを接続してローカルマルチプレイを行うことが多かった。
• PCマルチプレイ発展期: 1990年台後半
– Windows95以降はソケットライブラリを使えるようになり、IPv4/UDPを用いてマルチプレイを実装するのが普通に
なった。パケットの順序制御や再送を行うロジックは、ゲームごとに作っていた。MMOでは、TCPもよく使われるよ
うになった。
• ゲーム機でも通信: 2000年〜
– PS2のネットワークアダプタなど、ゲーム機でもIPv4で通信ができるようになった。UDPを使うことが多かった。
UDPとTCPの併用。
– スマホ以前の携帯電話ではUDPが使えないこともあった。
• モバイルゲーム時代: 2010年〜
– スマホが一般化し、IPv4/IPv6上でUDP/TCPを用いて自由にマルチプレイを実装できるようになった。
– UDPの再送や順序制御用のライブラリがオープンソースで利用可能になった。
ゲームは最初からUDPと友達であった

■ TCPとUDPのでどちらををつかえばいいの？
• TCPはどんどん良くなり続けてきた
• TCPはとても使いやすくアプリのバグを減らせる
。ゲームでもできればTCPを使いたい。でもTCP
はストールするから。。
• ネットワークプログラマは何十年も迷っている

■ TCPがどうしても解決できない問題
• ストリームが1本しかない : head-of-line
blocking
• IPアドレスの変化に対応できない

■ TCP: head of line blocking
TCP
こんなふうにしたい
packet1の影響で、全体が長時間ストールする
packet1はストールするがpacket2,3は早く届く
packet1の再送
packet1の再送

■ TCP: IPアドレスの変化に対応できない
TCPのヘッダ
送り元のIDがヘッダに含まれていないので、
TCPはIPアドレスを使って送り元を識別している。

■ インターネットの性能
• パケットロス率
– 有線LAN : スイッチとケーブルがちゃんとしてたら、ほぼ0だが
、完全に0ではない
– 無線LAN : 負荷がないときでも10000個に1個ぐらい消える。負
荷が高いと、100個に1個消えるときもある
– モバイルネットワーク : 電波がいいときでも100個に1個消える
かも、電波が悪いと1割消えたりする

■ 1990年代からのゲームにおける解決策
• 信頼性を保証しないUDPを使うのでOK。最初からUDP。
– ただし、どうしても確実性が必要なデータだけ、再送の工夫を
追加して対処する。
– 確実さが必要な例：ショップでの売買。1回しかやらないから
。
– 確実さが不要な例：モブの座標。何度も送り続けるので、1個
消えても、後のやつが届いたらいいから。

■ RUDP (Reliable UDP)
• UDPに信頼性を追加した通信プロトコル
• ビデオゲームでは、1990年代から、各ゲームで
独自に実装していた。
• Webでは、2012年ごろから、Googleが主導し
て、QUICの標準化が進められている。

■ RUDP (Relible UDP)
• UDPに信頼性を追加した通信プロトコル
• ビデオゲームでは、1990年代から、各ゲー
ムで独自に実装していた。
• Webでは、2012年ごろから、Googleが主導
して、QUICの標準化が進められている。

■ RUDPの実装
• ENet (2004~) MRSでも採用している。少人数用
• LiteNetLib(2016~) ピュアC#実装
• netcode.io (2016~) C, Glenn Fiedler氏による
• quicly (2017~) C, QUICのドラフト15？
• gQUIC : GoogleのQUIC実装、最新版ドラフト＋実験用
• iQUIC : IETFのリファレンス実装
• ほかにも用途に合わせて、数え切れないほどある

■ MRU : Monobit RUDP
• C++(ほぼC)
• IPアドレス変化への対応
• 正しい順序で送る
• 確実に送る (早めの再送)
• 順序も確実さも保証しない方法で送ることもできる
• 0RTTハンドシェイク
• チェックサム
• C10K以上のMMO向けにチューニング(少人数ももちろんOK)
• スロット飽和攻撃対策
– IP偽装対策
– 大量接続対策
• Linux/Windows/iOS/Android/MacOSに対応、ゲーム機は対応予定
• 実装していない機能
– ストリーム内の多重化チャネル (ゲームでは必要性が薄いため)
– 暗号化(MRSのレイヤで実装するため)

■ MRU: IPアドレス変化への対応
• MRUでは、すべてのパケットに、送り元ID(64bit)と送り先ID(64bit)が付加されているので、IPアドレ
スが変わっても、接続のやりなおしが不要で、0RTT(往復時間ゼロ)で通信が継続できる。
• IPv6からIPv4に変わっても問題なし。 (iOSでのNAT64にも対応)

■ MRU: 順序制御と再送制御
• TCPを単純にしたものでだいたい同じ
– 受信側でパケットをキューにためて順番どおり取
り出す(詳細は省略)
• QUICにはない「早めの再送」を実装している。
– データをあえて2回(設定次第でN回)づつ冗長に送
って、
再送の必要性自体を無くす

■ MRU: 早めの再送
早めの再送なし
早めの再送あり
1が消えたので再送が必要!
2,3はストールしている
1が消えたが、次のパケットに1が
含まれている。再送の必要なし
※IP/UDPのヘッダが48バイトあるので、
ゲームのデータが小さい場合は、送信量は単純
に2倍にはならない

■ 0RTTハンドシェイク
https://jacobianengineering.com/blog/2016/11/1543/
1RTT
(Round Trip Time,
往復時間)
2~3RTT
MRUはこれ

■ MRU: チェックサム
• CRC32を使っている
• ON/OFFができる。OFFにすると少し軽い。
• サーバ間通信ではOFFでOK

■ MRU: MMO向けのチューニング
• Linux カーネル3以降で追加された
send/recvmmsgシステムコールを使用。
– Linux以外ではsendmsgを使用
• カーネルコールオーバーヘッドを減らしている
• クラウドインスタンスでも効果を発揮している。
• 測定値は後述

■ MRU: IPアドレス偽装攻撃への対応
• IPアドレス偽装とは
– 典型的なDDoS攻撃であるスロット飽和攻撃
で使われる。使われていないIPアドレスを送
り元に設定したIPパケットを送って、サーバ
ーの接続スロットを飽和させる。

■スロット飽和攻撃 (IP偽装なし)

■スロット飽和攻撃 (IP偽装あり)

• 1秒あたりの接続回数が設定値を越えたときは、攻撃防御モードに入る。
• 攻撃防御モードでは、0RTTハンドシェイクをやめて、3Wayハンドシェ
イク(1RTT)を採用する。このとき、サーバのメモリを確保しない。
• 3Wayハンドシェイクでは、サーバーが発行した予測できない鍵(32ビッ
ト値)をクライアントに送り、それを返したクライアントだけ、メモリを
確保する。
サーバークライアント
接続要求
鍵
ここではメモリを確保しない
ここでメモリを確保する
鍵
※TCPの SYN クッキーとだいたい同じ
■MRU: IPアドレス偽装攻撃への対応

• IPアドレスを偽装しなくても、大量に接続をす
ることで攻撃ができる。
• 同じIPアドレスからの連続的な接続は設定され
た頻度以上ではできない。
■MRU: 一般的飽和攻撃への対応

• 低品質ネットワークのシミュレーション機能
– パケットロス率
– パケット重複率
– パケット遅延
– CRCエラー率
※TCPの SYN クッキーとだいたい同じ
■MRU:デバッグ機能

■MRU: ベンチマーク
• udptestプログラム
– 同時接続数32768までのテストに使える
– 早めの再送 ON/OFF
– CRC ON/OFF
– エコーON/OFF
– 攻撃防御モードの閾値設定
– 送信サイズ、送信頻度設定

Linux
Socket
MRU
MRS
アプリコード
libuvENet
マシン
物理層ベンチマーク
MRU層ベンチマーク
MRS層ベンチマーク
■MRU: システム階層(Linux)

• udpmax (MRUを使わない、UDP高負荷ツール)
– iperf3は性能が不足しているため、自作した
sv1 sv2
シングルスレッド
sendmmsgテスト size=1
udpmax udpmax
71万pkt/s
40Mbytes/s
sv1 sv2
4スレッド
udpmax udpmax
108万pkt/s
78Mbytes/s
udpmax
udpmax
udpmax
udpmax
udpmax
udpmax
4スレッド
70万pkt/s
1.06Gbytes/s
8Gbps出ている、速い
■物理層ベンチマーク

• udptestプログラム
– 同時接続数32768までのテストに使える
– 早めの再送 ON/OFF
– CRC ON/OFF
– エコーON/OFF
– 攻撃防御モードの閾値設定
– 送信サイズ、送信頻度設定
■MRU層ベンチマーク

sv1 sv2
udptest
udptest
シングルスレッドサーバの限界性能測定を行う。
負荷
udptest
udptest
・・・
■ベンチマーク構成

• データ受信コールバック関数の呼び出し回数を
測定する。
– 送信側でアプリケーションデータを送るとき
は、mru_peer_send(data) を1回呼び出す。
– それに対応して、受信側で受信関数が1回呼ば
れる。この1秒あたり回数を数える。
• 送信タイミングが近いと、1個のMRUパケット
に複数のアプリケーションデータが詰め込まれ
る場合がある。
■MRU層の測定内容

• 同時接続1, 間隔0.1秒、サイズ24, 早めの再送OFF
– ./udptest 10.100.xx.xx —interval=0.1 --
fast_retransmit=0 --conn=1
– 10コールバック/s
– 20pkt/s(send+recv)
– 平均パケットサイズ 60bytes
– サーバCPU : 5% (ほぼ空ループ毎秒1万回、調整可
能)
■MRU層の動作確認

• 同時接続12000, 間隔0.01秒、サイズ24,早めの再
送OFF
– ./udptest 10.100.xx.xx --interval=0.01 --
fast_retransmit=0 --conn=4000 x 3プロセス
– 108万コールバック/s
– 71万8000pkt/s (物理限界)
– 84Mbytes/s, 平均パケットサイズ 111bytes
– サーバ側CPU : 80% (1スレッド. 4vCPUなので
最大400％)
これ以上負荷をかけると、物理層が耐えられないので再送が増えすぎ、
接続が切れてエラー。
■MRU層最大帯域毎秒

• 同時接続12000, 間隔0.1秒, 早めの再送なし, エコーあ
り、サイズ1000
–./udptest 10.100.xx.xx --interval=0.1 --
fast_retransmit=0 --echo --conn=4000 --
size=1000 x 3
–39000コールバック/s
–25万pkt/s
–256Mbytes/s, 平均パケットサイズ 1026bytes
–サーバ側CPU : 70%(1スレッド)
■MRU層最大コールバック毎秒

• mrs_bench
– MRUだけでなくTCP,ENet,WebSocket,と切
り替えて比較が可能
– 暗号化通信 ON/OFF (今回は省略)
– 受信コールバック関数の呼び出し回数を測定
する。

• MRU, 同時接続1、間隔0.1秒、サイズ24、早めの再送な
し
–./mrsbenchcl 10.100.xx.xx 1 100 —
fast_retransmit=0
–10コールバック/s
–20pkt/s(send+recv)
–平均パケットサイズ 72bytes (MRSのヘッダ12バイト)
–サーバCPU : 6% (ほぼ空ループ毎秒1万回、調整可能)

• MRU, 同時接続4800、間隔0.005秒、サイズ24、早め
の再送なし echoなし
–./mrsbenchcl 10.100.102.80 1200 5 —
fast_retransmit=0 x 4
–62万コールバック/s
–72万pkt/s(send+recv) 物理限界 73Mbytes/s
–平均パケットサイズ 100bytes
–サーバCPU : 58% (1スレッド)

• TCP, 同時接続2000、間隔0.005秒、サイズ24、
echoなし
–./mrsbenchcl 10.100.102.80 1000 5 —tcp x 4
–69万pkt/s(send+recv) 物理限界 56Mbytes/s

• MRU, 同時接続3000、間隔0.01秒、サイズ512、早めの
再送なし echoなし
–./mrsbenchcl 10.100.102.80 1500 10 —
fast_retransmit=0 —size=512 x 2スレッド
–55.7万pkt/s(send+recv) 303Mbytes/s

• TCP, 同時接続1200、間隔0.01秒、サイズ1400、
echoなし
–./mrsbenchcl 10.100.102.80 1200 10 —
size=1400 x 2スレッド
–55.7万pkt/s(send+recv) 340Mbytes/s

TCP MRU
最大コールバック回数 34万/s 62万/s
上記時点での
サーバCPU
100% 58%
上記時点での
UDPパケット数
69万pkt/s 72万pkt/s
最大帯域 340Mbytes/s 303Mbytes/s
上記時点での
サーバCPU
90% 70%
上記時点での
データサイズ
1400 (MTU合わせ) 512 (MRS現状仕様による)
シングルスレッドサーバーの最高性能を示している。

• 同時接続1万のとき、UDPはソケット1個でよいが、TCPは
ソケットが1万個必要。
• 1万のソケットに対して1回のシステムコールで書き込みを
するAPIがLinuxでは存在しない。(デバイスドライバを直接
叩くライブラリを使えば可能)
• Linuxのシステムコールをまとめて呼び出せるようにする議
論が、カーネルメーリングリストで進行中。早く実現され
たら素晴らしい! (今後に期待)

• MRS側を長いメッセージに対応させる
• パケットヘッダ圧縮 (長いIDをパックする)
• さらなる高速化：ゼロコピーに近づける(MRSも
)
• 暗号化する場合も0RTTにする

• モノビットエンジン MRS バージョン 2.0.0から
、MRUは選択可能です。ぜひお試しください!

モノビットエンジン
VR/AR採用事例

株式会社バーチャルキャスト
ドワンゴ社と一緒にやることで、サーバーの負荷
がかかり、大改修が必要になるのはわかっていま
した。最初のバージョンでは他のリアルタイム通
信エンジンを利用していたのですが、通信の制限
やその改善で発生する課題がありました。
そこでモノビット社に相談したところ、モノビッ
トエンジンを利用すれば、解決できそうだとわ
かったのです。モノビット社はVR分野でも実績と
知見があるうえ、製品サポートの厚さも重要なポ
イントでした。
サービスに人気が出て、負荷が出て、止められな
いサービスになったときに安心感がある企業と組
みたい。そうなった時に安心して深いところまで
付き合えるパートナーが必要だったのです。
≪モノビットエンジン採用の理由≫
代表取締役社長：松井健太郎様
http://www.monobitengine.com/interview/36/
採用タイトル

75
■モノビットエンジンの使用範囲
・VR空間内でのオブジェクト同期
・ボイスチャット
※より深いバーチャルキャストを支える技術についての詳細は下記スライドをご参照ください。
https://www.slideshare.net/yhonjo/vr-103229316

※下記スライドより引用
https://www.slideshare.net/yhonjo/vr-
103229316

78
出典：マイナビニュース
フィールド業務に変革をもたらすサン電子の
ARスマートグラス「AceReal One」に注目－第4回ウェアラブルEXPOより
https://news.mynavi.jp/article/20180126-576734/
https://www.youtube.com/watch?v=SpMSmcfvzrA
AceRael Oneはフィールド業務に変革をもたらすソリューションです。
BtoB分野にとどまらず、音声認識やボイス・ビデオチャットの機能を
使ったアプリ開発が容易な為、様々な分野への応用が期待できます。
【採用事例】 AceReal One

79
パルス株式会社がパブリッシングする「INSPAIX LIVE」は誰もが自宅にいながら、音楽ライブやバーチャル握
手会に参加することができ、出演アーティストとリアルタイムコミュニケーションができる革新的なサービスで
す。
採用製品
© pulse Inc.
Virtual Live Platform「INSPIX LIVE」の特徴と独自性
INSPIX LIVEの
特徴と独自性を
支えています！
【採用事例】 INSPIX LIVE

80
その他こんなxRデバイスでも動きます。
Mirage Solo
Oculus Quest
■対応デバイス

Microsoft HoloLensに正式対応しました！
勿論モノビットエンジンクラウドが利用可能なので、
空間共有コンテンツをすぐに開発する事ができます。
■MUNとVRボイスチャットの最新情報

• SLAM（スラム、 Simultaneous Localization and Mapping ）とは、
自己位置推定と環境地図作成を同時に行うことを言う。
• HoloLens 空間マッピング
■ARとVR最大の違い

• 同じ空間にいても見えるものが同じ位置にならない。
→アプリを起動した位置が原点として扱われる
■HoloLensのマルチプレイアプリ開発の注意点
ここにある
ね！私から見るとここにあるけど…

■HoloLens同士の位置合わせ（公式）
• World
Anchor
• Sharing
• World Anchor共有

■HoloLens同士の位置合わせ（他の方法）
• 起動位置合わせ
• 画像認識（ARマーカー）
– OpenCV
→超有名OSS。勿論無料
– Vuforia
→基本は有償だが、
無償プランも有。
ユーザー登録は必須。
• モノビットエンジンのHoloLensデモを作成した際に取った方法
– VuforiaとMRTKのSpatialMappingの併用

• Gaze - 目視
• Bloom -メニューを出す
• Air tap - クリック
• Voice – 音声入力
■HoloLensアプリ開発する際の入力方法の選択肢

• MRTK-Mixed Reality Toolkit
– https://github.com/microsoft/MixedReality
Toolkit-Unity
HoloLens基本機能、操作方法、UI表現など
■ HoLorens開発上便利なAPI

UI操作方法等 – MRTK付属のUI、Air tap
キャリブレーション – Vuforia、MRTKの
SpatialMapping
オブジェクト同期 - ボイスチャット – モ
ノビットエンジンクラウド
■モノビットエンジンHoLolensデモ

本日ブースでデモを行ってます！
ぜひ来てください！
■MUNとVRボイスチャットの最新情報
お気軽にお問合せください contact@monobit.co.jp

【CEDEC2019 】5G時代に対応した『モノビットエンジン5G』を初公開！ HoloLens対応した通信クラウド最新情報も！

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 【CEDEC2019 】5G時代に対応した『モノビットエンジン5G』を初公開！ HoloLens対応した通信クラウド最新情報も！

Similar to 【CEDEC2019 】5G時代に対応した『モノビットエンジン5G』を初公開！ HoloLens対応した通信クラウド最新情報も！ (20)

More from モノビットエンジン

More from モノビットエンジン (20)