「序数 345 が見つかりません」 エラーで Franz や Rambox が起動しない問題

TLDR要約: MacType(多分ベータ版)が悪さしてた。
他の人が同じ症状にハマって検索した時のために記しておきます。

様々なメッセンジャーサービスをまとめるためFranzRamboxといったマルチメッセンジャーツールを愛用していたのですが、しばらく前から自分のWindows PCでそれらを起動しようとしたときに「序数345がダイナミックライブラリ<アプリのパス.exe>から見つかりません」というエラーが出て全く起動しないという状態に陥っていました。(Mac版は問題なく起動していたので、Windowsのみでの問題。)

Franzを古いバージョンにすると起動することもあるため、どうも一定以上のバージョンのElectronで動いているアプリが影響を受けてるようなのですが、他のElectronアプリでは動いてるものもありイマイチはっきりせず。Itch.ioのWindowsアプリがインストール後正しく動いてなかったのも関係あるかも。

「序数 345 見つかりません」とか”ordinal not found”とかで検索してまわってみると「sfc /scannowでスキャンしたら直った」とか「dism /online /cleanup-image /restorehealthで直った」とか出てくるものの、これらを試しても改善せず。

結果としては文字レンダリングのアンチエイリアスを改善するために入れてたMacTypeを外したら解消しました。別のPCでもMacTypeを入れててそちらでは問題なかったので見逃してましたが、どうも別PCではリリース版のMacType、影響が出ていたPCではGithubの最新ベータ版を入れてたのがまずかった模様。厳密にどのバージョンから問題が生じてたのかは未確認ですが、それくらいしか違いが思いつかないので。

日常的に使うVRへ: 使い始めやすさと使い続けやすさ

この記事はOculus Rift Advent Calendar 2018の20日目です。

技術や実装の話からちょっと離れて、ここのところ考えていた話を。

VR元年と囃し立てられた2016年から3年近くが経ち、最近は市場の伸びが期待したほどの勢いではないのではないかという声も聞かれます。その一方、日本では特に5月に発売されたOculus Goがその低価格から大きく注目され、同じスタンドアローン型の本命として来年発売のOculus Questに期待がかかったりもしています。

また、去年後半から今年にかけては施設型VRやVTuberなど、末端のエンドユーザーに対して直接VR機材の所有を要求しないユースケースも大きく注目を浴びました。本記事ではあえて、「いかにしてより多くの人にVR技術を直接所有し、使用し、更には使用し続けてもらうか?」という問題を、「使い始めやすさと使い続けやすさ」という概念から考えていきたいと思います。

Continue reading

Oculus Unity Integrationクロスプラットフォーム開発ドキュメンテーション 私家訳版

この記事はOculus Rift Advent Calendar 2018の4日目です。

はじめに

先日11月15日、Oculus SDKの一部であり、Oculus公式のUnity統合であるOculus Integration (Oculus Utilities for Unity)の最新版1.31が公開されました。このバージョンの大きな新機能が、Oculus Integrationを使ったままHTC Viveの動作がサポートされる、クロスプラットフォーム開発機能です。

以前からSteamVR SDKはViveにネイティブ対応しているのに加えRiftをサポートしていましたが、今回の対応により、Oculus側のSDKを使用した場合も、両方のヘッドセットに向けた開発が(少なくともUnityにおいては)可能になります。

前述の通りSteamVR SDKはViveとRift両方に対応していますが、問題なのが、SteamVR SDKを使用した場合はそのままではOculus Storeへの提出ができないという点です(その逆、つまり今回のOculus SDKのクロスプラットフォーム機能を使って実装したアプリをSteamに出すのは問題ないはず)。また、注目度の高いOculus Goや今後登場するOculus QuestはOculus SDKでしか動作しないため、これらにも対応したい場合いずれにしてもOculus SDKを避けて通ることはできません。もちろん、移植は色々な要素が絡むため、こういった機能があってもボタン一発とまではいきません。しかし、なるべく同じ機能の再実装を避けながら、PC・スタンドアローンを含む多くのプラットフォームに対応するという点においては、本機能は便利に使えるのではないでしょうか。

以下はOculusデベロッパードキュメンテーションのクロスプラットフォーム開発についてのページの私家版翻訳となります。2019/6/19追記: Integration 1.38に合わせて更新
Continue reading

Oculus Rift/Gear VRアプリでローディング画面の視界端に見える黒枠を別の色にする

Oculus RiftやGear VRのVRアプリにおいて、ローディング画面などでレンダリングがリフレッシュレートに間に合わず、Asynchronous Timewarp (ATW)処理で擬似的に生成されたフレームが表示されることがあります。このような時、ATWが前の絵の位置をずらしているため、ずれた分だけ表示領域の端に黒い枠が見えてきます。

現状こちらの色を一発で変更する方法はないのですが、Compositor Layerという機能を応用することで色を変えることが可能です。Oculus Utilities for UnityではOVROverlayというコンポーネント名、Unreal EngineではStereo Layersという名前で組み込まれています。

