TiXL 图像合成变换ImageComposeTransform上下文机制设计解析让 UV 变换在整个纹理图内免费生效【免费下载链接】t3TiXL is an open source software to create realtime motion graphics.项目地址: https://gitcode.com/GitHub_Trending/t3/t3本文解读 TiXL 仓库.agentic/Plans/Plan_ImageComposeTransform.md中的工程计划如何在EvaluationContext上引入一个中立的ImageComposeTransform上下文字段让纹理消费型算子texture-consuming ops在采样/渲染时统一读取并应用它从而用一个TransformImage算子即可为其整棵子树施加偏移、缩放、旋转、镜像、染色、透明度与混合——全程零额外渲染 pass。读者将理解这套机制的完整设计默认值约定、参与规则、组合顺序、分批迁移策略、风险与缓解并结合仓库中EvaluationContext、现有TransformImage算子及其.t3配置、视频工作计划的上下文约定掌握其落地的技术路径与适用边界。注意该计划当前处于Drafted / Deferred草案、已延期状态文中凡属计划设想的内容均已明确标注。一、计划背景从视频合成工作中拆出的一项横向工程ImageComposeTransform计划源自视频工作Plan_VideoClipPlayer.md的延伸。视频计划为了支持多片段合成需要一种图像级上下文变换约定视频算子VideoClipPlayer的 blit、VideoClip、TransformImage在EvaluationContext上引入并消费同一个ImageComposeTransform字段。视频工作只要求它自己的算子遵守该字段即可推进并不依赖本计划。而本计划Plan_ImageComposeTransform.md的目标是把这一机制的消费范围推广到每一个纹理消费算子使免费的 UV 变换free UV transforms在整个图中普遍生效。因此它被定位为一项横切cross-cutting的大型工程覆盖上百个算子而非某一个具体功能。从仓库现状看该上下文字段尚未出现在 EvaluationContext.cs 中——当前EvaluationContext已携带 3D 侧的三套矩阵CameraToClipSpace、WorldToCamera、ObjectToWorld见 EvaluationContext.cs、ForegroundColor、ContextTextures、FloatVariables/IntVariables等上下文数据但尚无ImageComposeTransform属性与本计划Deferred已延期的状态一致。这反过来印证了计划文档的定位这是一份待实施的设计蓝图。二、核心思想让上下文替算子记住变换2.1 一个字段一个默认值计划的核心设想是在EvaluationContext上携带一个ImageComposeTransform结构并赋予它一个中立且有意义neutral, meaningful的默认值组成中立默认值含义UV 变换单位矩阵identity不改变采样坐标颜色 / 染色1不染色透明度opacity1完全不透明混合模式正常混合normal blend标准叠加采样器默认采样器常规过滤/寻址纹理消费型算子在采样或渲染时读取该字段并应用它。这与 3D 侧 Scene[Transform]携带世界矩阵world matrix的心智模型完全一致变换作为上下文沿评估树向下传递子图里的算子无需各自接线就能感知到父级施加的变换。2.2 一个算子管一整棵子树计划中设想的TransformImage是一个通用的子图修饰算子不限于视频它在其子图求值期间修改context.ImageComposeTransform因此子树中的每一个图像/纹理算子都会拾取到累积后的变换——不需要任何逐算子接线no per-op wiring。这正好与仓库中现有的 TransformImage.cs 形成对比。当前仓库里的TransformImage是一个传统单入单出的 Texture2D→Texture2D 变换算子输入为Image、Offset、Stretch、Scale、Rotation、Resolution、ResolutionFactor、GenerateMips、Filter、WrapMode见 TransformImage.cs本质上是一个会产出中间纹理的独立变换节点。而计划中的TransformImage是上下文修饰符形态——它不产出新的纹理只改写上下文让子树内的所有采样在 shader 内完成变换。两者同名不同构读者在阅读本计划时应注意区分后者属于待实施的未来形态。三、为什么值得做三个核心论据计划给出了三点理由构成该机制的价值判断UV 变换在采样时几乎是免费的。偏移 / 缩放 / 旋转 / 镜像如果施加在采样时刻就只是算子已运行的 shader 内部的一次坐标变换——没有额外的渲染 pass、没有中间渲染目标。而链式串联一个专用的变换算子需要一次全屏 blitfull-screen blit的成本。染色 / 透明度 / 混合同样可以折叠进同一次采样。一套机制全图生效。TransformImage如同[Transform]变换的是整个图像子图算子不再需要各自暴露 offset/scale/rotate 输入。与 3D 侧保持一致。使用与 Scene[Transform]相同的思维模型降低学习与维护成本。四、安全默认原则让 100 算子的推广可增量进行计划特别强调了一个使工程可推进tractable的性质——Safe by default默认安全由于上下文默认值是中立的identity / one且只有子树中的TransformImage会改变它现有项目在引入TransformImage之前完全不受影响。不存在对当前图的行为迁移behavioral migration——采纳是纯增量的未迁移的算子像今天一样忽略中立的上下文已迁移的算子仅在上下文非中立时才会生效。这正是一个覆盖 100 算子的推广可以**分批进行、无需 flag day统一切换日**的原因任何时候都可以安全地发布部分迁移成果。从计划随后列出的实施节奏看这一原则贯穿始终未迁移的算子靠默认中立继续正常工作已迁移的算子靠非中立才生效保证行为可预期。五、范围与成本工作量的大头在哪里计划明确指出本工程的主体工作量是约 100 个纹理消费型算子——包括它们的HLSL 采样器以及C# 常量接线constant wiring。每一个算子都需要把上下文变换传入自己的 shader在采样时刻应用该变换。这意味着它不像视频计划那样集中在少数几个新算子而是一场覆盖全图既有算子的系统性改造。这也是它被标记为大型横切工程并延期的直接原因。六、落地策略共享 helper、明确规则、按类分批6.1 共享 helper而不是逐个算子重新发明计划给出的第一条策略是共享 helper保证一处把数学做对处处复用HLSL 侧一个 include 文件例如SampleWithComposeTransform(...)封装采样 应用上下文变换的逻辑C# 侧一个 helper 把上下文ImageComposeTransform打包pack进常量缓冲区constant buffer。算子迁移时只需把自己的采样调用切换到该 helper即可获得统一的行为与最小的逐算子改动量。这一设计也直接服务于风险章节中常量缓冲区布局一致性的缓解由共享 helper 统一打包就避免了上百个算子各自定义布局导致的不一致。6.2 定义参与规则participation rule并非所有算子都该遵守该字段。计划要求明确参与边界让采纳变成机械操作而非逐案判断参与纹理采样 / 绘制类算子——滤镜filters、blit、绘制draws、读取纹理的生成器generators不参与纯数据 / 非空间pure-data / non-spatial算子。从仓库算子布局可以观察到这一边界的自然分界图像类算子集中在 Operators/Lib/Symbols/image/ 下含analyze、color、fx、transform、use等子目录其中fx滤镜/扭曲、use采样使用等即属于计划所指的采样/绘制参与者而纯数值、数据结构类算子则明显不属于空间变换范畴。6.3 与算子自身变换输入调和ambient ∘ local许多图像算子已经自带 offset/scale/rotate 输入现有TransformImage即是例子。计划需要约定组合规则上下文变换是从祖先继承来的环境变换ambient transform与算子自身的局部输入local组合即最终变换 ambient ∘ local这与[Transform]沿场景树向下组合的方式一致。这一条约定了继承自祖先的变换与算子本地参数谁先谁后是避免视觉回归见风险章节的关键语义。6.4 按类别增量迁移Incremental, by category计划的实施分为若干阶段Phase 1字段本身 共享 helper 视频算子与视频计划重叠Phase 2按批次迁移纹理算子顺序为生成器generators→ 滤镜filters→ 渲染器renderers每批可独立测试。每批都靠默认安全性质保证未迁移算子继续工作。这种小步、可测、可回退的节奏与计划文档将其定性为可增量推进的工程完全一致。七、风险与缓解计划列出了三类主要风险及其对策风险缓解措施视觉回归算子在错误的坐标系或顺序下应用变换中立默认值无变换 ⇒ 无变化 每批视觉测试常量缓冲区布局一致性众多算子各自定义布局导致漂移共享 helper 统一打包与布局热路径纪律应用必须零分配、且折叠进现有采样不产生额外 pass遵循引擎的每帧规则强制在采样内完成其中热路径纪律与 TiXL 引擎一贯的每帧零分配no-per-frame-allocation约束一致——视频计划中_ProcessVideoClips复用List/HashSet避免每帧分配的做法见 Plan_VideoClipPlayer.md正是同一纪律的体现。八、与视频工作的关系约定的具体形态Plan_VideoClipPlayer.md中的Compose params TransformImage(the context convention)一节给出了该机制在视频场景下的具体约定可作为本计划第一消费者的实现蓝图EvaluationContext携带ImageComposeTransform默认中立identity 矩阵、color 1、opacity 1、normal blend不做特殊处理的叶子算子不触碰它。TransformImage是通用子图修饰符像 Scene[Transform]一样在子图求值期间改写context.ImageComposeTransform子树中的每个图像 /VideoClip都会拾取累积变换——这也是接线wired剪辑获得外部/图驱动变换的方式。VideoClip携带自己的完整合成参数集transform / color / opacity / blend / sampler作为可动画输入。作为叶子节点它读取当前上下文、组合自身参数并注册{frame, TimeClip, finalTransform}供播放器 blit——它不写上下文字段只有变换算子才写。当不存在祖先TransformImage上下文中立时VideoClip只用自己的参数——这是日常路径也是虚拟自动收集 auto-collected路径。自动收集的剪辑位于任何TransformImage子树之外因此只能通过自身参数变换——这一规则被机制本身强制而非特判。该计划文档还明确了两者的解耦关系视频工作不被本计划阻塞——视频合成只需要自己的算子遵守该字段即可先行落地本计划随后将消费推广到其余纹理算子把免费的 UV 变换开遍全图turning free UV transforms on everywhere。九、仓库现状佐证可继续深挖的路径上下文载体EvaluationContext.cs —— TiXL 的求值上下文已含 3D 矩阵CameraToClipSpace/WorldToCamera/ObjectToWorldL123-L125、ForegroundColor、ContextTextures等ImageComposeTransform字段按计划将在此落地。同名现有算子TransformImage.cs 与 TransformImage.t3 —— 当前为传统 Texture2D→Texture2D 变换算子其.t3配置显示默认值Stretch(1,1)、Scale1.0、Offset(0,0)、Rotation0.0、Resolution(0,0)、ResolutionFactor(1,1)、FilterMinMagMipLinear、WrapMode2Clamp 系、GenerateMipsfalse并引用Lib:shaders/img/fx/TransformImage.hlsl见 TransformImage.t3。视频计划中的上下文约定Plan_VideoClipPlayer.md —— 首批消费者的行为定义与实施状态Phase 1/2 已完成含_ProcessVideoClips、LayerIndex排序、每剪辑Color/BlendMode等。示例TransformImageExample.cs —— 官方示例中对TransformImage的使用入口。十、总结一份默认安全、可增量、共享 helper的图级改造蓝图ImageComposeTransform计划把视频合成工作中自然生长出的上下文约定升格为一项覆盖全图纹理算子的系统性改造。它的设计精髓在于三点中立默认值消除了对既有项目的任何行为迁移使 100 算子的推广可以无限分批共享 helper 明确参与规则 ambient ∘ local 组合约定把逐算子改造从每处判断降为机械替换与 3D[Transform]同一心智模型让变换向上游合成这一看似特殊的语义成为惯例而非特例。对读者而言理解这份计划不仅有助于阅读 TiXL 未来的提交历史也能复用于任何上下文携带渲染状态、叶节点采样时消费的实时图形引擎架构设计。当前该计划处于延期状态仓库中的落地证据主要在视频工作一侧VideoClipPlayer/VideoClip的上下文约定全图推广的 HLSL helper如SampleWithComposeTransform与EvaluationContext.ImageComposeTransform字段尚待后续实施。【免费下载链接】t3TiXL is an open source software to create realtime motion graphics.项目地址: https://gitcode.com/GitHub_Trending/t3/t3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考