Skip to content

[Remote rendering 3.2] Camera state persistence and sync-back聽#20

Description

@margalva

馃摑 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

Activity

  1. added
    technicalA User Story internal to development that identifies non-functional work such as a refactoring
    on Aug 25, 2026
  2. added theissue type on Aug 25, 2026
  3. changed the issue type fromtoon Aug 26, 2026
  4. LKasianAnsys commented on Sep 16, 2026

    @LKasianAnsys
    Collaborator

    Added 4 PRs for the remote rendering 3.2 user story (camera state sync back to the server):

    • 3.2a: server-tracked camera: record, load-path write, and re-serialization (#110)
    • 3.2b: save state reads from server camera (#111)
    • 3.2c: attribute camera changes to the input that caused them (#124)
    • 3.2d: report settled camera gestures to the server (#125)

    In the first of those PRs, I encountered a failing regression test, and it turned out that it was a pre-existing bug in load_state on Linux. The same test passes on Windows. It looks like load_state may have never worked on Linux, while it works as expected on Windows.

    Wrote an issue tracking it here: #122.

    User story 3.6 (#24) is already set up for verifying that the full save/load state workflow works as expected once all state is server-authoritative. For now, I disabled the regression test, and it likely makes sense to address the bug in #24.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

technicalA User Story internal to development that identifies non-functional work such as a refactoring

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions