Narazaka::Blog

奈良阪という人のなにか

お金を払いたい「タイトル」「フレーズ」のメモ

タイトルだけに対してお金を払いたくなる素晴らしい価値を感じているタイトルのメモ 一応精一杯言語化した理由も記しておく。まあ、理解不能かも知れないが。

前のブログでも書いていたのだけど、今後はこちらを更新していく。 お金を払いたい「タイトル」のメモ-奈良北部のなにか

イリヤの空、UFOの夏

夏の空、彼方のUFO、そして不思議で澄んだ響きの「イリヤ」。

目にした背表紙、青色の背表紙、イリヤの空、UFOの夏

内容の名作感のバイアスはあるが、しかしやはりこのタイトルだけで、何処にも無い情景がありありと目に浮かぶ……。

キスよりさきに恋よりはやく

f:id:narazaka:20200320191643p:plain
a

これ以上に圧倒的に「速い」感覚を得る表現を自分は知らない。

キスより先に恋よりはやく(なんなのか)、というところが述べられておらず、しかも一意に想像も出来ないところがまた詩情を感じさせて良い。

オープニングの曲がまた最高に良く、あんばい良い映像とも相まって中身も途方もない名作なのではという(どう見ても錯覚である)印象を受けてしまうので困る。

18禁ゲームのサイトです→)キスよりさきに恋よりはやく

ホニャららMAGIC

「ららマジ」の「らら」が「ほにゃらら」の略だと知った時の衝撃たるや。

「ほにゃらら」をタイトルにつけ、「ららマジ」と略するセンス、底知れない天才の所業に思える。

「タイトルだけでお金を払いたくなる」という感情を発見する発端になった偉大なタイトル。

raramagi.wrightflyer.net

アリスと蔵六

この圧倒的にきれいな対比、かのシンプルでこれ以上無い的確なロゴ、タイトルだけで本質的な面白さを悟ったとさえ思える。

表紙も相まっていっそう極まる、素晴らしいタイトル。

www.comic-ryu.jp

暁に響く3 埼玉異動編

DLsiteで見つけた艦これギャグ系一般同人誌のタイトルなんだけども、一瞬で魅了された。

艦これのネタを分かっている前提の体感にはなるが、タイトルだけで中を確認せずにはいられないパワーがある。即DLした。

www.dlsite.com

(2018年1月追記)

この声好きかもよ?

f:id:narazaka:20200320185956p:plain
この声好きかもよ?

VTuber配信アプリREALITYのユーザーEMA氏が毎回つけている配信タイトル。

ようは新規視聴者への訴求文言なわけだが、配信で実質メインとなる声にフォーカスをあて、その中の配信から直接問いかけられているかのような軽妙で親しみのわく魅惑の言葉。

既存視聴者にも「そう、その声が好きなんだ」という共感が毎回わく、素晴らしいセンスの最高タイトル。

twitter.com

(2020年3月追記)

(その他良いタイトル等)

VRChatボイチェン勢がOculus Questを出先で使う方法(雑

最高便利VRバイスであるOculus Quest。 年末年始に実家に帰るけどVRChat入りたいなーとかいうときにもこれ一台あれば完璧じゃん!と掛け値無しに言える無敵デバイスです。

ただし地声勢ならば。

Oculus Questは外部マイク入力がどうやらできない(イヤホン端子、USB OTGともに無理)ため、外部ボイチェンを使ってVRChat Questに突っ込むという手段が使えず、ボイチェン勢やゆかりねっと・ボイスロイド勢には厳しい環境です。

しかし色々調べた結果、Virtual Desktopを使ってマイク音声をPCにバイパスし、PC上でボイチェンをかけてPC上のVRChatをやるという方式が使えることが分かりました。

一時期 Oculus ストアから削除されるとかどうとかで話題になったご存じSteamVR環境をQuestでプレイできる「Virtual Desktop」ですが、

  • どうもインターネット越しにでもPCにつなげる
  • マイク音声をPC側にパススルーする機能がある

という感じの模様。

というわけで

  1. Oculus QuestでVirtual Desktopを購入
  2. PCにSideQuestを導入
  3. Oculus QuestにSideQuest経由でVirtual DesktopのSteamVR対応apkを突っ込む(ここまでVirtual Desktopで紹介されているインストール手段)
  4. Virtual DesktopでPC側Steamに繋がるように設定しておく
  5. 家のPCをつけっぱなしにしたまま実家に帰る
  6. 実家のWifi越しにVirtual DesktopでPCにつなぐ
  7. Virtual Desktopの設定項目にMicrophone passthroughという項目があるのでオンに……しようと思うけどできない
  8. PC側デスクトップ画面を見て設定→システム→サウンドサウンドコントロールパネルで録音側の項目を見ると「マイク(Virtual Desktop Audio)」というのが無効になっているのが見つかる
  9. それを右クリックなどから有効にすると設定項目のMicrophone passthroughがオンにできた
  10. 「マイク(Virtual Desktop Audio)」をマイク扱いしてボイスチェンジャーに通してからVRChatに出す設定をする(多分ボイチェンルーティング中のいつも使っているマイクデバイスを「マイク(Virtual Desktop Audio)」に変更するだけ)
  11. SteamVR画面に戻るとボイチェンできてる!やったね!
  12. しかしOculusのメニューを出したりデスクトップ画面に戻ったりするとなぜか「マイク(Virtual Desktop Audio)」が無効、「Microphone passthrough」もOFFになりONにできなくなっている。
  13. そうなったらまた9から手順を繰り返してボイチェンをオンにする

という感じで実家からボイチェンしつつVRChatに入れました。後半いちいち面倒くさい手順がありましたが、なんとかなりました。Virtual Desktopのおかげです。本当に良かった。

ALVRもマイクパススルー機能自体はあるらしいのでできるのかもしれません。ちょっと調べてないので分かりませんが、分かる方は記事とか書いていただけると。

とりあえず雑にできるよ~と言っただけでおわり(また実家帰るときに見直そう)。

ちなみにこれはQuest使いながらPC必要な方式ですが、そもそも家にPCないよ~と言う人は(元々ボイチェン勢では確実にないだろうけど)クラウドでPCを使うという手もあるらしいですね。別件ですがそういう記事を貼っておきます。

suna.hateblo.jp

Blazor+Electron.NETでクロスプラットフォームGUIを作った時のメモ

Blazor Advent Calendar 2019 の記事です。

今年VRChat Advent Calendarにしか参加してなかったのでソフトウェアっぽいやつも書いてみたくなったやつ。

WinForms(Mono)は衰退しました

最近MacがCatalinaになって32bit対応を切りましたよね。これにより、MonoのWinFormsでだましだまし動かしていた拙作OSSGUIが死亡しました。

f:id:narazaka:20191224003049p:plain
Macはクソ

やや試行錯誤したんですがMonoがそもそもWinFormsにやる気がなく64bit対応は死んでいる臭いので、Windows Formsワンソースでのクロスプラットフォーム対応はあえなく死亡しました。

今最高に面妖なGUIフレームワーク

というわけでせっかくだから.NET 4.6だったのを.NET Core 3.1にしたうえでLinuxMacで動くC#GUIライブラリを探してみたんですが、AvaloniaもEto Formsもドキュメントスカスカでハマったし、Xamarin FormsはLinux/Mac対応公式でなくてVisual Studioでやるの面倒そう……。

WebエンジニアなのでこれはElectronでCLIを叩いた方がましかなと思ったところで出会ったのがElectron.NET。なんでもASP.NETサーバーをローカルで立ち上げ、ページをElectronでレンダリングして無理矢理GUIにするという面妖な技術とのこと。

さらにSPAできたらな……と思ったところで行き当たったのがBlazor。こちらもASP.NETサーバーがレンダリングした結果をフロントHTMLにシームレスに反映することでサーバーサイドC#でSPAができるという面妖な技術とのこと。(wasmにしてクライアント動作というオプションもあるらしいですが、プレビューとのことだったのでいいかげんハマりたくない気持ちから今回は回避しました。)

ブラウザフロントエンドのビューにC#コードを書いてラップし、それをWebsocketで無理矢理通信してサーバーレンダリングSPAする黒魔術Blazorと、ASP.NETサーバーを一般ユーザーPCで動かしてかつChromeバイナリも.NET Coreランタイムもドーンと配る富豪の極みのようなElectron.NETの夢の共演。

そういう魔術的体感大好きなので、最高の面妖開発体験が得られると期待して開発して、……結果的にちょくちょくハマりつつも案外すんなりGUIができました。

これのseedtable-eguiというプロジェクトがそれです。

github.com

seedtableライブラリ(CLIとしても動く)を参照して、そこのインターフェースを叩くGUIフロントエンド的なアプリです。 Windows Forms製のseedtable-guiから設定画面を省いた感じの機能体系ですね。

f:id:narazaka:20191224030348p:plain
ElectronとASP.NETで動いている面妖な産物
f:id:narazaka:20191224030600p:plain
Macでも動くよ

Blazor+Electron.NETでクロスプラットフォームGUIを作った時のメモ

というわけで、Blazor+Electron.NETのアプリを作れたんですが、技術の見た目がヤバいせいか少なくとも日本語資料では「dotnet newしてElectron.NETの最低限コード書いて立ち上げてみたよ!」という感じの記事しかありませんでした。

……いや、そもそもElectron.NET単体についてのやつも少ないですね……。みんな面妖技術は嫌いなのかも……。

なので実際にBlazor+Electron.NETで小規模なクロスプラットフォームWindows/Linux/MacGUIアプリケーションを組んだときにぶち当たった事についていくつか書きます。

なお導入自体は以下の記事が示している通りです。意外にもとっても簡単お手軽。

qiita.com

ちなみにASP.NETがどう動かされているのかは分からないんですが、とくにファイヤーウォールの許可などは必要ありませんでした。 地味な懸念がなく普通のアプリと同じように配布できるのはうれしいですね。

Electronのファイルダイアログなどを使いたい

Electron.NETとBlazorの組み合わせで最も使うと思われる箇所ですね。

JavaScriptとのインターフェースとしてIJSRuntimeという物が用意されており、これを使います。

docs.microsoft.com

C#からJSの関数を呼ぶ時には、まずrazorファイルでIJSRuntimeをDIで注入し、

@inject IJSRuntime JSRuntime;

InvokeAsync()を呼べば良い模様。

JSRuntime.InvokeAsync<OpenDialogResult>("showOpenDialog", option);

オプションについてはこのようにclassを定義しておくと良い感じにJSのオブジェクトと相互変換してくれます。

using System;
using System.Collections.Generic;
using Newtonsoft.Json;
using Newtonsoft.Json.Serialization;

namespace seedtable_egui.Data.Electron {
    [JsonObject(NamingStrategyType = typeof(CamelCaseNamingStrategy))]
    public class OpenDialogOption {
        public string Title { get; set; }
        public string DefaultPath { get; set; }
        public string ButtonLabel { get; set; }
        public IEnumerable<FileFilter> Filters { get; set; }
        public IEnumerable<string> Properties { get; set; }
    }

    [JsonObject(NamingStrategyType = typeof(CamelCaseNamingStrategy))]
    public class OpenDialogResult {
        public bool Canceled { get; set; }
        public IEnumerable<string> FilePaths { get; set; }
    }
}

よく使う関数については拡張メソッドにシテオクと便利だと思います。

using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Microsoft.JSInterop;

namespace seedtable_egui.Data.Electron {
    public static class JSRuntimeExtensions {
        public static ValueTask<OpenDialogResult> ShowOpenDialog(this IJSRuntime js, OpenDialogOption option) {
            return js.InvokeAsync<OpenDialogResult>("showOpenDialog", option);
        }

        public static ValueTask<SaveDialogResult> ShowSaveDialog(this IJSRuntime js, SaveDialogOption option) {
            return js.InvokeAsync<SaveDialogResult>("showSaveDialog", option);
        }

        public static ValueTask ShowErrorBox(this IJSRuntime js, string content = null, string title = "エラー") {
            return js.InvokeVoidAsync("showErrorBox", title, content);
        }
    }
}

こうすれば

@code {
    async void OpenSeedPath() {
        var result = await JSRuntime.ShowOpenDialog(new OpenDialogOption {
            Title = "seedフォルダを開く",
            ButtonLabel = "開く",
            DefaultPath = SeedPath,
            Properties = new string[] { "openDirectory" },
        });
        if (!result.Canceled) {
            SeedPath = result.FilePaths.FirstOrDefault();
            StateHasChanged(); // JSRuntimeを使った際にステートが変わる場合はこれを叩かないとビューが更新されないです(ハマりどころ)
        }
    }
}

という感じでJS意識せず気軽に呼べます。

_Host.cshtmlに呼ばれるJS側関数を書いておきます。

    <script>
        const { BrowserWindow, dialog } = require('electron').remote;
        function showOpenDialog(options) { // 「開く」ダイアログを呼ぶ
            return dialog.showOpenDialog(win(), defaultNull(options));
        }
        function showErrorBox(title, content) { // エラーダイアログを呼ぶ
            return dialog.showErrorBox(title || undefined, content || undefined);
        }
        function win() { // ダイアログに親ウインドウが必要なのでJS側でハンドリングする
            return BrowserWindow.getFocusedWindow();
        }
        function defaultNull(obj) { // C#側から渡ってくるオプションは存在しないプロパティにnullが入っているが、electronのAPIはキー無し(undefined)を期待しているのでエラーを吐く場合があります。それの回避。
            const newObj = { ...obj };
            for (const key of Object.keys(newObj)) {
                if (newObj[key] === null) delete newObj[key];
            }
            return newObj;
        }
    </script>

かなりシームレスにElectronと連携できます。

Macでアプリケーションが終了しない問題

クロスプラットフォームGUIを作るとき頻発する「Macで閉じるボタン押してもアプリケーション終了しない問題」。

閉じるボタン押したのにアプリケーションが残っている、かつそのアプリのアイコン押しても何も反応がない……という悲しい状態になってしまいます。

本家Electron的にはメインプロセス側でこの問題に対処するのですが、Electron.NETにはどうも正規っぽい対処法がなかったです。

Applicationのcloseをとる系の対処が全滅したので、Electronのウインドウが閉じるJavaScript側のイベントを拾うことにしました。

上記IJSRuntimeとは逆向きにJSからC#を呼ぶ方法としては、DotNet.invokeMethodAsync("アセンブリ名", "静的メソッド名");と言う方法があります。

いきなりアセンブリ名が出てくるあたり無理矢理感のあるAPIですが、とりあえずDotNetという定数がJSに自動で注入されており、そこから[JSInvoke]属性のついたpublicな静的メソッドを呼べるとのこと。

_Host.cshtmlに

    <script>
        const { BrowserWindow, dialog } = require('electron').remote;
        function win() {
            return BrowserWindow.getFocusedWindow();
        }
        win().on('close', function(e) { // Electronのウインドウが閉じるとき
            DotNet.invokeMethodAsync("seedtable-egui", "OnClose"); // C#側のseedtable-eguiアセンブリ内の静的メソッドOnCloseを呼ぶ
        });
    </script>

Index.razorに

@code {
    [JSInvokable]
    public static void OnClose() {
        ElectronNET.API.Electron.App.Quit();
    }
}

と書いて事なきを得ました。(たぶんOnCloseはビューではなく別の普通の静的クラスに書くのが本来だと思いますが、JSInvoke属性が定義されている箇所を見つけるのが面倒だったので……)

razorデバッグできない問題

electronize startで単純に立ち上げるとVisual Studioデバッグできないっぽいです。(アタッチの設定書いていないので当たり前ですが……)

正直今回は小さいアプリ&既存の移植品だったためそんなに必要なく、そのままカンとprintfで済ませてしまいました。

ここ何か方法あるようなら誰か知見を書いてください。

「アプリケーションのフォルダ」がresources/binになるかも

ユーザーに直接見えるのはElectronを立ち上げるexeですが、Blazorが動いているのはASP.NET Coreのサーバー側です。

.NET Coreの1ファイルexeパッケージングなどに備えたPath.GetDirectoryName(System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName);等の手法では、サーバーDLLがあるresources/binになってしまう模様。

Application.StartupPathだとメインのexeパスになったり……するかな?(試していないです)

パッケージングの問題

electronize buildにまつわる問題

WindowsではMac OS X用ビルドができない

できないらしいです。これは回避不能っぽいのでMacを買うか、TravisMacビルドに投げましょう。

Linuxビルドだとサーバーしか吐かれない?

なぜかelectronize build /target linuxしてもresources配下のサーバー側しか吐かれず、electronのエントリポイントが吐かれないという現象に見舞われました。

electronizeから叩かれた時のelectron-builderだけなぜかそういう風に動いている模様だったので、

cd seedtable-egui
electronize build /target linux
cd obj/desktop/linux
npm install electron@7.1.2
npx electron-builder . --config=./bin/electron-builder.json --linux --x64 -c.electronVersion=7.1.2

と言う具合に、electronizeでサーバのpublishしてから、その中間フォルダで改めてelectron-builderを実行することでパッケージすることとしました。

原因はよく分からないのですが、応急処置は可能です。

パッケージングにめちゃくちゃ時間がかかる問題

デフォルトの設定だとWindowsインストーラー、LinuxがAppImage、Macdmgなどとなっているんですが、これがとにかく遅い。

圧縮あたりをJSでやってたりするのかもしれません。インストーラーなどが必須でないならば、ここは"dir"で出してzipコマンド等で固めるのが速くて良いです。

electron.manifest.jsonの"build"がそのままelectron-builderに渡されるオプションのJSONになるので書いてゆきましょう。

{
  "executable": "seedtable-egui",
  "splashscreen": {
    "imageFile": ""
  },
  "singleInstance": true,
  "build": {
    "appId": "net.narazaka.seedtable-egui.app",
    "productName": "seedtable-egui",
    "copyright": "Copyright © 2019 Narazaka",
    "buildVersion": "4.0.0-rc4",
    "compression": "maximum",
    "directories": {
      "output": "../../../bin/Desktop"
    },
    "extraResources": [
      {
        "from": "./bin",
        "to": "bin",
        "filter": ["**/*"]
      }
    ],
    "files": [
      {
        "from": "./ElectronHostHook/node_modules",
        "to": "ElectronHostHook/node_modules",
        "filter": ["**/*"]
      },
      "**/*"
    ],
    "win": {
      "target": "dir"
    },
    "linux": {
      "target": "dir"
    },
    "mac": {
      "target": "dir"
    }
  }
}

注意: electronize initなどのコマンドはプロジェクトのフォルダで実行すること

地味ですが、VisualStudioで作ったソリューションの中にElectron.NET環境を作る場合、electronizeコマンドはソリューションではなくプロジェクトのフォルダで実行してください。

でないとstartやらbuildやらがエラります。

まとめ

ちょくちょく問題はありましたが、正直ほとんどElectron.NETだけの問題で、特にBlazorは流石Microsoft謹製だけあってかなり隙のない作りで、正直予想外に安定感が感じられました。

Electron.NETはそういう意味でやや荒削りな所がありましたが、こちらもまあまあ回避可能です。

正直もっと手こずるかなと思っていたところ案外スムーズにいってしまったので、面妖技術に抵抗ない方には結構お勧めかもしれません。 見知らぬフレームワーク固有のXAMLタグいちいち使い方調べて書くより見知ったHTMLでバインディングできるのやっぱり良い。

github.com

ソースサンプルとしては、この中のseedtable-eguiプロジェクトが

  • サーバーサイドBlazor
  • Electron.NET
  • 他プロジェクト参照
  • Windows/Linux/MacのCIビルド

を含んだものなので、ざっくり参考になるかもしれません。

Blazor+Electron.NET、案外イケるよ!やっていこう!(雑

ついでに宣伝

github.com

seedtableは二次元データを格納したxlsxファイルとYAMLファイルの相互変換ツールです。 データはYAMLでgitフレンドリーにしつつ、その編集はExcelで快適にしたいというユースケースに使えます。

スマートフォンゲームの運用の辛みを救うために作ったツールで導入実績もあるので、興味があればどうぞ。

またBlazor+Electron.NETほどではないかもしれませんが、seedtableにはMotif*1の.NETバインディングWindows Forms仕立て)という面妖技術によるGUIもあります(漁港などに出没するらしいsazae657さんが作ったものです)。

github.com

Blazorのような心がわくわくする謎技術に興味がある方はこちらも触ってみても面白いかもしれません!(雑

*1:1989年から続くX Window System用のGUI規格およびウィジェットツールキット(GTKみたいなもの)

VRChatが見せた「VRソーシャル」の今後について

VRChatterとしてLavenderVRに入ってみるというクロスVRSNS体験をしてみて雑に思ったことがあるので書いてみる。

VRSNS体験の普遍性

VRChatの提供した極めて自由度の高いVRSNS体験というのはかなり普遍的というか、もはやWebブラウザをずっと開いてブラウジングしているという体感に近いものがある。

その中に拙いとはいえ談話室もたばこ部屋も飲み屋もキャバクラも自宅も別荘も神社も廃墟も将棋も囲碁もオセロも麻雀もマイクラもBeatSaverも動画プレイヤーも鉄道も幼稚園も遊園地もサーキットも展示会も恋愛も結婚式もポルノもラブホもある。

もはやそこが「世界」であり、ブラウザで見る「インターネット」の体感と極めて近い(粗雑なUGCが乱立していて収益化がむずかしい点も含めて)。 特定タスクしかできないほかの特定VRコンテンツとはわけが違う。

f:id:narazaka:20191222220335p:plain
VRChatやめろ

「どのVRSNSプラットフォームを選ぶか?」

「どのVRゲームをやるか?」という問いは大体これまでの非VRゲームについて「どのゲームをやるか?」と問われるのとほぼ同じ体感だ。 しかし「どのVRSNSプラットフォームを選ぶか?」という問いはそれとは決定的に異なる。

VRChatが提供したVRSNS体験とはすなわちインターネットブラウジングの体験なので、「どのVRSNSプラットフォームを選ぶか?」という問いは「どの草の根BBS(クローズドネットワーク)に繋ぐか?」と問われているようなものになるわけだ。 その中には「世界」があるのに、どの「世界」を選ぶか?と問われるわけである。

パソコン通信ではなくインターネットを知っている我々としては、VRChatクライアントもLavenderVRクライアントもambrクライアントも、分断なく同じ「世界」をインターネットブラウジングできる単なる「ブラウザ」であってほしい。 それぞれで動くものが違うというのはこの際しょうがないので、せめて「IEFirefox、どっちのブラウザを選ぶ?」になってほしい。

そういう意味ではまさに実際のインターネットブラウザメーカーが推進している「Mozilla Hubs」などの取り組みなどが実を結んでほしいが、ブラウザでVRを見るというよりはブラウザはVRの中ではいちアプリケーションになるので、どう進むのかという方向性はなかなか難しそうだと思う。

VRM界隈が進めているTHE SEED ONLINEなども割とその辺を見据えているとしたらうれしいなといったところだ。海外なら認知がないのでしょうがないが、日本発のプラットフォームならもし対応しない場合はもはや速やかに衰退してほしい(あるいは同じようなベターなものを作ってほしい)という感覚さえある。

ちなみにこれは実際にAlt VRChatになる可能性が感じられたLavenderVRが出てきて感じたことだ。(アバターやワールドの移行がめんどいのなんの。これがVRM界隈の規格(アバター、ワールド、Prop)に対応してくれるとだいぶ楽になる気がするのだか……。)

VRSNSがブラウザ体験になるためには

さて、では今現在分断されたクローズド(ソーシャル)ネットワークを閲覧するVRChatクライアントとLavenderVRクライアントとambrクライアントで「インター(ソーシャル)ネットブラウジング体験」をするにはどうなるべきか?

ブラウザが、あるいはそもそもPCが快適に使えるのは、違うコンテンツを見るときに、「マウスカーソル」と「キーボード入力」が同じように使えるからだ。

当たり前のことかもしれないが、現在VRSNSアプリ相互では「「マウスカーソル」と「キーボード入力」が同じように使えること」に相当することができないのだ。

「マウスカーソル」と「キーボード入力」は非VRにおける身体性だ。「それがあれば行動(の入力)に不自由しない」電子空間内のツールセットなのだ。(CUIならマウスカーソルがいらない等のマイナーチェンジはありつつ、それもその状況での身体性だ。)

VRにおいては、この身体性は恐らく「アバター」と「持ち物」(Prop)になる。非VRにおける身体性が物理的には「手」のみのものであったところから拡大し、全身の没入になるのにあわせた別のツールセットになるわけだ。

つまりVRSNSを人間として快適に使うためには、これらの相互運用が必要となる。

そしてその「アバター」と「持ち物」という身体性を相互運用する担い手は、「マウスカーソル」と「キーボード入力」と同様に、「OS」であるべきだ。

これをOSがハンドリングしてくれれば、個別のVRアプリケーションはつまるところ、onClick(onInteract)をハンドルしてハイパーリンク(ポータル)で別のページ(ワールド)へ遷移すれば良いだけになる。

ハイパーリンクを叩く際にインテントが飛んで別のアプリが開くかもしれないが、それはスムーズに感じられるだろう。身体性が連続しているのだから。

VR元年Microsoftが腰を上げてから

というわけで本当のVRネイティブ体験はつまるところ、WindowsVR対応がついてからが本番となると思う。

OSのメーカーであってかつVRをOSの体験そのものに組み込む実験をしているのは、現在の所Windows MRなどでウインドウをVRネイティブで扱おうという試みをしているWindowsだけだ。

ブレイクスルーはきっとまだまだ先だと思うが、アバターを自然とOSに預ける時代はきっと来るだろう。

それを見据えて、今現在だけでなくこれからのVRの様々な相互運用フォーマットなどが発展していくことを願う。

ネットVRChatter奈良阪は、株式会社バーチャルキャストを応援しています(雑