在浏览器里看到一个由纯代码驱动的3D旋转立方体整个项目的存档尺寸只有1KB——这个数字比你手机上一张普通壁纸还要小。很多人第一反应是“骗人的吧”但如果你愿意相信数学而不是素材1KB做3D游戏开发真的不是玄学而是在极简主义思路下把图形学核心算法“榨干”的结果。这个项目最吸引我的地方在于它不依赖任何模型文件、贴图资源或图形引擎只靠几十行代码就完整走完了图形渲染的流程。这篇东西适合两类人一类是想入门3D图形但被各种库和管线吓住的新手另一类是玩过代码压缩、想挑战体积极限的老手。看完你会明白1KB的3D游戏到底是怎么运作的也会拿到一套可以直接抄的旋转立方体代码和压缩思路。1. 先把“1KB”这个前提拆开看1.1 为什么1KB能渲染出3D画面很多人一听“1KB做3D”第一反应是文件里肯定藏了一个预渲染好的GIF或者视频序列。其实不是。1KB项目里没有美术资产只有源代码。传统游戏之所以体积庞大是因为模型网格、贴图、音频、动画曲线全都作为数据打包进文件里。而1KB项目换了一条路所有图形都靠运行时计算生成。打个比方传统游戏像是你雇了一个厨师团队带着一整车的食材和厨具过来做饭而1KB项目更像是你给了厨师一张写着“蛋炒饭”的纸条他自己去菜市场买菜、淘米、烧火在约定时间内把饭端上来。前者数据密集后者计算密集。浏览器里的Canvas和JavaScript就是那个厨师而你的代码就是那张纸条。所以在1KB项目里真正的“资产”只有三个几何体的数学描述比如立方体就是8个顶点的坐标组成的公式。旋转和透视的变换逻辑这是把三维坐标映射到二维屏幕的核心。绘制指令用线条或填充把算好的点连成面。这三个东西用代码写出来本质上就是几百个字符完全塞得进1KB。关键在于别在代码里保存任何一个多余的字节每个字符都要有它存在的理由。1.2 3D图形的数学底子透视投影是怎么回事要让屏幕上的二维画面产生3D感靠的是一套非常古老的数学工具——透视投影。你可以把它理解成“人的眼睛在看世界”离得近的物体看起来大离得远的物体看起来小。计算机做这件事并不复杂核心公式只有一个屏幕X 画布中心X (物体X * 缩放系数) / 物体Z 屏幕Y 画布中心Y (物体Y * 缩放系数) / 物体Z这里的“物体Z”是物体距离相机的深度值。除以Z之后越远的东西在屏幕上占的像素越少透视效果就出来了。缩放系数则用来控制视野范围一般取一个几百的常数比如300到500。我们平时在游戏里看到的模型旋转、视角移动本质上就是对顶点坐标做矩阵乘法。1KB项目里不需要实现完整的矩阵库只需要对每个顶点手动算几个三角函数。比如绕Y轴旋转一个点公式长这样x x * cos(θ) z * sin(θ) z z * cos(θ) - x * sin(θ)绕X轴旋转同理只是换成y和z参与运算。只要把这两组公式叠在一起就能让立方体在空中随意翻跟头。这些变换代码在压缩前也就十几行压缩到极致后甚至能合并成一行表达式。1.3 代码生成图形杯子、茶壶和立方体都能只用几行公式最近在网上经常能看到“用计算机图形画一个杯子”的提问很多人以为画个杯子需要导入3D建模软件导出的网格文件。实际上杯子这类旋转体完全可以用数学公式生成——把一条二维曲线绕中心轴转一圈就可以生成杯子、水壶、花瓶这些曲面形状。这种手法叫“旋转曲面”在极简图形项目里非常常用。1KB项目里的核心思路和画杯子是同一个道理不要存储顶点数据而是在运行时用循环生成。比如一个立方体的8个顶点没必要写8行坐标用一层循环配合位运算就能得到。这种“代码生成图形”的思路让体积限制不再是问题因为无论物体多复杂只要能用数学描述它就只占几十个字符的代码空间。2. 从0到1手写一个旋转立方体2.1 开发环境怎么选才不浪费预算1KB项目的最佳战场是浏览器因为浏览器提供了Canvas绘图API不需要引入任何额外文件。你只需要新建一个HTML文件或者直接打开开发者工具的控制台就能开始跑图形代码。为什么不用Three.js或者WebGL因为Three.js的库文件就有几百KB光加载它就已经超过预算了。我实测下来Canvas 2D的moveTo、lineTo和fill接口处理几百个顶点绰绰有余。WebGL虽然性能更强但初始化着色器和缓冲区就要几十行样板代码1KB根本不够折腾。所以对于纯几何体演示Canvas 2D是性价比最高的选型。如果你要做的只是旋转立方体、星星、弹幕粒子这些基础图形完全没必要上重型物流。2.2 核心数学旋转、透视、连线一条龙一个旋转立方体的完整流程是这样的定义立方体的8个顶点坐标中心在原点边长为2。每帧把顶点绕X轴和Y轴旋转一个角度角度随时间递增。对旋转后的顶点做透视投影得到屏幕坐标。按12条边的索引把对应的点连起来画出线框。第一步和第四步几乎不占什么空间最关键的是第二步和第三步。旋转用三角函数做矩阵乘法透视用缩放系数 / (深度 相机距离)算出每个顶点的屏幕放大比例。相机距离一般取4到6太小画面会爆出屏幕太大会显得物体很遥远。面数多一点的话还要做深度排序。比如一个填充立方体有6个面每帧把6个面按平均深度从远到近排列先画远的再画近的这样遮挡关系才正确。2.3 第一版代码长什么样我提供一个可以直接复制运行的开发版逻辑清晰方便你理解。这段代码没有刻意压缩但即便如此它的体积也只有大约1KB出头。canvas styleposition:fixed;inset:0;background:#000/canvas script const c document.querySelector(canvas), g c.getContext(2d); const W c.width innerWidth, H c.height innerHeight; let t 0; const V [ [-1,-1,-1], [1,-1,-1], [-1,1,-1], [1,1,-1], [-1,-1,1], [1,-1,1], [-1,1,1], [1,1,1] ]; const E [ [0,1],[0,2],[1,3],[2,3], [4,5],[4,6],[5,7],[6,7], [0,4],[1,5],[2,6],[3,7] ]; function rot(v){ let x v[0], y v[1], z v[2]; let x1 x * Math.cos(t) z * Math.sin(t); let z1 -x * Math.sin(t) z * Math.cos(t); let y1 y * Math.cos(t * 0.8) z1 * Math.sin(t * 0.8); let z2 -y * Math.sin(t * 0.8) z1 * Math.cos(t * 0.8); return [x1, y1, z2]; } function draw(){ g.fillStyle #000; g.fillRect(0, 0, W, H); g.strokeStyle #0ff; g.lineWidth 2; for(let i 0; i E.length; i){ let a rot(V[E[i][0]]), b rot(V[E[i][1]]); let d 5, sa d / (d a[2]), sb d / (d b[2]); g.beginPath(); g.moveTo(W / 2 a[0] * 200 * sa, H / 2 a[1] * 200 * sa); g.lineTo(W / 2 b[0] * 200 * sb, H / 2 b[1] * 200 * sb); g.stroke(); } t 0.02; requestAnimationFrame(draw); } draw(); /script跑起来你能看到一个青色的线框立方体在黑色背景上旋转两个轴的旋转速度不同所以整体会呈现一种翻滚感而不是呆板地绕单一方向转。requestAnimationFrame保证它在显示器刷新率下流畅运行t作为全局时间变量贯穿旋转和后续的光照计算。到这里你已经拥有一个1KB出头、但完整度很高的3D演示了。接下来要做的是怎么把它进一步压缩或者让它更好看。3. 画面质感升级用填充面替代线框3.1 画家算法让遮挡关系不再穿模线框立方体最大的问题是透明感太强你能同时看到前面和后面的边画面缺乏“实体”的感觉。想要提升质感最简单的办法是把立方体的6个面用颜色填满。但填充面引入了一个新问题后面的面板晚画怎么办答案就是画家算法。它和传统油画的绘制顺序一模一样先画远处的物体再画近处的物体后画的会盖住先画的。具体到立方体每一帧我都计算出6个面的平均Z值然后按Z从大到小排序——Z越大意味着离相机越近——近的面最后画。代码结构大致是let faces []; // 往faces里塞入每个面的深度、顶点列表、颜色 faces.sort((a, b) b.depth - a.depth); for(let face of faces){ drawPolygon(face.points, face.color); }排序的代价是O(n log n)对于6个面来说几乎可以忽略。但它是整个填充管线的基石少了它就会出现“前面盖后面”或者“闪烁抖动”的尴尬画面。3.2 法线与光照两行代码换来的体积感纯色的填充立方体还是不够立体因为每个面亮度一样看不出方向。真正的体积感来自光照光线照到的面亮背光的面暗。实现起来也不需要什么复杂的PBR一个点积运算就够了。每个面都有一个法线向量它的意思是“这个面朝哪个方向”。光照方向我取一个固定向量比如[1, 1, 1]代表光从右上角照过来。法线和光照方向的点积值域在-1到1之间值越大说明面越朝光。把这个值映射到颜色的明度上就生成了极为朴素的“伪光照”。代码里核心就两段let nx /* 法线x */, ny /* 法线y */, nz /* 法线z */; let b nx * 0.577 ny * 0.577 nz * 0.577; // 点积 let col rgb(${b * 200 55}, ${b * 180 40}, ${b * 220 80});压缩之后可以连rgb字符串都省掉直接用HSL颜色或者预置的颜色数组。我实测下来加上这一步立方体立刻从“平面几何作业”变成了“有点氛围感的小Demo”成本只有十几行代码非常划算。3.3 色彩循环和复古扫描线低成本氛围感1KB项目的乐趣在于用极小的成本制造“看起来很厉害”的效果。颜色循环就是其中性价比最高的一招。每帧让色相值递增几度整个画面就会像霓虹灯一样轮流变色。在JavaScript里用hsl(色调, 饱和度, 亮度)可以很自然地实现g.fillStyle hsl(${t * 50 % 360}, 90%, 50%);扫描线效果更简单在绘制完成后每隔4个像素画一条半透明的黑色横线模拟老式CRT显示器的条纹。之所以说它适合1KB项目是因为它不需要增加任何数学计算只需要一个循环加一个fillRect却能显著增加画面的“设计感”。我也是在把立方体换成填充模式之后才意识到一个道理1KB的限制反而逼着你把精力放到“图形感受”上而不是堆素材。一个色彩循环、一个扫描线、一个抖动纹理成本极低但观感提升是肉眼可见的。这和商业项目里那种“贴图叠滤镜”的思路完全不同属于典型的做减法。4. 把代码压进1KB的实用压缩路线4.1 第一刀变量名、空格和表达式合并开发版代码写完之后第一步是用工具压缩。推荐用Terser或者Closure Compiler选“简单优化”模式它会把变量名全部改成单字母、去掉所有注释和空白。但是别指望工具一步到位工具压缩之后往往还有数百字节的冗余需要手动继续优化。手动优化的第一刀从变量名开始。函数名和变量名不需要有语义全部换成a、b、c、d这类单字母。第二刀是把多处重复的Math.cos(t)和Math.sin(t)提取成局部变量因为Math这个前缀重复写很多次非常费字节。第三刀是合并表达式比如把透视投影里的d / (d z)直接写成5/(5z)省去变量定义。如果代码里有多条赋值语句可以用逗号运算符放进同一个for循环里省掉大括号和分号。我试过把上面的开发版压缩工具处理后降到约600字节再手动合并表达式后降到450字节左右。到这一步里面还剩大量优化空间但已经足够塞进1KB了。4.2 第二刀用循环生成几何数据压缩体积最狠的方式不是删字符而是把“数据”变成“代码”。立方体的8个顶点坐标如果用数组写出来是8行代码但如果用循环生成可以缩到几行。立方体顶点有一个天然规律每个坐标值都是-1或1。所以我可以写一个循环根据索引i的二进制位来决定当前点的坐标// i的二进制位低1位控制x符号低2位控制y符号低3位控制z符号 x i 1 ? 1 : -1; y i 2 ? 1 : -1; z i 4 ? 1 : -1;这样8个顶点就通过0到7的循环全部生成了。面的索引也可以用字符串存储比如0132代表面的四个顶点顺序字符串遍历的字节开销远小于二维数组。这种“算法生成数据”的压缩思路是1KB项目的核心哲学。你不再是一个数据的搬运工而是算法的建构师。同样一件事用数据表达可能要占100字节用算法表达可能只占30字节而且更容易压缩和变形。4.3 第三刀字节预算表与最终瘦身为了不让优化过程失控我会列一张字节预算表模块预算Canvas准备与resize80字节顶点生成与旋转250字节透视投影与坐标变换150字节骨架绘制或面填充200字节颜色/光照/循环动画150字节时间控制与帧循环100字节总计约930字节这个预算留了几十字节的余量给兼容性处理和压缩边界情况。实际操作中如果发现某个模块超额我会优先砍掉“花哨”的部分比如扫描线效果或第二层旋转轴——减少一个旋转轴可以把好几个Math调用直接删除立省100字节以上。完成压缩后用new Blob([code]).size检查实际的字节数。注意不要用code.length因为如果你的代码里有中文注释或非ASCII字符length算的是字符数而不是UTF-8字节数会严重低估体积。我吃过这个亏本地看到字符数不到1024结果保存的文件已经1200字节了。5. 我踩过的坑闪烁、精度与兼容性排查5.1 画面乱跳或闪烁先查排序和清屏旋转立方体最常见的bug不是黑屏而是画面撕裂或闪烁。我排查此类问题的顺序是先确认每帧绘制前有没有执行fillRect全屏清空再检查填充面的绘制顺序是不是稳定的从远到近。如果排序条件写得不对某些帧会突然把近面画到后面你就会看到闪烁。在极简代码里排序条件经常因为变量名太短而写错比如把b.depth - a.depth写成了a.depth - b.depth画面就变成近的先画整体看起来像“X光透视”。排查时最有效的方法是写一版未压缩的代码把排序逻辑单独抽出来打印确认无误后再压缩回去。5.2 顶点飞来飞去透视公式里的Z陷阱透视投影里除以Z的时候如果Z等于零或者变成负数顶点就会突然飞到屏幕外产生“穿天穿地”的视觉异常。旋转立方体在转到某些角度时某个顶点确实可能跑到相机后方这时候Z会为负透视公式就会失效。解决办法有两个一是在除法之前把Z值钳制到一个很小的正数比如Math.max(z, 0.1)二是在投影前判断如果Z小于0.1就跳过这根线或这个面。第一种更省字节我推荐直接用d / (d z)这种带偏移的公式因为d z天然避免了Z为0的情况只要立方体的尺寸不超过相机距离基本不会碰到负Z。5.3 超了预算怎么办砍功能优先级代码超过1KB时最忌讳的是“这也要那也要”地硬塞。我会按优先级砍第一优先级保留旋转、透视、绘制循环这些是核心砍掉就没意义了。第二优先级保留填充面、伪光照、颜色这是画面质感的来源。第三优先级可砍多轴旋转、扫描线、粒子效果、输入交互、音频反馈。如果砍完还是超说明你把代码写得太“胖”了比如用了大量if分支而不是数学表达式或者每个功能都做了过度封装。极简项目里不需要抽象和复用面向编译器的逻辑越直接越好因为这省的是运行时字节数。5.4 高分屏模糊与老设备适配1KB项目在手机上跑时很容易遇到画面模糊的问题原因是设备的高DPI缩放和Canvas像素没有对应上。最省解决方案是把Canvas尺寸设置为物理像素c.width innerWidth * devicePixelRatio; c.height innerHeight * devicePixelRatio;投影坐标里的W / 2和H / 2虽然会变小但视觉上整体比例是正常的。老设备上如果遇到requestAnimationFrame不兼容可以降级为setInterval轮询只要把定时器频率设为16毫秒效果相差不大。实测下来这个适配一共不超过80字节。6. 从1KB到4KB极简主义能延展到什么程度1KB项目的意义不在于“越省越好”的自我感动而是它教会你如何用最有创造力的方式解决问题。当你习惯了1KB再做4KB的3D项目时会突然觉得“资源太多了”可以加入动态生成的地形、粒子系统、简单的声音合成甚至写个小游戏逻辑。我个人在实际折腾中的体会是代码体积限制真的会改变思考习惯。以前我写图形代码总是先考虑引擎、插件、预设现在写之前第一反应是“这个能不能用公式生成”“那个能不能用循环算出来”。这个转变放到任何领域都通用。如果你也想做自己的1KB项目我建议从旋转立方体开始先把线框、填充、光照、颜色循环这四样跑通再加上一个最简单的玩家交互比如鼠标控制旋转方向你的“1KB 3D游戏”就已经具备雏形了。之后不管是加障碍物、加计分器还是加声效都是在这个基础上做增量而你已有的这套图形管线足够撑起你绝大多数创意。最后分享一个小技巧每压缩到一个节点把当前版本另存为一个文件。我习惯用cube-900b.html、cube-800b.html这种方式标记。这样一旦某次压缩把代码改坏了能立刻退回到上一个可用版本而不是对着乱七八糟的单字母变量名抓瞎。极简主义的路上留一手永远比追求极限重要。