artcraft这个名字是我给一个内部实验项目随手起的代号，拆开看就是“Art + Craft”，艺术加手艺。项目本身是一个跑在浏览器里的程序化艺术纹理生成器，用来在做小游戏、场景原画和技术Demo时快速产出可平铺的手绘质感贴图。早期美术资源紧张的时候，我经常花一个晚上画一张256x256的石头纹理，结果放进引擎里一拉伸就糊成一片。后来我决定换个思路：不画纹理，写一个能“画纹理”的工具，让程序根据噪声、笔刷和纸纹自动算出手绘风格的贴图，这就是artcraft的起点。
这个工具解决的核心问题有三个：一是纹理分辨率的限制，程序化生成可以做到无限分辨率，需要多大就采样多大；二是风格统一性，所有贴图都走同一套生成管线，放在一个场景里气质天然统一；三是迭代速度，调参数比重绘快得多，一张草稿质感的纹理在一秒内就能出结果。适合参考的人包括独立开发者、技术美术、对程序化生成感兴趣的图形程序员，以及那些和我一样不太会画画但需要美术资源的开发者。
1. 项目概述与核心需求
1.1 一句话解释artcraft
artcraft本质上是一个“规则驱动的纹理合成器”。你输入一组参数——颜色范围、噪声密度、笔刷分布、纸纹强度——它输出一张位图，也可以把位图转成可平铺的纹理。它不追求照片级真实，反而刻意保留手绘的不完美感，比如笔触边缘的毛刺、颜料叠加时的透明度变化、纸张颗粒对笔迹的干扰。这些“不完美”恰恰是程序化生成里最难复制的一部分，也是这个项目最花功夫的地方。
从架构上看，artcraft分三层。第一层是噪声基底，负责决定整张图的明暗结构和色块分布；第二层是笔刷层，用不同形状和透明度的笔刷在底图上反复“涂抹”，模拟手工叠色的过程；第三层是材质后处理，加上纸纹、颗粒、色调偏移，让结果更像真实纸面作品。三层之间通过一系列权重参数串联，调整任何一个参数都会影响最终输出。
1.2 它能解决什么场景下的问题
实际使用中最典型的场景是：做一个小场景，需要五六张风格一致的背景纹理。如果用传统方式，一个角色配一套手绘贴图，工作量会随数量线性增长，而且不同时间画出的纹理色调很容易跑偏。artcraft的做法是定义一套“风格模板”，比如暖色水彩风、炭笔速写风、低饱和扁平风，同一套模板配合不同的噪声种子和调色参数，就能批量生成一系列视觉上同源但又各不相同的纹理。
另一个很有用的场景是给3D模型做粗糙度贴图或高度贴图。手绘的粗糙度贴图往往需要叠加好几层图层才能看出层次感，而artcraft可以直接从颜色纹理的明度通道中提取一张对应的粗糙度图，省掉手工拆分通道的时间。这些算法生成的结果天然无缝衔接，平铺到模型上看不到明显的边界线。
1.3 目标用户与技术门槛
做这个项目需要的技术栈不算深，核心是图像处理的基础知识、噪声算法和一点图形学的概念。我用的是TypeScript加Canvas 2D，没有引入复杂的框架，也没有用WebGL做GPU加速，目的是保证代码足够直白，每一步计算都能被追踪和调试。如果你懂一点Canvas的基础API，比如getImageData、putImageData、drawImage，那么这个项目的核心代码读起来不会太吃力。
但如果你想直接拿去生产环境用，可能需要再补一点图像编码的知识，比如如何导出无损PNG、如何处理颜色配置文件（ICC Profile）以避免在不同设备上出现色差。这些都属于细节问题，下面会专门讲。
2. 整体设计思路与方案选型
2.1 为什么选程序化生成而非手工绘制
手工绘制的优点是上限高，缺点是下限不稳定、耗时不可控。artcraft选择的程序化生成路线，本质是“用规则换取确定性”。程序化生成并不是要替代画师，而是把重复劳动中可量化的部分抽象出来，比如纸张纹理的铺陈、同一色系不同深浅的渐层、笔刷痕迹的随机抖动。这些操作如果纯靠手绘，一两个小时才能画一张，而程序只需要几毫秒。
更重要的是，程序化纹理在工程上是“可持续维护”的。手绘图一旦画错，修改的成本很高，可能要重画。而程序化纹理里，噪声频率、笔刷半径、混合模式这些都是暴露在参数面板上的变量，想调色调？改一个色相偏移值就行。想增加纹理细节？把噪声的八度数量从4改成6就行。这种可调性让整个生产流程变得更像调音台操作，而不是每一次都要从头来过。
2.2 模块划分与数据流
整个artcraft的数据流可以简化成下面这条链：
参数配置 -> 噪声基底计算 -> 笔刷分层叠加 -> 纸纹混合 -> 颜色校正 -> 输出位图每一步对应一个独立的模块，模块之间只传递图像数据，不共享内部状态。这样设计的直接好处是方便测试。我可以只盯着噪声基底这一层跑一组单元测试，确认明暗分布符合预期；也可以单独把纸纹混合抽出来，尝试不同的混合公式，而不用关心色块是怎么来的。
其中笔刷分层叠加是最复杂的一环。它不是简单地在位图上画圆，而是模拟真实画笔的“吸水”和“释放”过程。每次绘制会生成一个跟随参数变化的笔触掩码，再根据这个掩码修改目标区域的像素颜色。笔画的透明度、间距、抖动幅度都受叠加次数影响，画得越多，颜色越深，纹理越密。
2.3 理论算法怎么落地：从None开始造轮子
很多现成的图像处理库都提供噪声和滤镜功能，但我坚持从零实现核心算法，因为依赖越少，调试越容易。一套从零手写的噪声函数，一旦结果不对，你可以直接看到底是插值问题、梯度问题还是坐标缩放问题。而引入外部库时，问题往往被封装在黑盒里，排查起来反而更费时间。
不过这不意味着完全不参考成熟的算法实现。比如Perlin噪声和Simplex噪声的经典实现方式，我在阅读相关图形学资料后自己推导了一遍，再用手写的版本替代。这样做还有一个附带好处：生成的纹理不会携带任何现成库的签名特征，风格上更容易做差异化。
3. 工具选型与工程化配置
3.1 运行时环境选择：浏览器优先
artcraft首选浏览器作为运行环境，核心原因是调试方便。浏览器开发者工具可以实时看到Canvas上的每一帧输出，断点能看到每个像素的RGBA值。同时，浏览器天然跨平台，不需要为不同类型的操作系统单独编译安装包。对一个工具类项目来说，用户能打开网址直接使用，比让用户配置Python环境轻松太多了。
但浏览器方案也有明显短板，最典型的是单线程的阻塞问题。当纹理尺寸达到2048甚至4096时，逐像素计算会产生明显卡顿。我的解决方案是把重计算任务丢给Web Worker，主线程只负责参数面板的交互和最终展示，计算完成后再把位图传回来。下面会有更详细的做法。
3.2 核心依赖与配置清单
为了保持代码精简，我的package依赖清单非常短：
- TypeScript，用来做类型检查和构建；
- 一个轻量的测试框架，用来跑核心算法的单元测试；
- 无其他运行时依赖。
配置上重点有两条。第一是tsconfig里开启strict模式，确保所有类型推断都是显式的，避免像素操作时出现隐式的类型转换错误。第二是构建时指定目标为ES2020，保留了BigInt、Promise.allSettled这些现代特性，同时又能兼顾主流浏览器的兼容性。
3.3 核心类结构设计
代码里最关键的是三个类：NoiseField负责生成二维噪声场；BrushEngine负责响应参数绘制笔刷层；PaperTexture负责生成纸纹并做最终的混合叠加。三个类通过一个ArtGenerator门面类组合，对外只暴露一个generate(config): ImageData方法。
设计成门面模式的好处是把复杂度收敛在内部。调用方不需要理解噪声的梯度计算细节，也不需要关心Canvas的像素缓冲区操作，只需要传一个配置对象就能拿到结果。这样即使将来把运行环境从浏览器迁移到服务端的Canvas实现，接口也不需要改动。
4. 核心算法与关键实现细节
4.1 底纹生成：Simplex噪声的实现与调参
底纹是整张纹理的骨架。我用Simplex噪声而非更常见的Perlin噪声，原因是Simplex的计算效率更高，在高维插值时表现更好，而且生成的噪声没有明显的网格方向性。实现上，二维Simplex噪声的核心逻辑是获取目标点所在三角形区域、计算顶点贡献权重、然后用梯度点积进行插值。
下面是去掉外围误差判断后的核心伪代码简化版：
function simplexNoise2D(x: number, y: number, perm: Uint8Array): number { const F2 = 0.5 * (Math.sqrt(3) - 1); const G2 = (3 - Math.sqrt(3)) / 6; const s = (x + y) * F2; const i = Math.floor(x + s); const j = Math.floor(y + s); const t = (i + j) * G2; const x0 = x - (i - t); const y0 = y - (j - t); // 判断第二个顶点位置 const i1 = x0 > y0 ? 1 : 0; const j1 = x0 > y0 ? 0 : 1; const x1 = x0 - i1 + G2; const y1 = y0 - j1 + G2; const x2 = x0 - 1 + 2 * G2; const y2 = y0 - 1 + 2 * G2; // 计算三个顶点的贡献，然后用梯度表插值 // ... 省略梯度哈希和衰减计算 return result; }调参时的核心指标是“视觉频率”。想让纹理更细碎，就把采样坐标乘以一个更大的倍数；想让色块更平滑，就减小倍数。实践中我一般设置三到四个不同频率的噪声层相加，形成多尺度细节。举个例子，第一层频率2.5负责大色块，第二层频率8负责中等程度的坑洼感，第三层频率22负责精细颗粒。三个层按0.6、0.3、0.1的权重混合，出来的底纹很接近水彩在纸张上自然晕染后的效果。
4.2 笔刷层：stamp、抖动与累积透明度
底纹画完之后，下一步是用笔刷往上叠加色块。这里的笔刷不是Photoshop里那种智能算法，而是最朴素的“印章式”绘制。我预先创建了几种笔刷形状的内存画布，比如圆形笔刷、带有随机毛刺边缘的湿笔刷、颗粒感强烈的干笔刷。每次绘制时，把这些笔刷形状随机旋转、缩放、平移到目标区域，再用drawImage盖上去。
关键点在“累积透明度”。如果一张纹理只叠一层笔刷，会显得很单薄，缺乏手绘时那种反复涂抹的厚重感。我做了两层叠加逻辑：第一层用60%到70%的透明度大面积铺色，确定整体色调；第二层用30%到40%的透明度在小范围叠加深色和亮色，制造层次感。两层中间还会插入基于噪声的抖动偏移，让笔刷轨迹不至于完全平行，模拟出手腕微颤的痕迹。
这里有一个容易踩的坑：Canvas的globalAlpha对drawImage是直接生效的，但它本身不带色彩混合的物理意义。如果你连续用50%透明度绘制同一区域两次，最终透明度不是100%，而是1 - (1-0.5)*(1-0.5) = 75%。这个算法和真实颜料的叠加规则很接近，但和大多数人对“叠加=相加”的直觉不一致。明白这一点后，才能更好地控制纹理的深浅，不至于反复涂抹后整块区域变成一坨深色。
4.3 纸纹混合：让算法生成结果像真的画在纸上
程序化生成手绘风格最缺的是质感，也就是触感。纸纹混合就是用来补足这一层的。我用一张“纸纹模板”来模拟纸张纤维的隆起和凹陷，在混合时把这些细节叠加到颜色纹理上。
纸纹模板本身可以用另一种噪声生成：高频噪声加上方向性拉伸，让凹槽的走向略微倾向于某个角度，模拟手工纸在抄纸过程中纤维的排列方向。混合方式我尝试过三种，最终选择了“线性减淡”和“柔光”的混合方案：
- 先用柔光模式把纸纹的明暗细节叠到颜色纹理上，让纸纹感觉是“长在”颜色里的；
- 再叠加一层极窄的线性减淡高光，模拟纸张在光照下的纤维反光。
这一步做完，整张图立刻从“电脑画的”变成了“纸上画的”。我在做用户测试时，好几个参与者在不知道生成过程的前提下，都以为这些纹理是用传统颜料手工绘制的。
5. 性能优化与工程实战
5.1 离屏Canvas与对象池
绘制过程中会产生大量的中间画布对象。如果每生成一次噪声场就新建一个Canvas和一个ImageData，短期内会触发大量的内存分配和垃圾回收，导致整体耗时忽高忽低。我的优化办法是开启一个“离屏画布池”：
const canvasPool: HTMLCanvasElement[] = []; function getOffscreenCanvas(width: number, height: number): HTMLCanvasElement { const existing = canvasPool.pop(); if (existing) { existing.width = width; existing.height = height; return existing; } return document.createElement('canvas'); }这个对象池的设计很简单，但效果非常显著。在高频拖动参数滑块时，每一帧都会触发重绘，如果每帧都重新创建画布，浏览器内存会迅速膨胀，页面滚动都会变得迟滞。用池化之后，内存分配次数明显下降，连续拖动滑块也稳定在60帧左右。
5.2 分块生成与Web Worker
当纹理尺寸超过1024像素时，单线程逐像素计算会产生明显的等待。我的方案是把整张纹理切成4块到16块小图，用Web Worker并行计算，每块算完再合并回主线程的Canvas上。
切块需要注意的是接缝问题。噪声计算必须保证采样坐标连续，也就是说，假设纹理尺寸是1024，分成四块，每块的大小是512，但计算第一块（0-511）时的坐标范围是0-512，计算第二块（512-1023）时坐标范围也是0-512，只是偏移了512。这样两块相接处的像素值才会连续，不会出现明显的分界线。
// 主线程 const boundary = 1; // 重叠一个像素 const blockSize = 512 + boundary * 2; const worker = new Worker(new URL('./worker.ts', import.meta.url)); worker.postMessage({ width: blockSize, offsetX: 512 * blockIndexX - boundary, offsetY: 512 * blockIndexY - boundary, config: currentConfig });Worker内部完成后，只截取中间512x512的有效区域传回主线程，这样就天然处理了边界重叠。实测下来，4096x4096的大纹理，四线程并行比单线程快了2.7倍，而且接缝问题一次都没再出现过。
5.3 内存与缓存策略
像素操作最怕大数组频繁拷贝。代码里有一个容易忽略的细节：getImageData返回的Uint8ClampedArray每次都是新分配的。如果在循环里反复调用，内存压力会很大。所以我改成尽量用一次getImageData拿到完整帧，然后直接操作这个数组，而不是分多次取小块数据再拼接。
另外，颜色校正在很多实现里是最后才做的，但它其实应该在像素数组层面完成。直接遍历数组修改RGBA值，比先转成Canvas再交给滤镜处理要快得多。下面是一个简单的色相旋转实现：
for (let i = 0; i < data.length; i += 4) { const r = data[i]; const g = data[i + 1]; const b = data[i + 2]; // 简化的HSV色相旋转 const hsv = rgbToHsv(r, g, b); hsv.h = (hsv.h + hueShift) % 360; const [nr, ng, nb] = hsvToRgb(hsv); data[i] = nr; data[i + 1] = ng; data[i + 2] = nb; }这段逻辑放在Worker里跑，不会阻塞主线程的UI更新。颜色校正放在最后一步，也意味着之前的噪声、笔刷和纸纹计算全部完成后，再统一处理颜色分布，这样既能保证叠加时颜色的数学规律不受破坏，还能减少CPU计算量。
6. 常见问题与排查记录
6.1 纹理边缘接缝问题
这是程序化生成纹理最经典的问题。第一次生成可平铺纹理时，我把噪声坐标直接映射到了像素坐标，结果平铺后边界处出现了明显的断裂感。原因很简单：噪声函数本身是连续的，但如果你只在一个有限矩形内采样，矩形左边界和右边界的噪声值没有关联，贴到模型上当然会断开。
解决办法是“环绕采样”。我把噪声输入坐标对齐到一个环形空间：当坐标超过纹理宽度时，用取模运算把它映射回纹理内部。这看起来简单，但需要确保噪声函数在环形边界上的梯度也是连续的。最简单可靠的做法是先把噪声坐标映射到[0, 2π]的范围，用三角函数把二维平面映射到环面，然后再计算噪声。代价是计算量多了一点点，但换来绝对无缝的结果，完全划算。
6.2 笔刷边缘锯齿与线条毛刺
用drawImage绘制笔刷时，边缘如果完全透明，就会产生明显的锯齿。尤其在使用干笔刷时，笔刷边缘的透明像素在放大后看起来像一条条割裂的线。处理手段有两个：一是所有笔刷模板在创建时，把边缘透明度从100%平滑渐变到0%，不要一步到位；二是在最终输出前做一次轻度的“去条纹”后处理，遍历每个像素，把与周围像素差异过大的颜色点往中间值拉近。
这个方案也有副作用，去条纹过度会让纹理变得有点“肉”，失去手绘的锐利感。我最后的平衡点是：去条纹只作用于纸纹混合之前的笔刷层，纸纹混合之后不再做任何平滑，保留纸面纤维的颗粒感。
6.3 不同浏览器上的颜色显示不一致
Canvas颜色在不同浏览器上出现差异，根本原因是颜色管理策略不同。有的浏览器默认按照sRGB空间解析颜色，有的则会尝试做广色域转换。我在项目最开始没有关注这个问题，结果在某个浏览器上导出的纹理色温明显偏冷，换到另一个浏览器又恢复正常。
排查过程花了一些时间。最终确认问题不在生成算法的计算公式，而是Canvas初始化时没有做显式的色彩空间声明。解决方案是创建Canvas时手动设置colorSpace属性为srgb：
const canvas = document.createElement('canvas'); canvas.width = size; canvas.height = size; const ctx = canvas.getContext('2d', { colorSpace: 'srgb' });这样能保证所有现代浏览器按同一套色域标准解析像素。虽然对绝大多数用户来说，微小的色差不会影响使用，但如果你要拿这些纹理做严格的生产素材，这个设置是必须的。
6.4 移动端内存占用过高
移动端浏览器对Canvas的内存限制非常严格。一张2048x2048的Canvas，光是像素缓冲区就需要大约16MB内存，如果同时创建多张离屏Canvas，很容易触发浏览器的内存回收甚至直接白屏。我在移动端测试早期就遇到过一次页面崩溃，排查后发现缓存池里积压了太多大画布没有释放。
解决方案有两个层面。一是把缓存池的上限控制在4张以内，超过之后直接丢弃而不是继续缓存；二是检测屏幕尺寸和像素密度，对超过一定规格的生成任务自动切换到分块生成模式，并降低后台Worker数量，避免同时占用太多内存。
我建议做这个项目时也保持同样的思路：宁愿损失一点流畅度，也不能让内存在一次操作中翻倍。对工具类应用来说，稳定性比极致的响应速度更重要。
6.5 参数实时调节时画面闪烁
实时调节滑块的场景下，画面会高频重绘。最开始我每次生成完都调用putImageData整帧覆盖屏幕，结果在参数变化时会出现上下半屏亮度不一致的闪烁。这个问题不是屏幕刷新率导致的，而是因为在某一帧的绘制过程中，上半屏已经用了新参数，而下半屏还在用旧参数。
解决办法是在主线程侧增加一个“只交换完整帧”的机制：Worker计算完成后，把整帧数据一次性交给主线程，主线程只在拿到完整帧之后才执行putImageData，算完一半就先放着的操作全部去掉。这样每次画面刷新看到的都是完整的最新帧，不再有半帧的撕裂感。
7. 扩展方向与个人体会
7.1 导出管线搭建
目前artcraft输出的是一张平面位图，但实际项目中往往需要多个贴图通道组合使用。我在项目里做了一个扩展：从颜色纹理中提取明度图作为粗糙度图候选，再用色相偏移生成一张色调变化幅度很小的高度图。这三个输出能组合出一套用于标准PBR流程的纹理打包方案，接入到主流引擎的材质编辑器里，素材质量可以满足大部分中小型项目的需求。
导出格式上，我首选PNG而不是JPEG，因为程序化纹理用到大量精细颗粒，JPEG的有损压缩会直接把纸纹细节压成色块。另一个建议是保留一份未合并图层的工程文件，把纸纹、笔刷层、底纹分开存放，这样后续改风格时不需要重新生成。
7.2 从外部导入笔刷资源
artcraft默认内置了几种笔刷形状，但一直用同一种笔刷会让批量生成的纹理显得单调。我后来添加了“自定义笔刷导入”功能：允许用户上传一张画布上只有黑色笔迹的透明PNG，程序读取它的Alpha通道来生成新的笔刷模板。
具体实现不复杂，用getImageData读出每个像素的Alpha值，生成一张灰度图，再交给笔刷引擎合成。导入的笔刷形状千变万化，这也意味着同一个噪声底纹和同一组颜色参数，换一套笔刷后能产生完全不同的视觉效果。
7.3 一点个人经验谈
做artcraft最大的收获不是学会了某个图形算法，而是理解了“工具思维”和“艺术家思维”的差别。写工具的时候，你的任务不是追求个别结果的出众，而是保证一大批同类结果的水平线足够高、风格足够统一。程序化生成很像驯马：你要的不是某一匹跑得特别快的马，而是能稳定奔跑一整天的整个马群。
踩过的坑里面，最值得记录的是“过度优化早了”。在最开始的版本里，我用大量精力优化了噪声函数的插值效率，结果发现整个生成流程的性能瓶颈根本不在噪声，而是在Canvas绘制笔刷的drawImage调用次数上。如果让我重新走一遍，我会先完整跑通整个流程，用性能分析工具找准瓶颈，再决定优化方向。
如果你也想做类似的程序化艺术工具，我的建议很简单：先从最朴素的像素遍历开始跑通MVP，不要一步到位做多线程并行、不要过早引入缓存池。先确认生成逻辑本身够稳定，再一步步加性能手段。这看起来慢，实际推进速度反而最快。
