Repository navigation
[Remote rendering 3.1] Server-authoritative state: per-part visual + variable state聽#18
Description
Activity
- addedtechnicalA User Story internal to development that identifies non-functional work such as a refactoringA User Story internal to development that identifies non-functional work such as a refactoring
on Aug 25, 2026 - added a parent issue
on Aug 25, 2026 Status
Added stacked PRs (listed below) for this user story. Currently these are all in draft mode before setting each as ready for review. Verified each manually, and CI/CD shows they all build, with all tests passing except for two regression tests.
(The two PRs that each have one failing regression test are 3.1d, which is where the behaviour change shows up on the client, and 3.1e, which bumps the persisted schema version to 1.1).
To do before setting as ready for review: add a section in each PR's description to provide any additional context where needed, and flag any decisions made.
PRs
- #50: feat: Remote rendering 3.1a - add per-part write path to the dataset registry
- #51: feat: Remote rendering 3.1b - implement per-part apply logic on the renderer and node pipeline
- #52: feat: Remote rendering 3.1c - register per-part triggers, serialize VTK access with lock, trigger payload validation
- #53: feat: Remote rendering 3.1d - route client per-part mutations through the server triggers
- #54: feat: Remote rendering 3.1e - source per-part state from registry on save and restore it on load
Copilot summary for the combined changes
This pull request implements a comprehensive "per-part" write and apply path for remote rendering, enabling fine-grained control of individual scene parts from the client through the backend, renderer, and node pipeline. It introduces new APIs, payload validation, and updates the renderer to support per-part operations like visibility, opacity, color, selection, and variable coloring. The changes also update the persisted viewer state version and improve model serialization.
Per-part control infrastructure:
- Added
ScenePartStateApiprotocol and corresponding trigger payload models tolocal_app.py, enabling type-safe, validated per-part operations (visibility, opacity, color, selection, variable coloring) from the frontend through the backend. Each trigger is validated and routed to the injected scene coordinator. - The scene is now injected into
LocalAppasscene_part_state_api, satisfying the new protocol for per-part operations.
Renderer and pipeline enhancements:
- Implemented per-part apply logic in
LocalRenderer, populating methods likeapply_visibility,apply_opacity,apply_diffuse_color,apply_selected,apply_color_variable, andclear_color_variableto mutate the appropriate actor or pipeline state. All methods handle unknown node IDs as logged no-ops.
Model and serialization improvements:
- Updated
VisorVariableStateto explicitly includearray_name,type, andnum_componentsfields, and added a serializer to emit the enum's wire value fortype. - Bumped the persisted viewer state version from "1.0" to "1.1" in
PersistedViewerStateV1.
馃摑 Description of the feature
Sync back per-part visual and variable state ownership to the server. This is the first of several user stories to state inversion. Each property class is independently testable by clicking a UI button and seeing the result. Establishes the trigger pattern that all subsequent stories follow.
Visibility, opacity, diffuse color, edge visibility, color variable mapping (the per-part reference: variable ID + component + range, see note), and selection highlight become server-authoritative mutations through
VtkNodePipeline.TheiaSceneBaseholds the canonical per-part state store (VisorDatasetRegistry).LocalAppregisters the corresponding trame controller triggers so the frontend can call them.Client no longer reapplies the per-part visual and variable state after local_view.update() is called.
Note: this story makes the per-part reference to a color variable server-authoritative, not the lookup tables themselves. Between this story and Story 3.6, the references resolve against the client-held default lookup tables, which is sufficient because those defaults are static. User-modified lookup tables become server-authoritative in 3.6.
To add further detail in backlog grooming
Acceptance Criteria
馃挼 Business Value
No response
馃敆 Useful links and references
No response