composer中图层渲染顺序由结构树自上而下决定，顶部节点先绘、底部节点后绘并覆盖前者；父子绑定启用父级变换时子部件随父整体绘制；viewport与callout属ui层，恒居模型之上。
Composer 里多图层叠加的渲染顺序，就是结构树从上到下的顺序——不是“谁在前面谁先画”，而是“谁在结构树里位置靠上，谁就后绘制、压在最上面”。
图层顺序 = 结构树顺序，不是时间轴或视口顺序
很多人误以为拖动时间轴上的轨道、或者调整视口层级能改变显示叠放关系，其实完全无关。Composer 的渲染栈只认结构树（Structure Tree）里的节点顺序：
- 结构树顶部的节点最先被绘制，但会被下面的节点覆盖（即“后绘制者在上”）
- 右键某个零件 → “剪切”，再右键另一个父节点 → “粘贴为子级”，它就会出现在该父节点的最末尾（最下层），从而被其他同级节点盖住
- 想让标注始终显示在零件上方？把标注图层拖到结构树最底部（即最后一条）
- 导入多个 STEP 文件后自动排成一列，它们默认是平级并列关系；若未手动建立父子链，就不存在上下遮挡逻辑，而是按导入先后顺序从上到下排列
父子层级会强制覆盖渲染顺序，但仅限于“启用父级变换”的部件
一旦启用了父级变换（在零件属性 → 变换页签下勾选 Enable parent transform），子部件的渲染就不再独立参与全局图层排序，而是绑定到父部件的视觉空间中：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 父部件本身仍遵循结构树顺序；子部件则“寄生”在其内部，无论结构树里子节点排第几，都随父部件一起被整体绘制
- 常见陷阱：把一个高亮箭头设为某螺栓的子级，结果箭头总被隔壁电机挡住——因为电机在结构树里排得比螺栓父装配更靠下，所以电机后绘制、压住了整个螺栓+箭头组合
- 解决办法不是调箭头位置，而是把螺栓所在装配体整体拖到结构树中电机节点的下方
视口对象（Viewport）和标注（Callout）有独立渲染通道
Viewport 和 Callout 不走普通模型图层栈，它们属于 UI 层，天然高于所有 3D 零件：
- 四个四分屏视口即使结构树里排第一，也一定显示在所有模型之上；你无法用结构树顺序把模型“盖过”视口
- Callout 标注同样如此，但它受磁力线吸附影响——吸附生效的前提是它处于“自由状态”，且未被固定（
Fixed position关闭） - 如果标注文字被模型遮住，不是顺序错了，而是：
Anchor point设错（比如锚点在左下，但模型刚好在左下区域），或 Z 轴深度没调（磁力线不处理 Z 吸附）
动画轨道不影响图层顺序，但关键帧污染会间接破坏视觉一致性
时间轴上轨道的上下排列，对最终画面毫无影响。但错误的关键帧管理会让图层“看起来乱”：
- 多个零件共用同一段位移关键帧，但枢轴点没统一——有的绕原点转，有的绕质心转，视觉上像错层抖动
- 未删除未使用的关键帧，导致某些零件在空闲时段仍被强制计算位置/旋转，偶尔因插值误差闪现偏移
- 跨图层粘贴关键帧时结构不一致（比如目标图层缺
rotationZ属性），粘贴失败却不报错，结果只有部分零件动，其余静止，误以为是图层盖住了
真正决定“谁盖谁”的只有结构树顺序 + 父子绑定状态；其余所有操作——拖时间轴、调视口、改动画属性——都不改这一底层规则。最容易被忽略的是：当你反复剪切粘贴零件调整结构时，Composer 不会自动刷新视图缓存，必须按 F5 或切换视口才能看到真实叠放效果。
