1. 项目缘起与整体设计思路1.1 为什么会有 artcraft 这个想法做创意工具这些年我最大的感受是大部分所谓的“创作辅助平台”最后都变成了素材堆砌站。用户打开页面满屏的模板、滤镜、预设看似丰富实则千篇一律。你让一个想认真做点东西的人面对这些东西他反而更迷茫——因为选择太多而真正能帮他表达自己想法的工具太少。artcraft 这个项目最初就是冲着这个痛点去的。它的核心定位不是“给你一堆现成的东西让你挑”而是“给你一套趁手的工具让你把脑子里的画面做出来”。这个区别听起来很虚但落到产品设计上差别巨大。我见过太多人脑子里有个很具体的画面——比如一张带有复古胶片颗粒感、边缘有轻微漏光、色调偏青绿但高光又带点暖黄的图——然后打开某个工具发现要么只能套滤镜要么得在十几个参数里自己瞎调最后调出来的东西跟脑子里想的完全不是一回事。artcraft 要解决的就是这个问题让用户用最直观的方式把脑海中的视觉概念转化为可操作的参数组合。这个项目适合谁我总结了三类人第一类是有明确创作意图但缺乏专业工具操作经验的独立创作者比如写作者、独立音乐人、小型工作室的视觉负责人第二类是需要在短时间内产出大量风格统一视觉素材的运营人员第三类是把 artcraft 当作教学工具的视觉设计入门者——因为它的参数逻辑足够透明能让人理解“为什么这个效果是这样调出来的”。1.2 核心架构的取舍逻辑artcraft 的整体架构我最终选择的是**“图层化处理管线 参数化效果栈”**的模式。这个选择不是拍脑袋定的是踩过坑之后才确定的。最早我试过“一键风格迁移”的方案就是用户上传一张参考图系统自动把风格套到目标图上。这个方案听起来很酷但实际用下来问题很大风格迁移的结果不可控用户没法微调而且对硬件要求高稍微大一点的图就得等半天。更致命的是用户根本不知道系统做了什么出了问题也没法排查。后来我又试了“预设模板 有限参数”的方案就是给用户几个滑块调调亮度、对比度、饱和度就完事。这个方案倒是简单但很快就被我否了——因为它本质上还是“让用户在有限选项里挑”跟 artcraft 的初衷背道而驰。最终确定的“图层化处理管线 参数化效果栈”核心思路是这样的把每一个视觉效果拆解成独立的处理节点每个节点暴露一组语义明确的参数用户通过组合和调整这些节点来实现自己想要的效果。比如“胶片颗粒”是一个节点它暴露“颗粒密度”“颗粒大小”“颗粒对比度”三个参数“漏光”是另一个节点暴露“漏光位置”“漏光强度”“漏光色温”三个参数。用户可以把这两个节点叠在一起再调各自的参数最终得到的效果就是可控、可复现、可解释的。这个架构的优势在于透明。用户知道每个效果是怎么来的调错了也能退回去重新调。灵活。节点可以任意组合不受预设限制。可扩展。新增一个效果只需要新增一个节点不影响已有管线。当然代价也是有的。相比“一键套用”用户的学习成本确实高了一些。但我的判断是愿意花时间调参数的人才是真正有创作需求的人。那些只想一键出图的人本来就不是 artcraft 的目标用户。1.3 技术选型背后的考量技术栈这块我最终选的是WebGL TypeScript 自定义着色器管线。这个选择有几个层面的考虑。首先是 WebGL。artcraft 的核心是图像处理而图像处理本质上是对像素的并行计算。WebGL 的 GPU 加速能力能让实时预览成为可能。我实测过一张 4000x3000 的图用 CPU 做高斯模糊要好几秒用 WebGL 着色器做基本是毫秒级。这个差距直接决定了用户能不能“边调边看”。其次是 TypeScript。artcraft 的参数系统比较复杂每个效果节点都有自己的参数定义、取值范围、默认值、依赖关系。用 TypeScript 的接口和泛型来描述这些能在编译期就发现很多类型错误减少运行时的诡异 bug。而且 TypeScript 的类型定义本身就是一种文档新加入的开发者看类型定义就能大概理解每个节点的结构。最后是自定义着色器管线。市面上有一些现成的图像处理库比如某些基于 Canvas 2D 的滤镜库。但我试过之后发现这些库要么性能不够要么扩展性差——你想加一个自定义效果得改库的源码。自己写着色器管线虽然前期工作量大但后期加效果就是加一个 fragment shader 的事非常干净。这里有个经验如果你也在做类似的图像处理项目不要一开始就追求“大而全”的效果库。先把管线搭好把两三个核心效果做扎实后面的效果可以慢慢加。管线设计得好加效果就是复制粘贴改几行 shader 的事管线设计得不好加一个效果得改五个地方那才是真正的噩梦。2. 核心细节解析与实操要点2.1 效果节点的参数设计原则artcraft 里每个效果节点参数设计都遵循一个原则语义化、正交化、可预期。语义化是说参数名必须让用户一看就知道是干什么的。比如“颗粒密度”而不是“param1”“漏光强度”而不是“intensity”。这个听起来是废话但我见过太多工具用“Amount”“Level”“Value”这种模糊的词用户根本不知道调了会发生什么。正交化是说参数之间尽量不耦合。比如“颗粒大小”和“颗粒密度”是两个独立参数调大小不会影响密度调密度不会影响大小。这个在实现上需要一些数学处理——比如颗粒的生成算法要保证在不同密度下颗粒的尺寸分布是一致的。我试过偷懒让密度参数同时影响颗粒数量和尺寸结果用户调密度的时候颗粒大小也跟着变体验很差后来重写了。可预期是说参数的变化方向要符合直觉。比如“强度”调大效果应该更明显“色温”调大应该更暖。这个看似简单但有些效果的非线性特性会导致参数变化方向反直觉。比如某些色彩映射曲线参数调大反而让画面变暗。遇到这种情况我会在参数映射上加一层转换保证用户看到的行为是符合直觉的。2.2 图层混合模式的实现细节图层混合是 artcraft 里比较核心的功能也是比较容易出问题的地方。我实现的时候参考了主流图像编辑软件的做法但做了一些简化。混合模式的核心是混合公式。比如“正片叠底”的公式是result base * blend“滤色”的公式是result 1 - (1 - base) * (1 - blend)。这些公式本身不复杂但在 WebGL 里实现的时候要注意几个点。第一是颜色空间。WebGL 默认是在线性空间做计算的但用户看到的图像通常是 sRGB 空间。如果直接在线性空间做混合结果会偏暗。我的做法是在着色器里先把 sRGB 转成线性做完混合再转回 sRGB。这个转换有现成的公式但要注意精度问题——用pow函数做伽马校正的时候低亮度区域容易出带状伪影后来我改用查找表才解决。第二是Alpha 通道的处理。有些混合模式对 Alpha 通道的处理方式不一样比如“叠加”模式在 Alpha 小于 1 的时候行为会比较奇怪。我的做法是先把图层预乘 Alpha做完混合再反预乘。这个流程能保证大多数情况下结果符合预期。第三是性能优化。混合模式的计算量不大但如果图层多了每个像素都要做多次混合累积起来就很可观。我的优化策略是如果某个图层的混合模式是“正常”且不透明度是 100%就直接跳过混合计算直接用上层像素覆盖。这个优化在实际使用中能省不少性能。2.3 实时预览的渲染管线设计实时预览是 artcraft 用户体验的关键。用户调一个参数画面要立刻更新不能有卡顿。为了实现这个我在渲染管线设计上做了几件事。首先是增量渲染。不是每次参数变化都重新渲染整个图像而是只重新渲染受影响的区域。比如用户调“颗粒密度”只有颗粒层需要重新生成底图和其他图层不用动。这个需要把渲染管线拆成多个 pass每个 pass 对应一个效果节点参数变化时只触发对应的 pass。其次是降采样预览。在用户拖动滑块的时候用低分辨率的图像做预览等用户松开滑块再渲染全分辨率。这个策略能大幅降低拖动时的计算量。我实测过一张 4000x3000 的图全分辨率渲染要 200ms 左右降到 1000x750 只要 15ms拖动起来非常流畅。最后是着色器缓存。每个效果节点的着色器程序在第一次编译后缓存起来后续复用。WebGL 的着色器编译是比较耗时的操作如果每次参数变化都重新编译性能会很差。缓存之后参数变化只是更新 uniform 变量不涉及编译速度快很多。这里有个坑WebGL 的着色器编译是异步的在某些浏览器上如果连续触发多次编译可能会导致上下文丢失。我的做法是在初始化阶段就把所有可能用到的着色器编译好运行阶段只更新 uniform不触发新的编译。2.4 参数预设与分享机制artcraft 支持把一组参数保存为预设并且可以生成分享链接。这个功能看起来简单但实现的时候有几个细节要注意。预设的序列化格式我选的是 JSON。每个预设包含效果节点的列表、每个节点的参数值、以及节点的顺序。JSON 的好处是可读、可编辑、跨平台。用户如果愿意甚至可以手动改 JSON 来微调预设。分享链接的实现是把预设 JSON 压缩后放到 URL 的 hash 部分。用 hash 而不是 query string是因为 hash 不会发送到服务器纯客户端解析更安全也更私密。压缩用的是 LZ-string 算法能把 JSON 压到原来的三分之一左右链接不会太长。预设的版本兼容是个麻烦事。如果后续加了新效果节点旧预设加载的时候可能会缺参数。我的做法是给每个效果节点定义默认参数加载预设时如果发现某个参数缺失就用默认值补上。这样旧预设在新版本里也能正常加载只是新效果不会生效。3. 实操过程与核心环节实现3.1 从零搭建 WebGL 渲染管线搭建 WebGL 渲染管线的第一步是初始化上下文和创建帧缓冲。帧缓冲是离屏渲染的目标每个效果节点渲染到一个帧缓冲下一个节点从上一个帧缓冲读取纹理。这个“乒乓”式的渲染流程是图像处理管线的经典模式。具体实现上我创建了两个帧缓冲对象交替使用。节点 A 渲染到帧缓冲 1节点 B 从帧缓冲 1 读纹理、渲染到帧缓冲 2节点 C 从帧缓冲 2 读纹理、渲染到帧缓冲 1以此类推。这样只需要两个帧缓冲就能支持任意数量的节点。纹理的格式选择要注意。如果只是做颜色处理用RGBA8就够了。但如果要做 HDR 效果比如高光溢出就需要用RGBA16F或RGBA32F。我一开始用的是RGBA8后来发现做漏光效果的时候高光部分会截断改成RGBA16F之后才正常。代价是显存占用翻倍但现代 GPU 基本都能承受。着色器的组织方式我采用的是“顶点着色器共用 片段着色器独立”的模式。顶点着色器就是一个简单的全屏四边形所有节点共用。片段着色器每个节点独立负责具体的像素计算。这样组织的好处是顶点着色器只需要编译一次片段着色器按需编译。3.2 胶片颗粒效果的着色器实现胶片颗粒是 artcraft 里比较有代表性的效果实现过程也踩了不少坑。这里详细说一下。颗粒的生成我用的是三维噪声。为什么是三维因为二维噪声在图像上会有明显的重复图案看起来不自然。三维噪声的第三个维度可以用时间或者随机种子这样每次生成的颗粒图案都不一样。噪声函数我用的是Simplex 噪声相比 Perlin 噪声Simplex 在高维度的计算量更小而且没有方向性伪影。Simplex 噪声的实现有现成的 GLSL 代码但要注意精度问题——在移动端 GPU 上highp精度可能不支持需要用mediump并做相应的精度补偿。颗粒的密度控制是通过对噪声值做阈值处理实现的。噪声值高于某个阈值的像素显示颗粒低于阈值的像素保持原样。阈值越高颗粒越稀疏阈值越低颗粒越密集。这个映射关系是线性的用户调“密度”参数的时候阈值线性变化颗粒密度的变化也是线性的符合直觉。颗粒的大小控制是通过对噪声的采样坐标做缩放实现的。采样坐标乘以一个系数系数越大噪声图案被放大颗粒看起来就越大。这里要注意的是缩放系数和颗粒大小不是线性关系——因为噪声本身有频率特性缩放系数变化时颗粒的视觉大小变化是非线性的。我后来加了一个对数映射让用户调“大小”参数的时候颗粒大小的变化更均匀。颗粒的对比度控制是通过对噪声值做幂运算实现的。幂次大于 1颗粒的明暗对比更强幂次小于 1颗粒更柔和。这个也是非线性映射但用户调起来感觉比较自然就没做额外处理。3.3 漏光效果的参数化实现漏光效果的核心是在图像边缘叠加一层带颜色的光晕。实现上分两步生成光晕图案然后和原图混合。光晕图案的生成我用的是径向渐变 噪声扰动。先创建一个从边缘向中心衰减的径向渐变然后用噪声对渐变值做扰动让光晕的边缘不那么规则。扰动的强度是一个参数用户调“漏光强度”的时候实际上调的是光晕的透明度和扰动强度。漏光位置的控制是通过调整径向渐变的中心点实现的。中心点可以在图像边缘的任意位置用户通过一个二维滑块来控制。这个滑块我做了映射让用户感觉是在图像边缘“拖动”光源而不是在调抽象的坐标值。漏光色温的控制是通过对光晕颜色做色相偏移实现的。色温参数从冷到暖对应色相从蓝到黄。这里要注意的是色相偏移不能简单地加一个固定值因为不同颜色的感知亮度不一样。我的做法是在 HSL 空间做偏移然后转回 RGB这样色相变化更均匀。混合方式我用的是“滤色”模式因为漏光本质上是“加光”滤色模式能保证亮部叠加后不会过曝。但如果用户想要更强烈的效果也可以切换到“线性减淡”模式那个叠加效果更猛但容易过曝我在 UI 上加了提示。3.4 参数系统的数据结构设计参数系统的数据结构我设计了三层参数定义层、参数实例层、参数绑定层。参数定义层描述“这个参数是什么”包括参数名、类型、取值范围、默认值、UI 控件类型。比如“颗粒密度”的定义是类型为浮点数范围 0 到 1默认值 0.5UI 控件为滑块。参数实例层描述“这个参数当前的值”就是一个简单的键值对。每个效果节点实例都有自己的参数实例互不干扰。参数绑定层描述“这个参数怎么和着色器交互”包括 uniform 变量名、数据类型转换规则。比如“颗粒密度”绑定到着色器的u_densityuniform类型是float直接传值就行。这三层分离的好处是定义层可以复用实例层可以序列化绑定层可以适配不同的渲染后端。如果以后要加一个 CPU 渲染后端只需要改绑定层定义层和实例层不用动。参数变化的监听我用的是观察者模式。每个参数实例都有一个监听器列表参数值变化时通知所有监听器。渲染管线注册为监听器收到通知后标记对应的效果节点为“脏”下一帧渲染时只重新渲染脏节点。这个机制能保证参数变化时只做必要的重渲染不浪费性能。4. 常见问题与排查技巧实录4.1 渲染结果偏暗或偏亮这是最常见的问题通常和颜色空间有关。WebGL 默认在线性空间做计算但纹理上传的时候如果没做 sRGB 转换采样出来的值就是 sRGB 空间的直接参与线性计算就会偏暗。排查方法先检查纹理的 internal format 是不是SRGB8_ALPHA8。如果是RGBA8那采样出来的就是原始值需要手动做 sRGB 到线性的转换。转换公式是pow(value, 2.2)但更准确的做法是用 sRGB 的标准转换曲线。另一个可能的原因是帧缓冲的格式。如果帧缓冲是RGBA8渲染结果会被截断到 0 到 1 之间高光部分会丢失。如果效果涉及高动态范围需要用RGBA16F或RGBA32F。还有一种情况是混合模式的问题。如果混合模式用的是“正片叠底”但颜色空间不对结果会偏暗。我的经验是所有混合操作都在线性空间做做完再转回 sRGB。这个流程能保证大多数情况下结果符合预期。4.2 实时预览卡顿卡顿的原因通常有三个渲染分辨率太高、效果节点太多、着色器太复杂。排查方法先用浏览器的性能分析工具看 GPU 时间。如果 GPU 时间很长说明是渲染本身的问题。如果 GPU 时间不长但帧率低可能是 JavaScript 层面的问题比如参数变化时触发了太多次重渲染。针对渲染分辨率可以用降采样预览。拖动滑块时用低分辨率松开后用全分辨率。这个策略能大幅降低拖动时的计算量。针对效果节点太多可以合并一些节点。比如“亮度”和“对比度”可以合并成一个“色阶”节点减少一次纹理采样和渲染。针对着色器太复杂可以简化计算。比如噪声函数如果用了太多 octave可以适当减少。或者把一些计算移到顶点着色器利用顶点着色器的插值来减少片段着色器的计算量。4.3 预设加载后效果不对预设加载后效果不对通常是版本兼容问题。新版本加了效果节点或改了参数范围旧预设加载时参数缺失或越界。排查方法先检查预设 JSON 里的节点列表和当前版本的节点列表是否一致。如果预设里有当前版本没有的节点加载时应该跳过并给出提示。如果预设里缺少当前版本有的节点加载时应该用默认参数补上。参数越界的问题需要在加载时做范围检查。如果预设里的参数值超出了当前定义的范围应该截断到边界值而不是直接使用。这个检查在参数实例层做加载预设时统一处理。还有一种情况是参数映射变了。比如某个参数原来是从 0 到 1 线性映射后来改成了对数映射旧预设里的值加载后效果就不一样了。这种情况需要在预设里记录版本号加载时根据版本号做相应的转换。4.4 常见问题速查表问题现象可能原因排查方法解决方案渲染结果偏暗颜色空间未转换检查纹理格式和着色器转换在线性空间计算输出时转 sRGB渲染结果偏亮混合模式错误检查混合公式和颜色空间确保混合在线性空间进行实时预览卡顿渲染分辨率太高用性能分析工具看 GPU 时间降采样预览拖动时用低分辨率实时预览卡顿效果节点太多检查节点数量和渲染 pass 数合并节点减少纹理采样预设加载效果不对版本不兼容对比预设节点和当前节点补默认值截断越界参数颗粒效果有重复图案噪声维度不够检查噪声函数维度用三维噪声第三维用随机种子漏光边缘太规则缺少噪声扰动检查光晕生成算法加噪声扰动强度可调着色器编译失败精度不支持检查移动端 GPU 精度用 mediump 并做精度补偿4.5 几个踩过的坑和独家技巧第一个坑是纹理坐标的精度问题。在移动端 GPU 上highp精度可能不支持纹理坐标用mediump会导致采样偏移画面出现奇怪的条纹。我的解决方案是在片段着色器里用highp声明纹理坐标如果设备不支持就降级到mediump并加一个微小的偏移补偿。第二个坑是帧缓冲的切换开销。每次切换帧缓冲都要绑定和解绑这个操作在桌面端开销不大但在移动端比较明显。我的优化是尽量减少帧缓冲切换次数能合并的 pass 就合并。比如“亮度”和“对比度”可以合并成一个 pass用两个 uniform 控制不需要两个帧缓冲。第三个坑是参数变化的防抖。用户拖动滑块时参数变化非常频繁如果每次变化都触发重渲染性能会很差。我的做法是加一个防抖延迟参数变化后等 16ms一帧的时间再触发重渲染。这样即使用户快速拖动也最多每帧渲染一次不会堆积。第四个技巧是用查找表代替复杂计算。比如 sRGB 转换、伽马校正这些计算如果用pow函数实时算开销不小。我的做法是预计算一个 256 项的查找表运行时直接查表速度快很多。查找表用纹理的形式传给着色器采样一次就能拿到结果。第五个技巧是着色器的条件编译。有些效果节点有可选功能比如颗粒效果可以选择是否带颜色。如果不用条件编译着色器里会有分支判断影响性能。我的做法是用#define在编译时决定是否包含某段代码这样运行时没有分支性能更好。5. 效果组合与工作流优化5.1 效果链的顺序对最终结果的影响在 artcraft 里效果节点的顺序会直接影响最终结果。这不是 bug而是图像处理管线的固有特性。比如“先调色再叠颗粒”和“先叠颗粒再调色”结果是不一样的。前者颗粒会跟着调色一起变后者颗粒保持原样。我的设计是让用户自由调整节点顺序但会在 UI 上给出提示某些效果组合有推荐的顺序。比如“降噪”应该在“锐化”之前“调色”应该在“颗粒”之前。这些推荐顺序是基于图像处理的常规实践但用户如果不按推荐来也能得到有趣的效果——只是需要自己承担结果。节点顺序的调整实现上是重新排列渲染管线的 pass 顺序。这个操作不涉及着色器重编译只是改变帧缓冲的读写顺序所以很快。用户拖动节点的时候画面会实时更新能直观看到顺序变化带来的影响。5.2 批量处理的工作流设计批量处理是 artcraft 里比较实用的功能。用户可以把一组参数保存为预设然后应用到多张图上。这个功能的实现有几个关键点。首先是参数与图像的解耦。预设只包含参数不包含图像数据。这样预设可以复用到任意图像上不受图像尺寸和内容的影响。其次是并行处理。批量处理的时候多张图可以并行渲染。我用的是 Web Worker OffscreenCanvas 的方案每个 Worker 负责一张图的渲染主线程负责调度和进度显示。这个方案能充分利用多核 CPU批量处理速度比单线程快很多。最后是结果的一致性。批量处理的时候要保证每张图用的参数完全一致不能因为图像尺寸不同导致效果有差异。我的做法是在参数映射里做归一化比如颗粒大小按图像短边的比例来算这样不同尺寸的图看起来颗粒大小是一致的。5.3 预设的版本管理与迁移预设的版本管理是个长期问题。随着 artcraft 迭代效果节点会增删改预设的兼容性需要维护。我的做法是给每个预设打一个版本号版本号对应 artcraft 的版本。加载预设时如果预设版本低于当前版本就执行迁移脚本。迁移脚本是一系列转换函数每个函数负责从一个版本迁移到下一个版本。比如从 1.0 到 1.1 的迁移脚本负责把旧的“亮度”参数转换成新的“色阶”参数。迁移脚本的编写要注意只做加法不做减法。意思是新版本可以加参数、加节点但尽量不要删参数、删节点。如果必须删也要保留兼容层让旧预设能加载只是新功能不生效。这个原则能最大程度保证预设的向后兼容。6. 性能优化与跨平台适配6.1 WebGL 性能优化的几个关键点WebGL 性能优化我总结下来最关键的是三点减少 draw call、减少纹理采样、减少分支。减少 draw call 的方法是合并渲染 pass。比如多个效果节点如果可以用一个着色器实现就合并成一个 pass。这个需要对着色器做一定的抽象把多个效果的计算逻辑放在一个着色器里用 uniform 控制哪些效果生效。减少纹理采样的方法是复用采样结果。比如同一个纹理坐标的多次采样可以只采样一次把结果存在变量里复用。这个在着色器里很容易做到但容易被忽略。减少分支的方法是条件编译。前面提过用#define在编译时决定是否包含某段代码运行时就没有分支了。这个对移动端 GPU 特别重要因为移动端 GPU 对分支的惩罚比桌面端大得多。6.2 移动端适配的注意事项移动端适配最大的问题是性能和精度的平衡。性能方面移动端 GPU 的填充率通常比桌面端低所以渲染分辨率要控制。我的做法是根据设备像素比动态调整渲染分辨率高像素比的设备适当降低渲染分辨率用 CSS 放大显示。这样视觉上差别不大但性能提升明显。精度方面移动端 GPU 对highp精度的支持不一致。有些设备支持有些不支持。我的做法是在着色器里用#ifdef GL_FRAGMENT_PRECISION_HIGH做条件编译支持highp就用highp不支持就用mediump并做精度补偿。还有一个问题是纹理尺寸限制。移动端 GPU 的最大纹理尺寸通常比桌面端小如果图像尺寸超过限制需要分块处理。我的做法是在上传纹理前检查尺寸超过限制就自动缩小并提示用户。6.3 不同浏览器的兼容性处理不同浏览器对 WebGL 的支持程度不一样兼容性处理是必须的。首先是WebGL 版本。有些老设备只支持 WebGL 1.0不支持 WebGL 2.0。我的做法是优先尝试 WebGL 2.0失败则降级到 WebGL 1.0。两个版本的着色器语法有差异需要准备两套着色器或者用预处理宏来适配。其次是扩展支持。有些效果需要特定的 WebGL 扩展比如浮点纹理、深度纹理。我的做法是在初始化时检查扩展支持情况不支持的功能就禁用对应的效果节点并在 UI 上给出提示。最后是上下文丢失。WebGL 上下文可能因为各种原因丢失比如 GPU 驱动崩溃、系统休眠。我的做法是监听webglcontextlost和webglcontextrestored事件在上下文丢失时保存状态恢复时重新初始化。这个机制能保证用户不会因为上下文丢失而丢失工作进度。7. 一些个人体会和后续扩展方向artcraft 做到现在我最大的体会是工具的价值不在于功能多而在于能不能让用户把想法落地。我见过很多功能极其丰富的创作工具但用户打开之后不知道从哪下手。artcraft 的设计哲学是“少即是多”——每个效果节点都足够简单但组合起来能实现复杂的效果。后续的扩展方向我目前考虑的有几个。一是效果节点的脚本化让用户可以用 JavaScript 写自定义效果节点这样扩展性会强很多。二是协作功能让多个用户可以同时编辑一个预设实时看到对方的修改。三是AI 辅助调参用户描述想要的效果系统自动推荐参数组合。这几个方向都在探索阶段具体怎么做还没定。如果你也在做类似的项目我的建议是先把核心管线搭好把两三个效果做扎实不要一开始就追求大而全。管线设计得好后面加效果就是水到渠成的事。管线设计得不好加一个效果得改五个地方那才是真正的噩梦。另外多花时间在参数设计上参数设计得好用户用起来顺手比多十个效果都管用。
1. 项目缘起与整体设计思路1.1 为什么会有 artcraft 这个想法做创意工具这些年我最大的感受是大部分所谓的“创作辅助平台”最后都变成了素材堆砌站。用户打开页面满屏的模板、滤镜、预设看似丰富实则千篇一律。你让一个想认真做点东西的人面对这些东西他反而更迷茫——因为选择太多而真正能帮他表达自己想法的工具太少。artcraft 这个项目最初就是冲着这个痛点去的。它的核心定位不是“给你一堆现成的东西让你挑”而是“给你一套趁手的工具让你把脑子里的画面做出来”。这个区别听起来很虚但落到产品设计上差别巨大。我见过太多人脑子里有个很具体的画面——比如一张带有复古胶片颗粒感、边缘有轻微漏光、色调偏青绿但高光又带点暖黄的图——然后打开某个工具发现要么只能套滤镜要么得在十几个参数里自己瞎调最后调出来的东西跟脑子里想的完全不是一回事。artcraft 要解决的就是这个问题让用户用最直观的方式把脑海中的视觉概念转化为可操作的参数组合。这个项目适合谁我总结了三类人第一类是有明确创作意图但缺乏专业工具操作经验的独立创作者比如写作者、独立音乐人、小型工作室的视觉负责人第二类是需要在短时间内产出大量风格统一视觉素材的运营人员第三类是把 artcraft 当作教学工具的视觉设计入门者——因为它的参数逻辑足够透明能让人理解“为什么这个效果是这样调出来的”。1.2 核心架构的取舍逻辑artcraft 的整体架构我最终选择的是**“图层化处理管线 参数化效果栈”**的模式。这个选择不是拍脑袋定的是踩过坑之后才确定的。最早我试过“一键风格迁移”的方案就是用户上传一张参考图系统自动把风格套到目标图上。这个方案听起来很酷但实际用下来问题很大风格迁移的结果不可控用户没法微调而且对硬件要求高稍微大一点的图就得等半天。更致命的是用户根本不知道系统做了什么出了问题也没法排查。后来我又试了“预设模板 有限参数”的方案就是给用户几个滑块调调亮度、对比度、饱和度就完事。这个方案倒是简单但很快就被我否了——因为它本质上还是“让用户在有限选项里挑”跟 artcraft 的初衷背道而驰。最终确定的“图层化处理管线 参数化效果栈”核心思路是这样的把每一个视觉效果拆解成独立的处理节点每个节点暴露一组语义明确的参数用户通过组合和调整这些节点来实现自己想要的效果。比如“胶片颗粒”是一个节点它暴露“颗粒密度”“颗粒大小”“颗粒对比度”三个参数“漏光”是另一个节点暴露“漏光位置”“漏光强度”“漏光色温”三个参数。用户可以把这两个节点叠在一起再调各自的参数最终得到的效果就是可控、可复现、可解释的。这个架构的优势在于透明。用户知道每个效果是怎么来的调错了也能退回去重新调。灵活。节点可以任意组合不受预设限制。可扩展。新增一个效果只需要新增一个节点不影响已有管线。当然代价也是有的。相比“一键套用”用户的学习成本确实高了一些。但我的判断是愿意花时间调参数的人才是真正有创作需求的人。那些只想一键出图的人本来就不是 artcraft 的目标用户。1.3 技术选型背后的考量技术栈这块我最终选的是WebGL TypeScript 自定义着色器管线。这个选择有几个层面的考虑。首先是 WebGL。artcraft 的核心是图像处理而图像处理本质上是对像素的并行计算。WebGL 的 GPU 加速能力能让实时预览成为可能。我实测过一张 4000x3000 的图用 CPU 做高斯模糊要好几秒用 WebGL 着色器做基本是毫秒级。这个差距直接决定了用户能不能“边调边看”。其次是 TypeScript。artcraft 的参数系统比较复杂每个效果节点都有自己的参数定义、取值范围、默认值、依赖关系。用 TypeScript 的接口和泛型来描述这些能在编译期就发现很多类型错误减少运行时的诡异 bug。而且 TypeScript 的类型定义本身就是一种文档新加入的开发者看类型定义就能大概理解每个节点的结构。最后是自定义着色器管线。市面上有一些现成的图像处理库比如某些基于 Canvas 2D 的滤镜库。但我试过之后发现这些库要么性能不够要么扩展性差——你想加一个自定义效果得改库的源码。自己写着色器管线虽然前期工作量大但后期加效果就是加一个 fragment shader 的事非常干净。这里有个经验如果你也在做类似的图像处理项目不要一开始就追求“大而全”的效果库。先把管线搭好把两三个核心效果做扎实后面的效果可以慢慢加。管线设计得好加效果就是复制粘贴改几行 shader 的事管线设计得不好加一个效果得改五个地方那才是真正的噩梦。2. 核心细节解析与实操要点2.1 效果节点的参数设计原则artcraft 里每个效果节点参数设计都遵循一个原则语义化、正交化、可预期。语义化是说参数名必须让用户一看就知道是干什么的。比如“颗粒密度”而不是“param1”“漏光强度”而不是“intensity”。这个听起来是废话但我见过太多工具用“Amount”“Level”“Value”这种模糊的词用户根本不知道调了会发生什么。正交化是说参数之间尽量不耦合。比如“颗粒大小”和“颗粒密度”是两个独立参数调大小不会影响密度调密度不会影响大小。这个在实现上需要一些数学处理——比如颗粒的生成算法要保证在不同密度下颗粒的尺寸分布是一致的。我试过偷懒让密度参数同时影响颗粒数量和尺寸结果用户调密度的时候颗粒大小也跟着变体验很差后来重写了。可预期是说参数的变化方向要符合直觉。比如“强度”调大效果应该更明显“色温”调大应该更暖。这个看似简单但有些效果的非线性特性会导致参数变化方向反直觉。比如某些色彩映射曲线参数调大反而让画面变暗。遇到这种情况我会在参数映射上加一层转换保证用户看到的行为是符合直觉的。2.2 图层混合模式的实现细节图层混合是 artcraft 里比较核心的功能也是比较容易出问题的地方。我实现的时候参考了主流图像编辑软件的做法但做了一些简化。混合模式的核心是混合公式。比如“正片叠底”的公式是result base * blend“滤色”的公式是result 1 - (1 - base) * (1 - blend)。这些公式本身不复杂但在 WebGL 里实现的时候要注意几个点。第一是颜色空间。WebGL 默认是在线性空间做计算的但用户看到的图像通常是 sRGB 空间。如果直接在线性空间做混合结果会偏暗。我的做法是在着色器里先把 sRGB 转成线性做完混合再转回 sRGB。这个转换有现成的公式但要注意精度问题——用pow函数做伽马校正的时候低亮度区域容易出带状伪影后来我改用查找表才解决。第二是Alpha 通道的处理。有些混合模式对 Alpha 通道的处理方式不一样比如“叠加”模式在 Alpha 小于 1 的时候行为会比较奇怪。我的做法是先把图层预乘 Alpha做完混合再反预乘。这个流程能保证大多数情况下结果符合预期。第三是性能优化。混合模式的计算量不大但如果图层多了每个像素都要做多次混合累积起来就很可观。我的优化策略是如果某个图层的混合模式是“正常”且不透明度是 100%就直接跳过混合计算直接用上层像素覆盖。这个优化在实际使用中能省不少性能。2.3 实时预览的渲染管线设计实时预览是 artcraft 用户体验的关键。用户调一个参数画面要立刻更新不能有卡顿。为了实现这个我在渲染管线设计上做了几件事。首先是增量渲染。不是每次参数变化都重新渲染整个图像而是只重新渲染受影响的区域。比如用户调“颗粒密度”只有颗粒层需要重新生成底图和其他图层不用动。这个需要把渲染管线拆成多个 pass每个 pass 对应一个效果节点参数变化时只触发对应的 pass。其次是降采样预览。在用户拖动滑块的时候用低分辨率的图像做预览等用户松开滑块再渲染全分辨率。这个策略能大幅降低拖动时的计算量。我实测过一张 4000x3000 的图全分辨率渲染要 200ms 左右降到 1000x750 只要 15ms拖动起来非常流畅。最后是着色器缓存。每个效果节点的着色器程序在第一次编译后缓存起来后续复用。WebGL 的着色器编译是比较耗时的操作如果每次参数变化都重新编译性能会很差。缓存之后参数变化只是更新 uniform 变量不涉及编译速度快很多。这里有个坑WebGL 的着色器编译是异步的在某些浏览器上如果连续触发多次编译可能会导致上下文丢失。我的做法是在初始化阶段就把所有可能用到的着色器编译好运行阶段只更新 uniform不触发新的编译。2.4 参数预设与分享机制artcraft 支持把一组参数保存为预设并且可以生成分享链接。这个功能看起来简单但实现的时候有几个细节要注意。预设的序列化格式我选的是 JSON。每个预设包含效果节点的列表、每个节点的参数值、以及节点的顺序。JSON 的好处是可读、可编辑、跨平台。用户如果愿意甚至可以手动改 JSON 来微调预设。分享链接的实现是把预设 JSON 压缩后放到 URL 的 hash 部分。用 hash 而不是 query string是因为 hash 不会发送到服务器纯客户端解析更安全也更私密。压缩用的是 LZ-string 算法能把 JSON 压到原来的三分之一左右链接不会太长。预设的版本兼容是个麻烦事。如果后续加了新效果节点旧预设加载的时候可能会缺参数。我的做法是给每个效果节点定义默认参数加载预设时如果发现某个参数缺失就用默认值补上。这样旧预设在新版本里也能正常加载只是新效果不会生效。3. 实操过程与核心环节实现3.1 从零搭建 WebGL 渲染管线搭建 WebGL 渲染管线的第一步是初始化上下文和创建帧缓冲。帧缓冲是离屏渲染的目标每个效果节点渲染到一个帧缓冲下一个节点从上一个帧缓冲读取纹理。这个“乒乓”式的渲染流程是图像处理管线的经典模式。具体实现上我创建了两个帧缓冲对象交替使用。节点 A 渲染到帧缓冲 1节点 B 从帧缓冲 1 读纹理、渲染到帧缓冲 2节点 C 从帧缓冲 2 读纹理、渲染到帧缓冲 1以此类推。这样只需要两个帧缓冲就能支持任意数量的节点。纹理的格式选择要注意。如果只是做颜色处理用RGBA8就够了。但如果要做 HDR 效果比如高光溢出就需要用RGBA16F或RGBA32F。我一开始用的是RGBA8后来发现做漏光效果的时候高光部分会截断改成RGBA16F之后才正常。代价是显存占用翻倍但现代 GPU 基本都能承受。着色器的组织方式我采用的是“顶点着色器共用 片段着色器独立”的模式。顶点着色器就是一个简单的全屏四边形所有节点共用。片段着色器每个节点独立负责具体的像素计算。这样组织的好处是顶点着色器只需要编译一次片段着色器按需编译。3.2 胶片颗粒效果的着色器实现胶片颗粒是 artcraft 里比较有代表性的效果实现过程也踩了不少坑。这里详细说一下。颗粒的生成我用的是三维噪声。为什么是三维因为二维噪声在图像上会有明显的重复图案看起来不自然。三维噪声的第三个维度可以用时间或者随机种子这样每次生成的颗粒图案都不一样。噪声函数我用的是Simplex 噪声相比 Perlin 噪声Simplex 在高维度的计算量更小而且没有方向性伪影。Simplex 噪声的实现有现成的 GLSL 代码但要注意精度问题——在移动端 GPU 上highp精度可能不支持需要用mediump并做相应的精度补偿。颗粒的密度控制是通过对噪声值做阈值处理实现的。噪声值高于某个阈值的像素显示颗粒低于阈值的像素保持原样。阈值越高颗粒越稀疏阈值越低颗粒越密集。这个映射关系是线性的用户调“密度”参数的时候阈值线性变化颗粒密度的变化也是线性的符合直觉。颗粒的大小控制是通过对噪声的采样坐标做缩放实现的。采样坐标乘以一个系数系数越大噪声图案被放大颗粒看起来就越大。这里要注意的是缩放系数和颗粒大小不是线性关系——因为噪声本身有频率特性缩放系数变化时颗粒的视觉大小变化是非线性的。我后来加了一个对数映射让用户调“大小”参数的时候颗粒大小的变化更均匀。颗粒的对比度控制是通过对噪声值做幂运算实现的。幂次大于 1颗粒的明暗对比更强幂次小于 1颗粒更柔和。这个也是非线性映射但用户调起来感觉比较自然就没做额外处理。3.3 漏光效果的参数化实现漏光效果的核心是在图像边缘叠加一层带颜色的光晕。实现上分两步生成光晕图案然后和原图混合。光晕图案的生成我用的是径向渐变 噪声扰动。先创建一个从边缘向中心衰减的径向渐变然后用噪声对渐变值做扰动让光晕的边缘不那么规则。扰动的强度是一个参数用户调“漏光强度”的时候实际上调的是光晕的透明度和扰动强度。漏光位置的控制是通过调整径向渐变的中心点实现的。中心点可以在图像边缘的任意位置用户通过一个二维滑块来控制。这个滑块我做了映射让用户感觉是在图像边缘“拖动”光源而不是在调抽象的坐标值。漏光色温的控制是通过对光晕颜色做色相偏移实现的。色温参数从冷到暖对应色相从蓝到黄。这里要注意的是色相偏移不能简单地加一个固定值因为不同颜色的感知亮度不一样。我的做法是在 HSL 空间做偏移然后转回 RGB这样色相变化更均匀。混合方式我用的是“滤色”模式因为漏光本质上是“加光”滤色模式能保证亮部叠加后不会过曝。但如果用户想要更强烈的效果也可以切换到“线性减淡”模式那个叠加效果更猛但容易过曝我在 UI 上加了提示。3.4 参数系统的数据结构设计参数系统的数据结构我设计了三层参数定义层、参数实例层、参数绑定层。参数定义层描述“这个参数是什么”包括参数名、类型、取值范围、默认值、UI 控件类型。比如“颗粒密度”的定义是类型为浮点数范围 0 到 1默认值 0.5UI 控件为滑块。参数实例层描述“这个参数当前的值”就是一个简单的键值对。每个效果节点实例都有自己的参数实例互不干扰。参数绑定层描述“这个参数怎么和着色器交互”包括 uniform 变量名、数据类型转换规则。比如“颗粒密度”绑定到着色器的u_densityuniform类型是float直接传值就行。这三层分离的好处是定义层可以复用实例层可以序列化绑定层可以适配不同的渲染后端。如果以后要加一个 CPU 渲染后端只需要改绑定层定义层和实例层不用动。参数变化的监听我用的是观察者模式。每个参数实例都有一个监听器列表参数值变化时通知所有监听器。渲染管线注册为监听器收到通知后标记对应的效果节点为“脏”下一帧渲染时只重新渲染脏节点。这个机制能保证参数变化时只做必要的重渲染不浪费性能。4. 常见问题与排查技巧实录4.1 渲染结果偏暗或偏亮这是最常见的问题通常和颜色空间有关。WebGL 默认在线性空间做计算但纹理上传的时候如果没做 sRGB 转换采样出来的值就是 sRGB 空间的直接参与线性计算就会偏暗。排查方法先检查纹理的 internal format 是不是SRGB8_ALPHA8。如果是RGBA8那采样出来的就是原始值需要手动做 sRGB 到线性的转换。转换公式是pow(value, 2.2)但更准确的做法是用 sRGB 的标准转换曲线。另一个可能的原因是帧缓冲的格式。如果帧缓冲是RGBA8渲染结果会被截断到 0 到 1 之间高光部分会丢失。如果效果涉及高动态范围需要用RGBA16F或RGBA32F。还有一种情况是混合模式的问题。如果混合模式用的是“正片叠底”但颜色空间不对结果会偏暗。我的经验是所有混合操作都在线性空间做做完再转回 sRGB。这个流程能保证大多数情况下结果符合预期。4.2 实时预览卡顿卡顿的原因通常有三个渲染分辨率太高、效果节点太多、着色器太复杂。排查方法先用浏览器的性能分析工具看 GPU 时间。如果 GPU 时间很长说明是渲染本身的问题。如果 GPU 时间不长但帧率低可能是 JavaScript 层面的问题比如参数变化时触发了太多次重渲染。针对渲染分辨率可以用降采样预览。拖动滑块时用低分辨率松开后用全分辨率。这个策略能大幅降低拖动时的计算量。针对效果节点太多可以合并一些节点。比如“亮度”和“对比度”可以合并成一个“色阶”节点减少一次纹理采样和渲染。针对着色器太复杂可以简化计算。比如噪声函数如果用了太多 octave可以适当减少。或者把一些计算移到顶点着色器利用顶点着色器的插值来减少片段着色器的计算量。4.3 预设加载后效果不对预设加载后效果不对通常是版本兼容问题。新版本加了效果节点或改了参数范围旧预设加载时参数缺失或越界。排查方法先检查预设 JSON 里的节点列表和当前版本的节点列表是否一致。如果预设里有当前版本没有的节点加载时应该跳过并给出提示。如果预设里缺少当前版本有的节点加载时应该用默认参数补上。参数越界的问题需要在加载时做范围检查。如果预设里的参数值超出了当前定义的范围应该截断到边界值而不是直接使用。这个检查在参数实例层做加载预设时统一处理。还有一种情况是参数映射变了。比如某个参数原来是从 0 到 1 线性映射后来改成了对数映射旧预设里的值加载后效果就不一样了。这种情况需要在预设里记录版本号加载时根据版本号做相应的转换。4.4 常见问题速查表问题现象可能原因排查方法解决方案渲染结果偏暗颜色空间未转换检查纹理格式和着色器转换在线性空间计算输出时转 sRGB渲染结果偏亮混合模式错误检查混合公式和颜色空间确保混合在线性空间进行实时预览卡顿渲染分辨率太高用性能分析工具看 GPU 时间降采样预览拖动时用低分辨率实时预览卡顿效果节点太多检查节点数量和渲染 pass 数合并节点减少纹理采样预设加载效果不对版本不兼容对比预设节点和当前节点补默认值截断越界参数颗粒效果有重复图案噪声维度不够检查噪声函数维度用三维噪声第三维用随机种子漏光边缘太规则缺少噪声扰动检查光晕生成算法加噪声扰动强度可调着色器编译失败精度不支持检查移动端 GPU 精度用 mediump 并做精度补偿4.5 几个踩过的坑和独家技巧第一个坑是纹理坐标的精度问题。在移动端 GPU 上highp精度可能不支持纹理坐标用mediump会导致采样偏移画面出现奇怪的条纹。我的解决方案是在片段着色器里用highp声明纹理坐标如果设备不支持就降级到mediump并加一个微小的偏移补偿。第二个坑是帧缓冲的切换开销。每次切换帧缓冲都要绑定和解绑这个操作在桌面端开销不大但在移动端比较明显。我的优化是尽量减少帧缓冲切换次数能合并的 pass 就合并。比如“亮度”和“对比度”可以合并成一个 pass用两个 uniform 控制不需要两个帧缓冲。第三个坑是参数变化的防抖。用户拖动滑块时参数变化非常频繁如果每次变化都触发重渲染性能会很差。我的做法是加一个防抖延迟参数变化后等 16ms一帧的时间再触发重渲染。这样即使用户快速拖动也最多每帧渲染一次不会堆积。第四个技巧是用查找表代替复杂计算。比如 sRGB 转换、伽马校正这些计算如果用pow函数实时算开销不小。我的做法是预计算一个 256 项的查找表运行时直接查表速度快很多。查找表用纹理的形式传给着色器采样一次就能拿到结果。第五个技巧是着色器的条件编译。有些效果节点有可选功能比如颗粒效果可以选择是否带颜色。如果不用条件编译着色器里会有分支判断影响性能。我的做法是用#define在编译时决定是否包含某段代码这样运行时没有分支性能更好。5. 效果组合与工作流优化5.1 效果链的顺序对最终结果的影响在 artcraft 里效果节点的顺序会直接影响最终结果。这不是 bug而是图像处理管线的固有特性。比如“先调色再叠颗粒”和“先叠颗粒再调色”结果是不一样的。前者颗粒会跟着调色一起变后者颗粒保持原样。我的设计是让用户自由调整节点顺序但会在 UI 上给出提示某些效果组合有推荐的顺序。比如“降噪”应该在“锐化”之前“调色”应该在“颗粒”之前。这些推荐顺序是基于图像处理的常规实践但用户如果不按推荐来也能得到有趣的效果——只是需要自己承担结果。节点顺序的调整实现上是重新排列渲染管线的 pass 顺序。这个操作不涉及着色器重编译只是改变帧缓冲的读写顺序所以很快。用户拖动节点的时候画面会实时更新能直观看到顺序变化带来的影响。5.2 批量处理的工作流设计批量处理是 artcraft 里比较实用的功能。用户可以把一组参数保存为预设然后应用到多张图上。这个功能的实现有几个关键点。首先是参数与图像的解耦。预设只包含参数不包含图像数据。这样预设可以复用到任意图像上不受图像尺寸和内容的影响。其次是并行处理。批量处理的时候多张图可以并行渲染。我用的是 Web Worker OffscreenCanvas 的方案每个 Worker 负责一张图的渲染主线程负责调度和进度显示。这个方案能充分利用多核 CPU批量处理速度比单线程快很多。最后是结果的一致性。批量处理的时候要保证每张图用的参数完全一致不能因为图像尺寸不同导致效果有差异。我的做法是在参数映射里做归一化比如颗粒大小按图像短边的比例来算这样不同尺寸的图看起来颗粒大小是一致的。5.3 预设的版本管理与迁移预设的版本管理是个长期问题。随着 artcraft 迭代效果节点会增删改预设的兼容性需要维护。我的做法是给每个预设打一个版本号版本号对应 artcraft 的版本。加载预设时如果预设版本低于当前版本就执行迁移脚本。迁移脚本是一系列转换函数每个函数负责从一个版本迁移到下一个版本。比如从 1.0 到 1.1 的迁移脚本负责把旧的“亮度”参数转换成新的“色阶”参数。迁移脚本的编写要注意只做加法不做减法。意思是新版本可以加参数、加节点但尽量不要删参数、删节点。如果必须删也要保留兼容层让旧预设能加载只是新功能不生效。这个原则能最大程度保证预设的向后兼容。6. 性能优化与跨平台适配6.1 WebGL 性能优化的几个关键点WebGL 性能优化我总结下来最关键的是三点减少 draw call、减少纹理采样、减少分支。减少 draw call 的方法是合并渲染 pass。比如多个效果节点如果可以用一个着色器实现就合并成一个 pass。这个需要对着色器做一定的抽象把多个效果的计算逻辑放在一个着色器里用 uniform 控制哪些效果生效。减少纹理采样的方法是复用采样结果。比如同一个纹理坐标的多次采样可以只采样一次把结果存在变量里复用。这个在着色器里很容易做到但容易被忽略。减少分支的方法是条件编译。前面提过用#define在编译时决定是否包含某段代码运行时就没有分支了。这个对移动端 GPU 特别重要因为移动端 GPU 对分支的惩罚比桌面端大得多。6.2 移动端适配的注意事项移动端适配最大的问题是性能和精度的平衡。性能方面移动端 GPU 的填充率通常比桌面端低所以渲染分辨率要控制。我的做法是根据设备像素比动态调整渲染分辨率高像素比的设备适当降低渲染分辨率用 CSS 放大显示。这样视觉上差别不大但性能提升明显。精度方面移动端 GPU 对highp精度的支持不一致。有些设备支持有些不支持。我的做法是在着色器里用#ifdef GL_FRAGMENT_PRECISION_HIGH做条件编译支持highp就用highp不支持就用mediump并做精度补偿。还有一个问题是纹理尺寸限制。移动端 GPU 的最大纹理尺寸通常比桌面端小如果图像尺寸超过限制需要分块处理。我的做法是在上传纹理前检查尺寸超过限制就自动缩小并提示用户。6.3 不同浏览器的兼容性处理不同浏览器对 WebGL 的支持程度不一样兼容性处理是必须的。首先是WebGL 版本。有些老设备只支持 WebGL 1.0不支持 WebGL 2.0。我的做法是优先尝试 WebGL 2.0失败则降级到 WebGL 1.0。两个版本的着色器语法有差异需要准备两套着色器或者用预处理宏来适配。其次是扩展支持。有些效果需要特定的 WebGL 扩展比如浮点纹理、深度纹理。我的做法是在初始化时检查扩展支持情况不支持的功能就禁用对应的效果节点并在 UI 上给出提示。最后是上下文丢失。WebGL 上下文可能因为各种原因丢失比如 GPU 驱动崩溃、系统休眠。我的做法是监听webglcontextlost和webglcontextrestored事件在上下文丢失时保存状态恢复时重新初始化。这个机制能保证用户不会因为上下文丢失而丢失工作进度。7. 一些个人体会和后续扩展方向artcraft 做到现在我最大的体会是工具的价值不在于功能多而在于能不能让用户把想法落地。我见过很多功能极其丰富的创作工具但用户打开之后不知道从哪下手。artcraft 的设计哲学是“少即是多”——每个效果节点都足够简单但组合起来能实现复杂的效果。后续的扩展方向我目前考虑的有几个。一是效果节点的脚本化让用户可以用 JavaScript 写自定义效果节点这样扩展性会强很多。二是协作功能让多个用户可以同时编辑一个预设实时看到对方的修改。三是AI 辅助调参用户描述想要的效果系统自动推荐参数组合。这几个方向都在探索阶段具体怎么做还没定。如果你也在做类似的项目我的建议是先把核心管线搭好把两三个效果做扎实不要一开始就追求大而全。管线设计得好后面加效果就是水到渠成的事。管线设计得不好加一个效果得改五个地方那才是真正的噩梦。另外多花时间在参数设计上参数设计得好用户用起来顺手比多十个效果都管用。
