Alias Archiveアーカイブ更新中
アーカイブ更新中

舞台からデスクトップへ:画面と描画の分離

デジタル伴侶制作記07 / SERIES

デジタル伴侶制作記第7回。キャラクター表示、内容閲覧、入力、状態を分け、Unity接続の設計判断を整理する。

記録日
所属分野
その他
言語版
JA / 閲覧版

本稿は「デジタル伴侶制作記」の第7回である。前回までは記憶、音声、内容生成を扱った。次の課題は、それらをデスクトップ上のキャラクターへ移した後も、利用者が使える状態で保てるかだった。

八月の設計と引き継ぎ記録に基づく振り返りである。初期の移行案は、後のUnity接続総設計に置き換えられた。二つを混ぜて最終画面とすることはできない。引き継ぎでは一部のコンソール接続や修正を確認できるが、移行計画全体の検収を示すものではない。

メッセージの到着と機能の提供は違う

8月17日の点検では、多くのイベントを受信しながら、一部しか有効に処理していないことが分かった。画像、動画、入力の反映、録音状態などが、非表示のログ領域に入っていた。接続は続き、キャラクターも動くのに、その画面では内容が見えなかった。

「WebSocketは正常」という確認では、この故障を見落とす。イベントの到着から、利用者に見える結果まで追う必要がある。

移行一覧も、利用者の行動で書く。新着に気づく、画像を開く、入力して送る、録音状態を知る、音声を止める、後から読み返す。それぞれを観察可能な結果まで確認する。

キャラクターと閲覧画面を分ける

最初の案は、吹き出しの近くにメディアカードを出すものだった。後のUnity案では、キャラクター画面が姿、動作、短い通知を担い、画像、動画、履歴は独立した閲覧ウィンドウへ移った。

これなら、キャラクターの周囲にアプリ全体を常設しなくて済む。閲覧側も輪郭に合わせる必要がなく、一覧、ライトボックス、履歴を通常の画面で扱える。

入力欄、マイク、トレイ、コンソールへの入口も明確にする。透明部分はデスクトップへクリックを通し、実際の操作部は押せる必要がある。入力中はフォーカスを受け取り、閉じたら戻す。異常終了やフォーカス喪失後にも、見えない領域でデスクトップを塞いではいけない。

これらは検収する動作であり、透明ウィンドウにすれば自動的に備わる機能ではない。

描画を替えてもサーバーの責務は保つ

Unity案で置き換えるのはキャラクターの表示フロントエンドだ。記憶、会話、音声認識、音声生成、内容生成はサーバーが担い、Electronにはトレイと閲覧UIを残す。少数の互換エンドポイントと接続識別も追加するため、「サーバーを変えない」は、一行も変更しないというより中核の責務を保つ方針と読むのが正確だ。

この境界があれば、描画と透明画面、音声、入力、通知、調整という段階を踏める。全体を書き直さず、各段階で旧フロントエンドへ戻せる。

以前の事前レンダリング舞台やモデル変換手順も、履歴資産、対応表、復帰経路として保存できる。表示方法を替えるために、すぐ削除する必要はない。

複数クライアントの消費主体を決める

旧ページ、キャラクター、閲覧ウィンドウが同時に動くと、表示以上に危険なのは、副作用の重複や取りこぼしである。

責務記録された問題・設計条件確認する結果
音声サーバー再生済みの音声を新描画側で再生しない一発言につき一経路、中断も揃って終わる
再接続既存イベント列には連番も再送もない現在状態を取得し直して画面を揃える
未読キャラクターの接続は閲覧中を意味しない閲覧画面の状態に従って数え、解除する
蓄積メッセージ複数画面が同じキューを空にすると奪い合う決めた消費主体だけが空にする
モデル調整キーの違うモデルへの全体書き込みが設定を上書きするキーを照合し、必要なら名前空間を分ける

8月19日の追記には、未読や実行時モデル構造を扱うサーバー側経路の実装・実測がある。一方、Unity側の報告、表示、応答は、それぞれの段階で検収する必要がある。エンドポイントの存在だけでクライアントの動作までは証明できない。

二つのウィンドウが開いたことだけを成功とせず、切断、再接続、閲覧画面の開閉、モデル切替を行い、重複、欠落、上書きを確認する。

書き出せたモデルも対象環境で見る

VRChatからVRMへの変換記録では、ファイル生成は形式上の結果にすぎなかった。表情、瞬き、口形、材質、骨格、二次動作は、実際に使う環境で見る必要がある。

確認は二層に分ける。構造検査では参照の欠落や不正な値を調べる。見た目と動作では、中立顔、各表情、側面と背面、首振り、急停止、腕上げ、待機への復帰を確認する。要素数の大小だけでは合否を決めない。

物理の異常でも、すぐに揺れ骨の値を変えない。表示対象と既定の変形、スキニング、静止姿勢と制約を先に調べ、その後に物理と衝突を見る。別の故障を補正で隠すだけになりかねないためだ。

実行時専用の修正には境界を明記する。このデスクトップ側で直っても、別のビューアで開いた書き出しファイルまで直ったとは限らない。Unityでの直接描画とVRM変換も異なる経路であり、物理や材質の挙動を同一とは扱えない。

検収を一連の操作にする

この設計から引き継ぎたいのは、一段ずつ確認し、戻せることだ。

  1. 初期起動で姿が見え、透明部分はクリックを通し、操作部は動く。
  2. 一度入力し、反映、音声、口形を確認する。途中で止め、揃って終わるかを見る。
  3. メディアを受け、閲覧画面で開き、未読状態を確認する。
  4. 切断して戻し、状態が再び揃うかを見る。
  5. 旧版と新版を同時起動し、音声、蓄積、調整を奪い合わないことを確認する。
  6. 失敗した段階から、記録どおり旧版へ戻せる。

8月21日の引き継ぎには、停止指示の動作IDが固定され、切替時に止まる不具合を実際のIDへ合わせて修正した記録もある。最初の動作の再生だけでは、切替、停止、復帰の故障を見つけられない。

舞台からデスクトップへ移る過程で残すべきなのは、こうした責務と検収条件だ。次に表示フロントエンドを替えるときにも、システム全体がつながったかを判断する基準になる。

あわせて読む

03 / LINKS
C01

デジタル伴侶制作記:経過記録と全体目次

オープンソースのデスクトップ伴侶から出発し、2週間で自前のシステムへ至った記録。技術記事と、その後の移行を振り返る記事への入口でもある。

全文を読む ↗
C02

ブラウザを表示装置として扱う:ホスト非依存の舞台と三つの基盤戦

一つのAI伴侶をブラウザ、独立ウィンドウ、デスクトップ壁紙として同時に存在させる構成。ロジックをサーバーへ集め、ページを表示装置へ戻す。

全文を読む ↗
C03

服を選べる自撮りシステム:制御されたランダム性と画像・文章の整合

会話の空気に合わせてAI伴侶が自撮りを送る仕組み。権限を分層した装いエンジン、画像と文章を一致させる制約、能動的共有の境界、成功を返しながら参照画像を無視した二度のAPI障害を記録する。

全文を読む ↗