[Remote rendering 3.2] Camera state persistence and sync-back
@LKasianAnsys がすでに取り組んでいます。
2026年9月3日 から。
評価
この issue はまだ評価されていません。
説明
📝 Description of the feature
Intent: give the server a persistent record of the camera, so save_state/load_state work and remote mode has a shared contract to build on. Today nothing on the server holds camera between saves; FrontendBridge pulls it from the client on demand at save time.
The goal is to ensure the server tracks camera state, not to change interaction. In local (vtk-wasm) mode the camera lives in the browser: orbit/pan/zoom manipulate the wasm vtkCamera and the browser renders each frame with the server outside that loop. This remains, and for continuous interactions it will continue this way. This story doesn't route the camera through the server, and doesn't make the server drive the gesture. The only change is that the browser reports the settled camera to the server on EndInteractionEvent, and the server stores it.
Further details on the full camera interaction mechanism are deferred until user story 6.4, where the local (vtk-wasm) mode round trip mechanism is designed.
For the present user story, the following is intended scope (added for context/intent not for the purpose of a concrete prescription):
- Replace the passthrough camera handling. On main, the server asks the client for camera only when it needs it (save time) and never maintains its own pipeline vtkCamera; this story makes the server apply the client's reported camera on EndInteractionEvent, into the real pipeline vtkCamera, not a side record (as it currently is).
- The point is to keep the server pipeline current so local_view.update() is non-clobbering; a fresh server camera means any update() (dataset change, state loaded, etc) carries the camera the client already has and doesn't jump the view; a stale one drags it back.
Acceptance Criteria
- Tests pass
- Behaviour is the same as it is on main
- On a browser refresh, the camera state is preserved (this is a side effect of the server applying the camera to its own VTK pipeline on sync-back or at load_state time)
💵 Business Value
No response
🔗 Useful links and references
No response
- 主要言語
- Python
- スター
- 1
- フォーク
- 0
- 平均マージ
- 1日 21時間
- マージ済み PR(30日)
- 47
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
ansys/Visual-Interactive-Simulation-Object-Renderer のほかの issue
-
難易度 3/5 1〜2日 初心者へのやさしさ 50/100
-
Library updates オープンtechnical
ansys/Visual-Interactive-Simulation-Object-Renderer#136 · 担当者 1 名 ·
-
maintenance
ansys/Visual-Interactive-Simulation-Object-Renderer#131 · 担当者 1 名 ·
-
Release 1.0.2 オープンmaintenance
ansys/Visual-Interactive-Simulation-Object-Renderer#130 · 担当者 1 名 ·
-
enhancement
ansys/Visual-Interactive-Simulation-Object-Renderer#126 · 担当者 1 名 ·
ansys/Visual-Interactive-Simulation-Object-Renderer の issue をすべて見る
似ている issue
-
agent-ready documentation needs-triage
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
-
documentation
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
-
workflow-status page template still says reusable workflows are "triggered only by workflow_call:" オープン
難易度 1/5 1時間未満 初心者へのやさしさ 92/100
-
instance instance add
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
searxng/searx-instances#939 · コメント 1 件 ·
-
area-deployment area-integrations triage:bot-seen
難易度 2/5 半日 初心者へのやさしさ 86/100