在屏幕里
模拟真实空间

开场：
关于讲者

题叶 · Tiye tiye.me ↗

业余兴趣，就是好奇心和探索欲。用 Shader / WebGPU / VR 在屏幕里画数学图案，也写过脚本语言——总想知道每个规则会长成什么样。

兴趣项目

背景：
谁在用代码画数学

先交代这个领域的生态：Twitter/X 上活跃着一批用代码把数学变成图案的人，也在持续分享共用的规则与代码。认识他们，才看得懂后面每个 demo 在做什么。

这个圈子不叫“AI 画图”：作者写 Shader、粒子、迭代与微分方程，让 GPU 实时算成画面，同一段代码既是作品也是教程。下面先列出几位仍在活跃的创作者，再看他们常用的平台。

活跃的创作者 · Twitter / X

透视投影：
把三维放进二维屏幕

要画“空间”，得先回答：一个点用什么坐标描述，又怎样从三维投影到二维屏幕。定位（坐标）与投影（到屏幕）是所有 demo 的共同语言；Shader 的逐像素运行，会在后面的实践时间线里接上。

生成式画面里的一切——点、粒子、曲线、分形表面——都是空间中的坐标。看懂所有 demo 的钥匙只有三个动作：定位（坐标）、变换（旋转 / 平移）、投影（到屏幕）。旋转作为“改变坐标的规则”，留到数学概念一节展开。

茶壶线框网格：表面由大量三角形组成——每个三角形由三个顶点定义，顶点经透视投影落到屏幕后以边相连，这正是投影管线在每一帧做的事情。本地程序化生成的示意。

后面的 Shader 逐像素计算、Compute 更新粒子、手柄移动相机、VR 生成双视图——全都建立在这套坐标与变换之上。先有这些基础，再谈高复杂度图案才不悬空。

Ray Marching：
不用网格建模也能画空间

如果说上一节的「透视投影」是把三维坐标一步步换算成屏幕上的二维点，那 Ray Marching 就是另一条到达屏幕的路：不提前建网格模型，而是沿视线一步步走，直到碰到隐式定义的表面。两种手法放在一起看，正好是「算坐标」与「走空间」的对比。

核心是距离函数（SDF）：它回答“这个点离表面多远”，据此沿视线一步步前进，直到接近表面。这样就能直接渲染分形、反射、布尔运算等隐式几何。

Ray Marching / SDF：每一步根据距离场决定安全的前进距离。图片：Wikimedia Commons。

和透视投影对比

所以两种手法适合不同素材：有明确顶点坐标的网格模型交给投影管线；分形、反射这类“没有显式表面”的几何交给 Ray Marching 沿视线求交。

真正值得反复调整的不是公式本身，而是它周围的观看条件：相机、空间重复、表面着色、轨迹、颜色映射与迭代预算——它们决定同一套规则呈现为安静图案、膨胀世界还是无法预测的运动。

渲染计算：
把规则算成颜色

投影与 Ray Marching 给了两种“上屏方式”。最后一个关键问题：每个像素的颜色，到底是怎么算出来的？这就是渲染计算。

渲染计算是“规则 → 像素”的最后一公里：像素位置由投影或视线求交决定，再经法线、光照与颜色映射输出一个 RGB。数学结果本身不是颜色，把它变成颜色并算得足够快，才成画面。

至此地基拼齐了：坐标与投影决定“看哪里”，Ray Marching 决定“走多远”，渲染计算把规则变成颜色——而“每个像素都是一次函数调用”的逐像素运行，正是后面实践阶段里直接计算 Shader 的基础。分形、Compute 粒子与 VR 双视图，全都建立在这些之上。

用到的数学概念：
让边界变复杂的工具箱

坐标、投影、Ray Marching 与渲染计算背后，还有一批反复出现的数学概念。它们不是孤立的公式，而是同一个主题：重复局部规则，得到复杂边界。

旋转：两种相反的思路

