Download as PDF, PPTX
Uploaded byモノビット エンジン
【CEDEC2019 】5G時代に対応した『モノビットエンジン5G』を初公開！ HoloLens対応した通信クラウド最新情報も！
【CEDEC2019】上記の弊社セッションにてご紹介させていただいたスライドを公開したします。 ■セッションタイトル 5G時代に対応した『モノビットエンジン5G』を初公開！ HoloLens対応した通信クラウド最新情報も！ ■セッション概要 『モノビットエンジン』は、ドコモ５Gオープンパートナー企業として、5Gの通信速度を最大限に活かし切るため、RUDPの通信アルゴリズムを一新しました！従来比でさらに5倍高速になった『モノビットエンジン5G』の最新性能と新機能を初公開で発表させて頂きます。また、盛り上がりを見せるAR/VR/MRサービスに対応するため、HoloLensに正式対応した『モノビットエンジンクラウド』の最新情報や、スマホゲームからVRライブまで、最新のエンジン採用事例をご紹介します。 ■登壇者 ・代表取締役社長 安田京人 ・弊社CTO 中嶋謙互
More Related Content
![スマホゲームのチート手法とその対策 [DeNA TechCon 2019]](https://cdn.slidesharecdn.com/ss_thumbnails/techcon2019funakubo-190218065153-thumbnail.jpg?width=640&height=640&fit=bounds)
![[CEDEC2012]ネットワークゲームの不正行為と対策](https://cdn.slidesharecdn.com/ss_thumbnails/20120821cedec2012-141216194712-conversion-gate02-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to 【CEDEC2019 】5G時代に対応した『モノビットエンジン5G』を初公開！ HoloLens対応した通信クラウド最新情報も！
【CEDEC2019 】5G時代に対応した『モノビットエンジン5G』を初公開！ HoloLens対応した通信クラウド最新情報も！
- 1.
- 2. ■会社紹介 関連会社 ㈱モノビット ㈱AVOCADO ■設立 2018年7月（モノビット社から事業独立・分社化いたしました。） ■代表取締役安田 京人 ■取締役 本城 嘉太郎 中嶋 謙互 ■神戸本社 兵庫県神戸市中央区神戸市中央区京町78番地 三宮京町ビル 3階 A号室 ■東京支社 東京都新宿区新宿1丁目9−2 ナリコマHD新宿ビル４F モリカトロン㈱ スマホゲームやVRなどの受託開発を行っております。 「地元でゲームを作ろう!」がコンセプト 日本初のゲーム専用AIの会社です。
- 3. 1980年横浜生まれ。 システムエンジニアを経て、コンシューマゲーム開発にプログラマーとして6年間従事。 携帯ゲーム機から据え置き機まで、アクションを中心に格闘ゲームやスポーツゲーム等 様々なタイトル開発に関わる。 その後、ネットワークゲーム時代の到来を予見し、その 分野で展開を試みる株式会社モノビットへ入社モノビットではプログラマー責任者兼ミ ドルウェア事業部長として、リアルタイム通信の研究開発に従事し、統合サーバパッ ケージ「モノビットエンジン」の開発ディレクションとエヴァンジェリストとしても活 動。 2018年7月「モノビットエンジン株式会社」代表取締役に就任。CEDEC、GTMF、 Unite等講演多数。 安田 京人 モノビットエンジン株式会社 代表取締役 ■自己紹介
- 4.
- 5. • モノビットエンジンのご紹介 • モノビットエンジン５Gの概略 •Monobit Reliable Udp（MRU）詳細 • モノビットエンジンクラウドVR/AR採用事例 • HoloLensを用いたマルチプレイコンテンツ開発TIPS ■アジェンダ ※本日のスライドは後日公開されますので、メモや撮影などは不要です。
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12. スマホ/家庭用ゲームや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」も標準で利用可能と なっています。
- 13.
- 14.
- 15.
- 16. ●多彩な機能が多様なプラットフォームで利用可能 - サーバ接続/切断、オフラインモード - ロビーやルームに対する入室/退室制御、ロビーとルームの状態取得 -プレイヤー情報の取得（サーバ内検索, プレイヤーパラメータの設定と取得） - RPCによる、任意のクライアントに対する情報送信および受信 - シーン内オブジェクトの位置・姿勢・アニメーション等の同期 - 各種条件に応じた、マッチメイキング制御 - ノンプログラミング通信制御 etc... ※すべて単一のコンポーネントやAPIで実装可能 ■ MUN(Monobit Unity Networking)の特徴 ブラウザゲーム開発でもMUNが使用可能 MUNで提供されている機能一覧 利用可能なプラットフォーム
- 17. ●すべての通信ロジックを、クライアント側オンリーで実装可能 - 『サーバサイドの構築なしでリアルタイム通信を実現したい』というご要望に対応 - 通信ロジックも含め、オンラインゲームのすべての制御をクライアント側でコーディング可能！ ※MUNサーバはbroadcastでリレー配信する役割を果たします -クライアントコードをそのままサーバに移植して、簡単にチート対策！ - MUN標準機能のサーバのソースコードを公開中。VisualStudioでカスタマイズ可能。 ●必要に応じて、サーバにコードを書くことも可能！ サーバとクライアントでコードを自在に配置可能 MUN リリース当初からの設計思想を実現 MUN2.0より、MRSと連携してC++/C#言語でサーバ開発が可能になりました！ ■ MUN(Monobit Unity Networking)の特徴
- 18. - MUNサーバ側は、TCP/UDPの通信ポート双方で待ち受けしている - 同一認証のMUNクライアントであれば、TCPの接続クライアントとUDPの接続クライアントを 同一ルームに接続させることも可能 ●TCP,UDPの通信プロトコルの利用 - MUNの内部処理で行われる送受信（ロビー/ルームの入退室など）の通信をUDPで行なう場合、 すべて RUDP で伝送される - RPC（リモートプロシージャコール）、およびオブジェクト同期通信のみUDP/RUDP の個別設定が可能 速度を重視するか信頼性を重視するか、 場面によって最適な通信プロトコルを選択可能 ■ MUN(Monobit Unity Networking)の特徴 MUNにおける UDP/RUDP接続プロトコルについて MRSに基づき、TCP/UDPの通信プロトコルをサポート
- 19.
- 20. 2020年には第5世代となる「５G」の運用が本格化され、 2024年末には人口の97%をカバー率を目指しています。（※１） ■「 Monobit ReliableUdp β版（MRU) 」が生まれた理由！ ※１：総務省資料 http://www.soumu.go.jp/main_content/000613734.pdf
- 21. ■ 「Monobit ReliableUdp β版（MRU)」が生まれた理由 5Gは『高速大容量』『低遅延』『同時多数接続』の 3つの特徴を持ちます。 参照「2020年に本格導入！5Gが創る新しい未来を東工大・阪口教授が解説！（前編）」 https://www.oro.com/ja/technology/013/ 同時多数接続で コンテンツの あり方が変わる？ タイムラグは 1/10
- 22. ■ Monobit ReliableUdp β版（MRU) ５Gの通信速度を最大限に活かせる RUDPの通信アルゴリズムを一新！ MRSのRUDP通信プロトコル、 「Monobit Reliable Udp β版（MRU)」 を搭載したバージョンを、 先日公開いたしました！ http://www.monobitengine.com/ MRSが バージョンアップ！
- 23.
- 24. ■ Monobit ReliableUdp β版（MRU) 詳細 MRU : Monobit Reliable UDP 〜5G世代のモバイルゲームに最適な通信プロトコルを目指して〜 • モノビットエンジン 取締役CTO • 中嶋謙互 • Twitter @ringo • https://github.com/kengonakajima
- 25. ■ Internet ProtocolStack https://www.w3.org/People/Frystyk/thesis/TcpIp.html ハードウェア 1個1個のパケットを マシンまで届ける マシンの中のプロセスや ソケットにデータを届ける それぞれのアプリケーション
- 26. ■ IPv4, IPv6の基本動作 引用元:atmarkit
- 27. ■ WeBの発達 • インターネット黎明期:1994年より前 – サーバーのリモート操作(telnet/ssh)や電子メール、FTPのために、データを正しい順序 で確実に届ける方法が必要だった。 TCPがこのために普及し、標準になった。 • ウェブ普及期: 1994年〜2005年 – TCPの上に実装されたHTTPがウェブの発展を支えた。 • モバイル普及期: 2005年〜 – 特にモバイルにおいて、HTTP(TCP)の遅さやIPアドレス変化が問題になった。 – WebSocketのようなつなぎっぱなしアプリではさらに問題が悪化した。 • TCP限界期: 2012年〜 – TCPを今さら捨てることはできないので、UDPをうまく使って、TCPの問題を解決する ための挑戦が始まった。 Google社がSPDYを提案した。その後QUIC、HTTP3と概念と 仕様の発展が続く。
- 28.
- 29. ■ TCPの時代分け • 1980年代: TCP登場、telnetでマシンを遠隔操作 • 1990年代 : メールやHTTPなどで大ブレイク • 2000年代 : モバイルで長時間のストールを防ぎたい！ • 2010年代 : 動画や音声を高速送信したい!
- 30. ■ ゲームにおける通信の歴史 • シリアル通信時代: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と友達であった
- 31. ■ TCPとUDPのでどちらををつかえばいいの？ • TCPはどんどん良くなり続けてきた •TCPはとても使いやすくアプリのバグを減らせる 。ゲームでもできればTCPを使いたい。でもTCP はストールするから。。 • ネットワークプログラマは何十年も迷っている
- 32. ■ TCPがどうしても解決できない問題 • ストリームが1本しかない: head-of-line blocking • IPアドレスの変化に対応できない
- 33. ■ TCP: headof line blocking TCP こんなふうにしたい packet1の影響で、全体が長時間ストールする packet1はストールするがpacket2,3は早く届く packet1の再送 packet1の再送
- 34.
- 35. ■ インターネットの性能 • パケットロス率 –有線LAN : スイッチとケーブルがちゃんとしてたら、ほぼ0だが 、完全に0ではない – 無線LAN : 負荷がないときでも10000個に1個ぐらい消える。負 荷が高いと、100個に1個消えるときもある – モバイルネットワーク : 電波がいいときでも100個に1個消える かも、電波が悪いと1割消えたりする
- 36. ■ 1990年代からのゲームにおける解決策 • 信頼性を保証しないUDPを使うのでOK。最初からUDP。 –ただし、どうしても確実性が必要なデータだけ、再送の工夫を 追加して対処する。 – 確実さが必要な例：ショップでの売買。1回しかやらないから 。 – 確実さが不要な例：モブの座標。何度も送り続けるので、1個 消えても、後のやつが届いたらいいから。
- 37. ■ RUDP (ReliableUDP) • UDPに信頼性を追加した通信プロトコル • ビデオゲームでは、1990年代から、各ゲームで 独自に実装していた。 • Webでは、2012年ごろから、Googleが主導し て、QUICの標準化が進められている。
- 38. ■ RUDP (RelibleUDP) • UDPに信頼性を追加した通信プロトコル • ビデオゲームでは、1990年代から、各ゲー ムで独自に実装していた。 • Webでは、2012年ごろから、Googleが主導 して、QUICの標準化が進められている。
- 39. ■ RUDPの実装 • ENet(2004~) MRSでも採用している。少人数用 • LiteNetLib(2016~) ピュアC#実装 • netcode.io (2016~) C, Glenn Fiedler氏による • quicly (2017~) C, QUICのドラフト15？ • gQUIC : GoogleのQUIC実装、最新版ドラフト＋実験用 • iQUIC : IETFのリファレンス実装 • ほかにも用途に合わせて、数え切れないほどある
- 40. ■ MRU :Monobit RUDP • C++(ほぼC) • IPアドレス変化への対応 • 正しい順序で送る • 確実に送る (早めの再送) • 順序も確実さも保証しない方法で送ることもできる • 0RTTハンドシェイク • チェックサム • C10K以上のMMO向けにチューニング(少人数ももちろんOK) • スロット飽和攻撃対策 – IP偽装対策 – 大量接続対策 • Linux/Windows/iOS/Android/MacOSに対応、ゲーム機は対応予定 • 実装していない機能 – ストリーム内の多重化チャネル (ゲームでは必要性が薄いため) – 暗号化(MRSのレイヤで実装するため)
- 41. ■ MRU: IPアドレス変化への対応 •MRUでは、すべてのパケットに、送り元ID(64bit)と送り先ID(64bit)が付加されているので、IPアドレ スが変わっても、接続のやりなおしが不要で、0RTT(往復時間ゼロ)で通信が継続できる。 • IPv6からIPv4に変わっても問題なし。 (iOSでのNAT64にも対応)
- 42. ■ MRU: 順序制御と再送制御 •TCPを単純にしたものでだいたい同じ – 受信側でパケットをキューにためて順番どおり取 り出す(詳細は省略) • QUICにはない「早めの再送」を実装している。 – データをあえて2回(設定次第でN回)づつ冗長に送 って、 再送の必要性自体を無くす
- 43.
- 44. ■ 0RTTハンドシェイク https://jacobianengineering.com/blog/2016/11/1543/ 1RTT (Round TripTime, 往復時間) 2~3RTT MRUはこれ
- 45. ■ MRU: チェックサム •CRC32を使っている • ON/OFFができる。OFFにすると少し軽い。 • サーバ間通信ではOFFでOK
- 46. ■ MRU: MMO向けのチューニング •Linux カーネル3以降で追加された send/recvmmsgシステムコールを使用。 – Linux以外ではsendmsgを使用 • カーネルコールオーバーヘッドを減らしている • クラウドインスタンスでも効果を発揮している。 • 測定値は後述
- 47. ■ MRU: IPアドレス偽装攻撃への対応 •IPアドレス偽装とは – 典型的なDDoS攻撃であるスロット飽和攻撃 で使われる。使われていないIPアドレスを送 り元に設定したIPパケットを送って、サーバ ーの接続スロットを飽和させる。
- 48.
- 49.
- 50. • 1秒あたりの接続回数が設定値を越えたときは、攻撃防御モードに入る。 • 攻撃防御モードでは、0RTTハンドシェイクをやめて、3Wayハンドシェ イク(1RTT)を採用する。このとき、サーバのメモリを確保しない。 •3Wayハンドシェイクでは、サーバーが発行した予測できない鍵(32ビッ ト値)をクライアントに送り、それを返したクライアントだけ、メモリを 確保する。 サーバー クライアント 接続要求 鍵 ここではメモリを確保しない ここでメモリを確保する 鍵 ※TCPの SYN クッキーとだいたい同じ ■MRU: IPアドレス偽装攻撃への対応
- 51.
- 52. • 低品質ネットワークのシミュレーション機能 – パケットロス率 –パケット重複率 – パケット遅延 – CRCエラー率 ※TCPの SYN クッキーとだいたい同じ ■MRU:デバッグ機能
- 53. ■MRU: ベンチマーク • udptestプログラム –同時接続数32768までのテストに使える – 早めの再送 ON/OFF – CRC ON/OFF – エコーON/OFF – 攻撃防御モードの閾値設定 – 送信サイズ、送信頻度設定
- 54.
- 55. • udpmax (MRUを使わない、UDP高負荷ツール) –iperf3は性能が不足しているため、自作した sv1 sv2 シングルスレッド sendmmsgテスト size=1 udpmax udpmax 71万pkt/s 40Mbytes/s sv1 sv2 4スレッド sendmmsgテスト size=1 udpmax udpmax 108万pkt/s 78Mbytes/s udpmax udpmax udpmax udpmax udpmax udpmax 4スレッド sendmmsgテスト size=1472 70万pkt/s 1.06Gbytes/s 8Gbps出ている、速い ■物理層ベンチマーク
- 56. • udptestプログラム – 同時接続数32768までのテストに使える –早めの再送 ON/OFF – CRC ON/OFF – エコーON/OFF – 攻撃防御モードの閾値設定 – 送信サイズ、送信頻度設定 ■MRU層ベンチマーク
- 57.
- 58. • データ受信コールバック関数の呼び出し回数を 測定する。 – 送信側でアプリケーションデータを送るとき は、mru_peer_send(data)を1回呼び出す。 – それに対応して、受信側で受信関数が1回呼ば れる。この1秒あたり回数を数える。 • 送信タイミングが近いと、1個のMRUパケット に複数のアプリケーションデータが詰め込まれ る場合がある。 ■MRU層の測定内容
- 59. • 同時接続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層の動作確認
- 60. • 同時接続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層最大帯域毎秒
- 61. • 同時接続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層最大コールバック毎秒
- 62. • mrs_bench – MRUだけでなくTCP,ENet,WebSocket,と切 り替えて比較が可能 –暗号化通信 ON/OFF (今回は省略) – 受信コールバック関数の呼び出し回数を測定 する。 ■MRU層最大帯域毎秒
- 63. • MRU, 同時接続1、間隔0.1秒、サイズ24、早めの再送な し –./mrsbenchcl10.100.xx.xx 1 100 — fast_retransmit=0 –10コールバック/s –20pkt/s(send+recv) –平均パケットサイズ 72bytes (MRSのヘッダ12バイト) –サーバCPU : 6% (ほぼ空ループ毎秒1万回、調整可能) ■MRU層最大帯域毎秒
- 64. • 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スレッド) ■スロット飽和攻撃 (IP偽装あり)
- 65. • TCP, 同時接続2000、間隔0.005秒、サイズ24、 echoなし –./mrsbenchcl10.100.102.80 1000 5 —tcp x 4 –34万コールバック/s –69万pkt/s(send+recv) 物理限界 56Mbytes/s –平均パケットサイズ 81bytes –サーバCPU : 100% (1スレッド) ■スロット飽和攻撃 (IP偽装あり)
- 66. • MRU, 同時接続3000、間隔0.01秒、サイズ512、早めの 再送なしechoなし –./mrsbenchcl 10.100.102.80 1500 10 — fast_retransmit=0 —size=512 x 2スレッド –24万コールバック/s –55.7万pkt/s(send+recv) 303Mbytes/s –平均パケットサイズ 544bytes –サーバCPU : 70% (1スレッド) ■スロット飽和攻撃 (IP偽装あり)
- 67. • TCP, 同時接続1200、間隔0.01秒、サイズ1400、 echoなし –./mrsbenchcl10.100.102.80 1200 10 — size=1400 x 2スレッド –22万コールバック/s –55.7万pkt/s(send+recv) 340Mbytes/s –平均パケットサイズ 872bytes –サーバCPU : 90% (1スレッド) ■スロット飽和攻撃 (IP偽装あり)
- 68. TCP MRU 最大コールバック回数 34万/s62万/s 上記時点での サーバCPU 100% 58% 上記時点での UDPパケット数 69万pkt/s 72万pkt/s 最大帯域 340Mbytes/s 303Mbytes/s 上記時点での サーバCPU 90% 70% 上記時点での データサイズ 1400 (MTU合わせ) 512 (MRS現状仕様による) シングルスレッドサーバーの最高性能を示している。 ■スロット飽和攻撃 (IP偽装あり)
- 69. • 同時接続1万のとき、UDPはソケット1個でよいが、TCPは ソケットが1万個必要。 • 1万のソケットに対して1回のシステムコールで書き込みを するAPIがLinuxでは存在しない。(デバイスドライバを直接 叩くライブラリを使えば可能) •Linuxのシステムコールをまとめて呼び出せるようにする議 論が、カーネルメーリングリストで進行中。早く実現され たら素晴らしい! (今後に期待) ■スロット飽和攻撃 (IP偽装あり)
- 70. • MRS側を長いメッセージに対応させる • パケットヘッダ圧縮(長いIDをパックする) • さらなる高速化：ゼロコピーに近づける(MRSも ) • 暗号化する場合も0RTTにする ■スロット飽和攻撃 (IP偽装あり)
- 71. • モノビットエンジン MRSバージョン 2.0.0から 、MRUは選択可能です。ぜひお試しください! ■スロット飽和攻撃 (IP偽装あり)
- 72.
- 73. 73 バーチャルキャスト社が提供するサービス。 バーチャルキャラクターになってVR空間のスタジオをリアルタイムで配信し、コ ミュニケーションできるVRライブ・コミュニケーションサービス。 https://www.youtube.com/watch?v=P66BNMuee7A © Virtual Cast,Inc. All rights reserved. 【採用事例】バーチャルキャスト
- 74.
- 75.
- 76.
- 77. 77 ネットワークを通じてリアルタイムで画像・映像共有、 ボイスチャットによるコミュニケーションをスマートグラス上で実現。 https://www.youtube.com/watch?v=YmydXPQHAsI © SUNCORPORATION Allrights reserved. 【採用事例】 AceReal One 採用製品
- 78. 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. 79 パルス株式会社がパブリッシングする「INSPAIX LIVE」は誰もが自宅にいながら、音楽ライブやバーチャル握 手会に参加することができ、出演アーティストとリアルタイムコミュニケーションができる革新的なサービスで す。 採用製品 © pulseInc. Virtual Live Platform「INSPIX LIVE」の特徴と独自性 INSPIX LIVEの 特徴と独自性を 支えています！ 【採用事例】 INSPIX LIVE
- 80.
- 81.
- 82. • SLAM（スラム、 SimultaneousLocalization and Mapping ）とは、 自己位置推定と環境地図作成を同時に行うことを言う。 • HoloLens 空間マッピング ■ARとVR最大の違い
- 83.
- 84. ■HoloLens同士の位置合わせ （公式） • World Anchor •Sharing • World Anchor共有
- 85. ■HoloLens同士の位置合わせ （他の方法） • 起動位置合わせ •画像認識（ARマーカー） – OpenCV →超有名OSS。勿論無料 – Vuforia →基本は有償だが、 無償プランも有。 ユーザー登録は必須。 • モノビットエンジンのHoloLensデモを作成した際に取った方法 – VuforiaとMRTKのSpatialMappingの併用
- 86. • Gaze -目視 • Bloom -メニューを出す • Air tap - クリック • Voice – 音声入力 ■HoloLensアプリ開発する際の入力方法の選択肢
- 87. • MRTK-Mixed RealityToolkit – https://github.com/microsoft/MixedReality Toolkit-Unity HoloLens基本機能、操作方法、UI表現など ■ HoLorens開発上便利なAPI
- 88. UI操作方法等 – MRTK付属のUI、Airtap キャリブレーション – Vuforia、MRTKの SpatialMapping オブジェクト同期 - ボイスチャット – モ ノビットエンジンクラウド ■モノビットエンジンHoLolensデモ
- 89.