search

vrm-c / vrm-specification

vrm specification
244 stars 37 forks source link

VRMの事実上のサブセットが乱立し可搬性が悪いためサブセット規格が欲しい #217

Open Narazaka opened 3 years ago

Narazaka commented 3 years ago

VRMをアバターとして利用する各サービスが個別に制限を設けているため、VRMが目指すべき可搬性を満たしていないと思います。（現状3D界のJPGではなく、せいぜい良くてPSDかなという体感です）

VRMはこれらが出来ずに制約のあるアプリ利用そのものが出来ないので、可搬性が低いです。 （VRMにそれら制約を設けた事実上サブセットであっても現状「VRM対応」と名乗れています）

JPGの圧縮率変更やサイズ変更、PSDの互換出力に相当する容易に利用可能な「変換」があればこれは解消できると思いますが、十分フレキシブルな変換は現状（ユーザーが簡単に利用できる実装が無い以上）難しいのではと考えられるため、サブセット規格のようなものが有れば多少状況は改善されるのでは無いかと思います。

究極は「変換技術が欲しい」という話なのですが、サブセット規格策定が現状できる選択肢の一つかなと思ったので仕様の方に立てました。

（あまり3DやVR技術には詳しくない1ユーザーとしての所感なので的外れかも知れませんが一応……。）

infosia commented 3 years ago

同感です。我田引水ですが似たようなニーズから #214 にて、 VRM 作成に使われたオリジナルデータに対して破壊的変更をしないようにという提案をしています。破壊的変更をしないことでメッシュの削減など自動変換をかける際にも役立つではないかと思っています。