「Compositor Layer (Timewarp Layer)」はOculus SDKに内蔵されている、一部のオブジェクトを通常のレンダリングと別枠で、出力直前に合成して表示することができる機能です。Compositor Layerを使って表示できるものは板ポリゴン(Quad)やキューブマップ、円筒など形状が限定されます1が、レンダリングのフレームレートではなくコンポジターのフレームレートで動作するため、通常のレンダリングが間に合っていない時であっても常時滑らかに表示されます。(名前が似ていますが、Unityのレイヤー機能とは無関係です。)

例えばUnityでは以下のように:

  • Main Cameraの子としてQuadオブジェクトを作成(位置は0,0,0
  • Quadオブジェクトのマテリアルとして白一色の画像テクスチャ(ここではwhitesquare)を貼り付けたマテリアルを指定
  • QuadオブジェクトにOVROverlayコンポーネントを貼り付ける
  • OVROverlayCurrent Overlay TypeUnderlayCurrent Overlay ShapeQuadに指定。これにより、通常のレンダリングが行われていない(はみ出した)領域にのみ、このQuadが表示されます。
  • OVROverlayの中にあるTextures変数に先程と同じ白一色のテクスチャを2箇所とも指定する

こうすると、ATWで生成されたフレームが見えている間も、普段ならはみ出して黒い背景が表示されている部分に白いQuadが表示されるため、背景の色が白に見えるようになります。2
なお、挙動の確認のためにわざとレンダリングの処理落ちを起こすには、Update()内にSystem.Threading.Thread.Sleep(500);などを入れたコンポーネントをどこかに貼っておくと起こせます。

このほか、Compositor Layerは処理落ち中でもガタつかない注視カーソルの実装や、画質が高いことを活かしたUI/テキスト/画像などの表示、またそもそもローディング画面自体をCompositor Layerで作るといった使い方もできます。Compositor Layerについてより詳しくはこちら。

Unity: https://developer.oculus.com/documentation/unity/latest/concepts/unity-ovroverlay/
Unreal: https://developer.oculus.com/documentation/unreal/latest/concepts/unreal-overlay/


  1. 使える形状はPCとモバイルで多少異なります。QuadやCubemapは両方で利用可。 
  2. ただし、白色は人によってはチラツキを視認しやすくなるためお勧めしません。実際に変える場合は暗めの色をお勧めします。 

VPSをMondo Rescueでバックアップ

さくらのVPSで自分用Mastodonインスタンスを立てるまでのYak Shavingの記録…になるはずだが、まだ途中。

改めて見たらUbuntuのバージョンが14.04で古すぎたので、まず16.04にアップグレードするところから始める。
ディストリビューションアップグレード中にぶっ壊れるのは怖いので、まずはバックアップを取る。

これを参考にMondo Rescueでバックアップを取ることにする。
ただ、/etc/apt/sources.list.d/mondorescue.sources.listを追加してsudo apt-get updateしたところ、公開鍵が見つからないようで以下の警告が出る:

W: GPG error: ftp://ftp.mondorescue.org 14.04 Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 6BA8C2D220EBFB0E

検索してみたところ、Mondo Rescueメーリングリストで以下のやりとりを発見。
[Mondo-devel] [OT?] New keys for debian repository…

書かれている通り、以下の鍵を追加して解消。

gpg --recv-keys 8AB63AFD171EFF9E
gpg -a --export 8AB63AFD171EFF9E | sudo apt-key add -
gpg --recv-keys 6BA8C2D220EBFB0E
gpg -a --export 6BA8C2D220EBFB0E | sudo apt-key add -

無事Mondo Rescueがインストールできたので、早速バックアップを試みる。

sudo mkdir /backup
sudo mondoarchive -Oi -L -s 50G -d /backup -E /backup -S /tmp -T /tmp -p backup-20170417

途中で以下のエラーが出てバックアップが失敗する。

Mindi failed to create your boot+data disks.
Fatal error... Failed to generate boot+data disks
---FATALERROR--- Failed to generate boot+data disks
If you require technical support, please contact the mailing list.
See http://www.mondorescue.org for details.
The list's members can help you, if you attach that file to your e-mail.
Log file: /var/log/mondoarchive.log
Mondo has aborted.

ログファイル(/var/log/mondoarchive.log)を見たら、ディスクが足りない…?
HDD容量はまだガラガラのはずだけども。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
(略)
/dev/vda1        96G  7.3G   84G   9% /
(略)

調べたところ、足りてないのはHDD容量ではなく、MindiのRAMディスクの容量らしい。
[Mondo-devel] no space left on device error – mindi

Mindiの設定ファイル/etc/mindi/mindi.confで大きめのサイズを指定する。何回か失敗したが結局以下のサイズで成功。

EXTRA_SPACE=320152      # increase if you run out of ramdisk space
BOOT_SIZE=80960

先ほどと同じバックアップコマンドでバックアップが始まったが、長時間かかる中でSSH接続がタイムアウトしてしまい、接続切断に巻き込まれてmondoarchiveコマンドが終了させられてしまった。
改めて、途中で切れても大丈夫なようにtmuxでセッションを作り、その中で実行する。Ctrl-B dでセッションからdetach。数時間待って再度tmux attachでセッションに入って結果を確認。今回は成功。
Transmitで手元のMacにダウンロードする。

今日はここまで。