旋转可以用两种相反的思路理解，都能表达“绕轴 n 转 θ”，但看问题的角度完全不同。一种把它当作作用在坐标上的变换：矩阵把整组坐标线性地转过去，罗德里格公式负责从轴和角度直接构造这张矩阵。另一种把它当作一个对象本身：四元数（几何代数里叫旋转子）把旋转“装”进四个数里，再用它去包裹向量。

① 变换旋转矩阵 · 罗德里格公式

旋转矩阵：输入向量 v，经矩阵 R 一次乘法得到 v'；R 由轴 n 与角度 θ 用罗德里格公式构造。它是一张“线性变换表”，对整组坐标一视同仁。

矩阵把旋转表达为一次乘法，与位移、缩放统一在同一套运算里，是引擎与 Shader 的标准形态。代价是九个数冗余、重复累乘会积累浮点漂移，需定期正交化——它更像“怎么算”，而不是“旋转是什么”。

② 对象旋转子 / 四元数

四元数 / 旋转子：把旋转装进 q 这一个对象里，向量被“夹”在中间 v' = q·v·q*；在单位球面上做 SLERP，就能在两次旋转之间平滑地走弧线。

旋转子是“旋转本身”：四个数、归一化即稳定、组合即乘法，SLERP 让相机旋转顺滑，也没有万向节死锁。它更像“旋转是什么”——后面手柄与 VR 的相机都依赖它。

更高复杂度的数学工具

我的尝试：
从工具到世界

这不是一条从“不会图形学”到“掌握图形学”的直线，而是一连串对反馈速度的追问：能不能更快看见？能不能更容易改变？能不能让系统自己长出下一步？

下面用五个阶段和十三个 demo 把这条线展开：有的证明公式能变成图像，有的证明工具能让实验变快，有的暴露出下一步的问题。播放前先讲该观察什么，播放后再讲它如何影响下一阶段。

真正费力的部分：
调试、数学与状态

这些 demo 看上去像一段段“效果”，但开发过程里最耗时间的往往不是写出第一个画面，而是让它可解释、可控制、可持续地运行。把困难说出来，才自然引出 AI Coding 可以帮到哪里、又不能替代什么。

从已有仓库看，这不是单一的 Shader 难题。WebGPU-Art/soluble 同时组织 WGSL、TypeScript、参数、bind group 与手柄控制；vr-dive 的 greddysnake 分支 则把 Ray Marching 放进 VR 的视角和交互约束。困难会在图形、数值、输入和运行环境之间来回传导。

AI Coding：
把想法变成实验

AI Coding 最适合生成式艺术的地方，不是替我决定作品长什么样，而是把“我想试一个假设”到“我看见它运行”的距离缩短。

生成式艺术里有很多“半懂不懂但很想试”的时刻：知道想要一种结构，却不知从哪个距离函数开始；知道一个吸引子的名字，却不熟悉方程。AI 能把模糊意图翻译成一组可以运行、可以失败、可以继续追问的实验。

模型越容易生成代码，人越需要判断：这个变化真正改变了结构，还是只换了颜色？结果是值得探索的空间，还是常见案例的表面拼接？AI 让代码更便宜，也让选择更重要。

未来的想象：
作品是一个入口

未来的生成式艺术可能不再以“最终图片”结束。它会更像一个可以进入的规则空间：你可以改变参数、加入动作，甚至让另一个 agent 继续修改它。

更有意思的方向不是生成更复杂的画面，而是让作品暴露自己的生成机制：观众知道哪些参数可改、动作怎样进入系统、一次变化由什么规则造成。作品因此同时像作品、工具和实验室。

这也带来可理解性与作者性的问题：观众能否理解自己的参与？实时计算和模型调用的成本如何进入作品？规则、代码与模型共同参与时，贡献如何被描述？

不止代码：
其他的生成艺术工具

今天一路都是从写 Shader、写规则出发的，但这远不是生成式艺术的全貌：还有一大批工具靠节点、参数与 AI 也能生成精美作品。它们不在今天分享范围，却值得被知道。

它们的共性依然是“定义规则，让结果自动出现”，只是输入不再是文本代码：拖连线、调参数、拼节点，或只给一句提示词交给模型。下面挑几个有代表性的。