ansys / ansys/Visual-Interactive-Simulation-Object-Renderer
[Remote rendering 3.5] Server-authoritative color variable lookup tables
- 主要语言
- Python
- 星标
- 0
- 派生
- 0
- 平均合并
- 1 天 10 小时
- 30 天内合并 PR
- 37
描述
### 📝 Description of the feature
**Intent**: The lookup table backing each color variable, the color mapping itself rather than a part's reference to it, becomes server-owned. This is the last piece of the state to invert.
**Context**: Story 3.1 makes each part's reference server-authoritative: which color variable it uses, which component, over what range. the lookup table that reference resolves against still lives client-side on the wasm path, so the server cannot reconstruct what a scene actually looks like, and a user-modiifed color mapping is lost on reload. `RuntimeAppState` reserves a slot for this; this story fills it.
Also move component selection from the mapper to the lookup table (`SelectColorArray(name)` plus `VectorMode` / `VectorComponent`), which is required for magnitude coloring of vector variables. The serialized reference can stay as it is, since `component: -1` already means magnitude, but decide whether to keep that sentinel or mirror VTK's two-field shape.
---
**Known risk**: the lookup table sync issue: On the round-trip spike branch, the LUT state failed to reach the renderer correctly: the framework's client-side cache applied a stale snapshot instead of the state the server delivered. It was diagnosed as a framework-level issue, with no viable local workaround, and has not been retested since.
What kept this from being an issue on `main` is that the client rebuilds its own LUT on every color change, which creates a fresh object (and object ID) every time, and the framework's stale cache is keyed on object ID. This story removes that, so this is the story that creates that condition; it is therefore expected here. See the first comment below for more details on diagnosing the issue.
If we do encounter a similar issue in this user story, it can be deferred until 6.2 [to add link to user story once it's created] - where we retest after bumping the vtk-wasm and trame-vtklocal versions to be current (we are currently a major version behind on both dependencies). Defer by leaving the client owning its own LUT on the wasm path, which is what `main` does today. The spike branch tried making the server own the LUT state and adding a client-side reapply to compensate; this did not reliably work, so is not a recommended stop-gap.
The remote rendering work that follows in Phase 4 and Phase 5 is not dependent on the present user story.
### Acceptance Criteria
- Color LUT is applied on the server side, so on a refresh or reconnect, the LUT is preserved.
- No in-visualizer differences from main.
### 💵 Business Value
_No response_
### 🔗 Useful links and references
_No response_
贡献指南
调研方向
Start with RuntimeAppState and the current client-owned LUT path on main, then compare it with the round-trip spike branch and the mapper/lookup-table responsibilities. Move component selection with SelectColorArray(name), VectorMode, and VectorComponent while checking the known framework cache behavior. Done means the server-applied LUT survives refresh or reconnect and produces no visual differences from main.
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- python, wasm
- 领域
- backend, computer-graphics
- Issue 类型
- 功能
- 难度
- 5/5
- 预计耗时
- 一周以上
- 活跃度
- 活跃
- 描述清晰度
- 基本清楚
- 新手友好度
- 35/100