サブセット規格に関してですが VRM 1.0で MSFT_lod という複数の Levels Of Detail (メッシュのクオリティ）をひとつのファイルにまとまられる機能について話題にはされていた気はします。 MSFT_lod だとファイルサイズが増える欠点があるので個人的には自動変換を推します。

これまた我田引水ですが自動変換に関しては SEED などでやっている メッシュ削減と似たようなことを拙作 vrmpack で実現できることを確認しているので、こういうものを各種サービスで独自に実装するのではなくて VRM-C として標準実装を提供してユーザ側もしくはサービス提供側で簡単に削減してもらえるようにできるといいのかもしれません。

xanxys commented 3 years ago

制限乱立問題について、弊社のサービス(cluster)の制限 ( https://clusterhelp.zendesk.com/hc/ja/articles/360029465811 )は問題の筆頭であると認識し、かつ改善したい領域と考えています。なので、現状の考えを表明しておきます。

まずVRMの変換(以下reductionと呼びます)技術が十分であれば、各サービスが制限を撤廃することで互換性が保たれるという考えには同意します。reduction技術をエコシステム全体として洗練させていくことはクリエイターの負担を増やさず、多様なプラットフォームでユーザーがアバターを利用できるためには必須であると考えています。

実はclusterでもVRM reduction技術の開発中で、現在の制限についても緩和する見通しがあります。

その上で、reduction技術が成立し発展してくため、VRM仕様としては以下が担保されているべきと考えます。

その上で、reducerのreference実装が公式に提供されているのは望ましいとは思いますが、必須だとは思いません。 (VRM利用サービス・アプリケーションによって、対応したい性能レベルやOS、サービス形態上保証しないといけない特性が異なるため、一元的に「実際に使える」レベルのものを提供するのは実現性が低いと想定します。)

上記が実現された状態でも、各種パラメーターの制限について値の組み合わせがひとつ標準として定義されて、それによって「対応」を名乗っていいか、より具体的には上記bのデータセットがその目安で作られていて提供されていると好ましいと考えています。

infosia commented 3 years ago

実はclusterでもVRM reduction技術の開発中で その上で、reducerのreference実装が公式に提供されているのは望ましいとは思いますが、必須だとは思いません。

素晴らしいことなのですがこれはつまり VRM エコシステムを構成する主要メンバーであるところの VRoid、SEED ONLINE、cluster の各サービスがそれぞれ別の reduction を実装していることになるということで...こうなると何か各社フィードバックをして公式実装が可能なのではないかとか期待してしまいます :sweat_smile:

Narazaka commented 3 years ago

リダクション、どちらかと言えば現状サービス上で勝手に行うという流れを感じていますが、ユーザー側で自由に使えるとより用途が増えて（例えば自作ゲームなどにも使える）良さそうだと思いました（jpgはそう）。

infosia commented 3 years ago

cluster が LOD に対応したということで感服して 色々見てみているのですが 例えば 3万ポリゴンのモデルを 2,000 とかに自動で落とすとかはアルゴリズムではなかなか厳しいのかなという印象を持ちました。。モデルの形状を崩さずに削減するのは例えば vrmpackだと 3万→5,000くらいが限界という印象です。 VRM に MSFT_lod があるといいのかもしれないですね。

xanxys commented 3 years ago

CPU・ネットワーク・システムメモリ・ストレージが潤沢(ほぼ無限)で、GPUメモリだけ限定されているという環境が主な対象ならMSFT_lodは結構歓迎なんですが、実際にはすべて制限があるので、もっと先送りできる方が嬉しいですね…

MSFT_lodの導入意図としては、アバター作者(もしくは編集ツール作者)の手間と引き換えに、ユーザーが最終的な見えをコントロールできるということだと思ってます。が、複数のLOD levelが含まれてるひとつのVRMをそのまま配信・クライアントで展開したら当然パフォーマンスは今より悪化するので、VRMを分割して配信するシステムやVRMの部分的遅延ロードが必要だと思ってます(後者はUniVRMやその他importerの内部構造の大幅な複雑化を招くと思います)。

分割した場合でも、たとえばLOD levelが10個あって距離ごとになめらかに10回切り替えるのは(ネットワーク・メモリ・CPUが潤沢な環境じゃないと)かなり厳しいので何かしら間引く必要があって、

の問題があるので、MSFT_lodを導入するだけで何かが解決するという気はあんまりしてないです。 (cluster的には、今提供してる2K trisのreductionの継続的改善に加えて、もっとゆるい(5K~10K trisぐらいの?)LODレベルを間に自動生成することで十分な品質が達成できると期待してるので、そこを完全に諦めるまではデータ形式の複雑性が増す判断は保留してもらえるとありがたいという立場です。)

infosia commented 3 years ago

そうですね、10 段階の LOD level となるとしんどそうですが例えば容量の大半を占めるテクスチャを共通化させる前提で 3,000 tris など最低限表示が崩れないレベル１つだけにするというような縛りにできれば、MSFT_lod もそれほど非現実的ではないのかなあという印象を持っています。例えば手元の VRoid モデル (35,000 tris 26MB) からマテリアルを削除して 4,000 tris 程度に落とした glb を作ってみたのですがファイルサイズは 1MB ほどでした。独立した glb ファイルでこのサイズなので実際にはもっと削減できるのではと期待しています。

とはいえ、MSFT_lod 対応は今より圧倒的に複雑になると思いますし、仮にハードウェアやロジック等の改善で 5,000 tris 程度に自動リダクションできるのであればそれが一番良いと思います 😄

yakumo-proj commented 3 years ago

できることなら各プラットフォームごとにブラックボックス化せずにユーザーサイドで調整できる形が良いなぁ と思ったり。 3DアバターのJPEGを目指しているのであれば、編集ソフトがUnityみたいな開発者向けツールを エンドユーザーに使わせるのを要求すべきではないと思いますし。

本題ですが、特にテクスチャの解像度の変更などはサーバ側であまり勝手にやって欲しくないなというのが ユーザーの立場です。 clusterさんの話が出ましたが、2048pxから512pxにするときに必要だと思うのは、模様のディティールを 崩す「リサイズ」じゃなくて、残したい特徴を残す「デフォルメ」だと思います。 （たとえばノーマルマップで布地の凹凸面を表現しているような場合がわかりやすい例です）

たとえばPNGってデータ構造上、複数のデータチャンク持てますよね？ Windowsのico, MacやiOSのicns方式みたいに解像度の違う複数の画像を1ファイルにまとめられます。 PNGの登場当初から言われてたことみたいですが現状はマルチ解像度対応のPNGには有力なサブ規格も実装もない状態です。 そこで、リダクションを業界全体としてサポートする方針なら、VRMコンソーシアム参加企業で連携して マルチ解像度のPNGのサブセットのデファクトスタンダードを作ってしまっても良いのではないでしょうか。 たとえばclusterさんですと2048px用と512px用のテクスチャを纏められると便利かと思います。 （現状はイベント用の2048px版のVRMとワールド用の512px版のVRMの２データをアップロードして切り替えたりしてます）