Scratch画圆技巧：多边形逼近法与弧度概念详解

在 Scratch 里接到“画一个指定圆心和半径的圆”这种需求往往不是基础练习题而是真正要做项目的时候了比如做一张表盘、模拟圆周运动轨迹、画同心圆装饰等。这时候你会很快发现官方积木块里根本没有“画圆”这个动作画笔只能记录角色移动的路径而角色移动最直接的轨迹就是直线。所以绕不开的思路就是标题里的多边形逼近法——把圆看作无数条首尾相接的短线。而要让这些短线准确落在指定的圆心和半径上又必须吃透弧度概念圆的周长是 2πr把它均分给 n 条边每一条边的长度、每一步转过的角度就全出来了。这篇文章把我从实际带项目过程中攒下来的经验完整梳理一遍从数学原理讲到可直接复用的自制积木再附上一份常见坑位清单给正在做 Scratch 绘图类项目的朋友做个参考。1. 为什么画圆必须走“多边形逼近”这条路1.1 Scratch 画笔机制的两个关键约束Scratch 舞台上的画笔扩展本质上是一个“落笔后随着角色移动留下轨迹”的纪录仪。抬笔状态下随便跑一点痕迹都不留一旦落笔角色每移动一步就在舞台上画一条起点到终点的线段。这就带来两个硬约束第一你没有办法让角色沿着一条真正的弧线连续移动。Scratch 只提供“移动多少步”和“面向多少度方向”以及“左右旋转多少度”这些动作叠加出来的路径永远是折线。换句话说不是我们不想直接画圆而是平台本身的画笔模型决定了所有曲线都必须用线段去逼近。第二画笔轨迹只和角色移动路径有关和角色的造型无关。你可以把角色隐藏起来画笔依然正常工作。很多时候我在演示项目时会先把角色隐藏掉只留画笔痕迹在舞台上视觉效果干净很多。这一点对后面的演示作品尤其重要因为画圆的过程中角色会在起点和终点之间反复转向露出角色造型容易干扰观察。理解了这两个约束就能明白为什么“用多边形逼近法画圆”不是一种妥协而是 Scratch 平台下唯一的通用方案。说它“通用”是因为无论是旋转法、坐标法还是数学函数法落到最终执行层画出来的都是多边形差别只在于这个多边形的边数够不够多、转折点算得准不准。1.2 正多边形为什么可以逼近圆把我的话换一种更“数学”的说法圆是极限意义下的正多边形。正三角形、正四边形、正五边形……每增加一条边形状就离圆近一点当边数趋近无穷大时这个图形就趋近于圆。实际做项目不需要无穷条边只要多到肉眼分不清“转折”就行了。在设计脚本之前建议先建立一个直觉认知假设我们要画一个半径 100 步的圆用正六边形来逼近每条边和相邻边之间的夹角是 120 度内角画出来一眼就能看出是六边形。改成正十二边形好一些但还是能看出棱角。到正三十六边形在 Scratch 舞台上已经接近圆形了。到正一百二十边形大部分人的肉眼很难看出它和真圆的区别。到三百六十边形除了舞台刷新带来的细微抖动视觉上就是正圆。这个“多少边够用”的问题直接对应着“精度”与“计算开销”的平衡。边数太少逼近误差明显边数太多每一条边的长度变得极小如果半径只有几十步单边长度可能不到 1 步角色的移动会出现明显的抖动感而且绘制时间变长。从实操角度看静态图形用 120 边左右最舒服动态演示用 36 到 60 边也够。这里有一张我整理的误差参照表能很直观看出边数对逼近精度的影响边数 n用弧长均分法时实际外接圆半径相对 r 的误差3约 20.9%6约 4.7%12约 1.15%30约 0.18%60约 0.046%120约 0.011%360约 0.001%这张表里的误差来源我先卖个关子下一节就会详细解释。你只要先记住一个结论当 n 超过 36 之后误差已经小到肉眼无法察觉当 n 到 120数据层面的精度完全可以满足绝大多数 Scratch 项目。2. 弧度概念才是“指定半径画圆”的钥匙2.1 从周长平均到弧度制为什么一圈是 2π很多教程讲画圆直接甩给你一个脚木移动 2×π×半径÷边数步旋转 360÷边数度。但如果你只是照抄遇到问题还是会卡住。我建议把背后的弧度概念搞明白因为它能回答一个特别实际的问题为什么半径越大每段边的长度也要跟着变大回到定义。弧度是用“弧长”和“半径”的比值来衡量角的大小的。想象你站在一个圆的圆心朝圆周方向走一段弧这段弧的长度除以圆的半径得到的数值就是这段弧对应的圆心角单位是弧度。一个整圆弧长等于周长 2πr除以半径 r结果就是 2π。所以“一整圈 2π 弧度 360 度”这个看似奇怪的等式本质上只是用不同尺子在量同一个角。这个关系直接给出画圆的核心公式。我要把一个半径为 r 的圆均匀切成 n 条边每条边近似等于一小段弧这一小段弧的长度就是整圆周长除以 n每段弧长 2πr ÷ n每个小弧对应的圆心角 2π ÷ n弧度 360 ÷ n度这也就是我最常用的“弧长均分法”的来源。你会发现半径 r 一旦确定每段边长就和 r 成正比圆心角则和半径无关只取决于边数 n。所以“指定圆心和半径”这件事本质上就是前面那条公式的两个输入参数。顺便说一句如果你想让圆弧概念在项目里继续发挥价值可以把这个思路推广到画任意圆弧。想画一个只占整圆三分之一的小圆弧就让角色移动的步数变成 2πr÷n×三分之一转过的总角度也对应缩小。这也是为什么不少项目里同一个自制积木既能画圆又能画仪表盘刻度。2.2 Scratch 里的“度”和数学里的“弧度”怎么换算这里必须讲一个极其容易翻车的细节Scratch 的旋转积木和三角运算积木默认单位都是“度”不是“弧度”。右转 90 度、面向 180 度方向这些大家都熟。而数学公式里sin、cos 这类函数在大多数文本编程语言里接收的是弧度。于是很多从别的语言转过来的同学会把一段现成的 Python 画圆代码直接搬进 Scratch结果画出来的多边形完全对不上。这个坑的根源就是单位制。Scratch 里 sin 和 cos 积木的输入框直接填“度”。想知道 sin(π/6)也就是 30 度的结果你需要在积木里填 sin(30)而不是 sin(π/6)。所以如果你在纸上推导出一个弧度制公式比如后面要讲的正弦精确法里的 sin(π/n)落地到 Scratch 时必须先把弧度换算成角度角度 弧度 × 180 ÷ π弧度 角度 × π ÷ 180一个 π 弧度等于 180 度这一点不用死记。每次我写这类脚本都会在变量区专门建一个常量“π”填 3.14159265然后在用到角度的积木里写上 180÷n 来代替 π÷n。因为 π÷n 弧度恰好就等于 180÷n 度。这个转换关系非常隐蔽但恰恰是标题里“弧度概念”在编程实操中最关键的一次落地。别小看这一步很多学生程序“翻车”就翻在这里。2.3 两种边长公式到底用哪个说到具体的边长公式网上流传着两种写法。一种是我前面提到的弧长均分法边长 2πr÷n简单直观。另一种是更精确的弦长公式边长 2r×sin(π÷n)。两者差别在哪里弧长均分法的思路是“把一小段弧拉直了用”实际画出来的弦会比弧短一点。这样的后果是如果你严格沿着一个半径 r 的圆来画最后多边形的顶点不会精确落在这个圆上而是稍微偏内一点点。边数越少这个偏差越大。精确法的思路是“直接按弦长来算”。正 n 边形的边长和它外接圆半径的几何关系是边长 2r×sin(π÷n)。这个公式在弧度制下写得很干净但放进 Scratch 时要转换成边长 2r×sin(180÷n)因为前面说过了Scratch 的 sin 积木吃的是度数。两张公式在实战中怎么取舍我自己一般这么处理方法边长公式适用场景弧长均分法2×π×r÷n教学演示、快速原型边数多时误差可忽略正弦精确法2×r×sin(180÷n)需要图形严格落在指定半径上尤其边数较少时如果 n 已经到 120两种方法画出来的图形肉眼完全一样选哪个都行。但如果你要画一个正十二边形来模拟圆或者做边数滑杆从 3 慢慢往上推的演示弧长均分法在边数少时会出现明显的外扩偏离。正弦精确法在边数为 3、4、6 时依然保证每个顶点都精确落在半径 r 的圆上只是这些顶点连起来还不像圆而已。我推荐的实操组合是教学场景先用弧长均分法建立直觉再做一次正弦精确法的对比实验让学生亲眼看到差别。这样比直接背公式有效得多。3. 完整实操用自制积木实现指定圆心和半径的画圆工具3.1 参数设计为什么需要四个参数“指定圆心和半径”这句需求翻译成程序语言其实就是四个变量圆心的横坐标 cx、纵坐标 cy、半径 r、边数 n。cx 和 cy 负责定位r 负责定大小n 负责定精度。你可能会问为什么圆心坐标要两个变量不能直接让角色走到某个地方画吗因为在真正的项目里你可能需要用同一个画圆积木在不同位置画出多个圆。比如画一个表盘几个同心圆、一圈刻度每个圆都有自己的圆心和半径。把 cx、cy、r 都做成参数这个画圆工具才能被反复调用而不需要改内部代码。Scratch 里实现参数最优雅的办法就是自制积木。在“自制积木”面板点“制作积木”名称填“画圆”然后加四个数字参数cx、cy、r、n。这样每次调用它只需要告诉它圆心在哪、半径多大、边数多少它就能独立完成任务不污染主程序的全局变量。这个习惯非常建议养成——哪怕是画一个圆也把它封装成一个独立模块后面调试起来会轻松很多。下面把完整的自制积木脚本用伪代码形式展示给你定义 画圆(cx, cy, r, n) 全部擦除 抬笔 移到 x: (cx r) y: (cy) 面向 90° 方向 落笔 重复 (n) 次: 移动 (2 × 3.14159265 × r ÷ n) 步 右转 (360 ÷ n) 度 抬笔看着很短但每一行都有讲究。第一步“全部擦除”可加可不加如果你希望这个积木每次调用都重新绘制就放在开头。它会把舞台上之前所有画笔痕迹清掉省的因为残留线条误判图形。第二步“抬笔”必须有。很多人画出来的圆总是多一条莫名其妙的直线多半就是因为上一条流程结束时笔还压在舞台上。干脆在每个画圆过程的开始都显式抬笔把画笔状态拉回安全位置。第三步“移到 x: (cx r) y: (cy)”这是把角色放到圆上最右侧的顶点。注意这里不是把角色移到圆心而是圆心右侧距离 r 的那个点。如果直接移到圆心再画第一笔就会从圆心画到圆上留下一条半径线那是典型错误。用计算积木组合出“cx r”这一步等价于在 Scratch 的“移到 x: y:”积木里嵌入一个“加法”积木脚本会自动计算。第四步“面向 90° 方向”。Scratch 里 90 度方向是正右方。角色面向正右落笔后往前走第一条边就是水平的弦。配合“右转 360÷n 度”整个多边形会顺时针方向一笔一笔围出来。第五步“落笔”从此开始记录轨迹。第六步循环里“移动 (2×π×r÷n) 步”这是弧长均分法的边长。注意我在这里把 π 写成了 3.14159265不要偷懒只写 3.14。舞台坐标的数值运算精度有限用 3.14 在边数多时累积误差会变大圆的终点和起点可能会对不齐。第七步“右转 360÷n 度”这是正多边形的外角。每次画完一条边就转向一次循环重复 n 次后角色一共转了 360 度正好回到起始方向图形闭合。3.2 起点的选定和转向方向的细节起点选在最右侧而不是正上方这个选择是有讲究的。因为 Scratch 里“面向 90° 方向”是正右角色从右侧开始第一笔水平向右画完一条边后右转 n 分之一圈继续画第二条。整个过程非常自然不需要额外处理角色的初始旋转角。如果你想让图形从正上方开始只需要把起点坐标改成 (cx, cy r)面向 0° 方向第一笔向上画其他逻辑完全一样。还有一个细节整体画完以后角色会回到起点位置方向也归位到 90°但不是必须的。因为每一次调用画圆积木的开头都会重新设置起点和朝向所以留在原地不会影响下一次调用。真正需要注意的反而是循环结束后的“抬笔”。如果循环结束后没有抬笔下一次调用画圆积木时第一步抬笔之前角色还压着笔从当前位置移到新起点的过程会莫名其妙多画一条线。因此把抬笔放在循环结束之后是一次防御性编程强烈建议保留。3.3 核心加速技巧运行时不刷新屏幕很多人第一次用这个脚本画 360 边的圆会看到角色在舞台上慢慢转圈画了大半天才完成。原因是 Scratch 默认每一帧都会刷新舞台显示角色每移动一步、旋转一次舞台都要重新渲染。画一个 120 边的圆就意味着舞台要刷新 120 次自然很慢。解决方法藏在自制积木的细节里在自制积木编辑区右上角右键点击你已经建好的“画圆”积木定义块菜单里有一项“运行时不刷新屏幕”勾选它。这样在执行这个自制积木期间Scratch 会暂停舞台刷新所有移动和旋转动作都在后台算完直到积木运行结束才把最终结果一次性显示出来。效果非常夸张120 边的圆原本要转半天勾选后几乎瞬间画完。这个技巧是 Scratch 绘图类项目里性价比最高的优化。不过要注意勾选后用户看不到绘制过程动画。如果你是做教学演示想让学生观察多边形是怎么一步步逼近圆的就不要勾选反而应该把角色显示出来、放慢边数让动画慢慢转如果你只是要最终结果加快处理速度那就果断勾选。3.4 让画圆工具支持“任意圆弧”既然已经走进弧度概念了再往前迈一步就会特别自然如果我只想画一段圆弧而不是完整圆怎么改回看核心公式。整圆对应的圆心角是 360 度分成 n 段。如果我只想画一个圆心角为 α 的圆弧可以把总角度设成 α同时把总弧长从 2πr 改成 2πr×α÷360。更优雅的做法是给自制积木再加一个参数“总角度”例如画一个半圆就传 180。循环次数可以按总角度除以每步转角来算比如每步转 3 度画 60 次就是 180 度圆弧。这个能力在画仪表盘、花瓣图案、雷达扫描效果时特别有用是“画圆”这个基础能力的直接延展。4. 现场改造做一个可调节精度和参数的多边形画圆演示器4.1 边数滑杆动态观察多边形逼近圆理论说一百遍不如亲手拖一次滑杆。在 Scratch 里新建一个变量 n右键变量把它显示为滑杆然后设置最小值为 3、最大值为 360。主程序写一个简单的循环拖动滑杆调用一次画圆积木画完后等待一小段时间。这样你就能实时看到同一个半径下正三角形、正六边形、正十二边形……逐渐“演化”成圆的过程。我做这个演示时最喜欢让学生从 n3 开始慢慢拖。三边形时很明显是三根直线围成的三角形拖到 6是个六边形但已经开始有点“圆滑”的雏形到 12棱角比较柔和但依然可见到 30形状已经接近圆再到 120几乎没有人能看出转折点。这个过程本身就是对“多边形逼近法”这个标题最好的诠释比任何语言都直接。脚本实现起来非常简单当绿旗被点击: 重复执行: 全部擦除 画圆(cx, cy, r, n) 等待 0.2 秒这里的 cx、cy、r 可以先用固定值。注意在重复执行里调用画圆积木时别忘了勾选不刷新屏幕否则每一帧都要重画一遍几百条边拖滑杆会非常卡。如果勾选了不刷新屏幕重绘几乎是瞬时的滑杆体验非常流畅。4.2 圆心和半径滑杆让“指定圆心和半径”变成可视参数如果你想完全对应标题里的“指定圆心和半径”不妨再新建三个滑杆变量cx范围 -240 到 240、cy范围 -180 到 180、r范围 10 到 200分别控制圆心的横坐标、纵坐标和半径。Scratch 舞台的坐标系里x 范围约 -240 到 240y 范围约 -180 到 180这些范围可以灵活调整。只要 cx、cy、r 都能用滑杆控制“指定圆心和半径画圆”这件事就从一句口号变成了真正可交互的工具。我实际测试下来当 r 设成 200 且 cx 也偏到边缘时圆很容易超出舞台边界超出的部分会被截断看起来像缺了口。这是正常现象但如果你要做演示最好加一个简单的边界提示。比如判断如果 cxr 大于 240 或 cx-r 小于 -240就让角色说一句“圆超出舞台范围”或者弹一个提示。在高阶一点的项目里还可以自动把 r 缩减到安全值。这个边界检查虽然只有几行判断积木但能避免学生在拖滑杆时突然看到半个圆而误以为程序出错了。4.3 画多个圆验证“同一个圆心”验证“指定圆心和半径”是否真正生效最简单的方式是画一组同心圆。固定 cx 和 cy先用 r60 画一个红色的圆再用 r120 画一个蓝色圆再用 r180 画一个绿色圆。如果三个圆的圆心坐标都正确它们会完美共享一个中心间距均匀。如果圆心算错了你会发现三个圆的相对位置偏移一眼就能看出来。画不同颜色的圆很简单在调用画圆积木之前设置画笔颜色和粗细即可。比如将画笔的颜色设为 (0) (0) (255) 将笔的粗细设为 (3) 画圆(cx, cy, 60, 120)注意 Scratch 里“将画笔的颜色设为”通常需要你输入 RGB 三个通道值或者直接选色板。建议在画每组圆之前先设置一次颜色画完后再把颜色改回来避免不同图形之间互相覆盖看不清。这个多圆验证技巧是我在课堂项目里检查学生圆心坐标是否理解正确的标准方法。4.4 从小工具到项目怎样扩展成可应用的作品不要小看这个画圆演示器它稍微改一改就能变成实际可用的作品。比如把画笔颜色设置成不同分段配合圆心角参数可以做圆形仪表盘用多个不同半径的圆叠加可以做雷达扫描的底座甚至在每个顶点处落一笔就能生成正多边形星形。我在一次项目中就用这个自制积木给同学做了一张渐变圆环的桌面壁纸生成器原理不过是循环调用画圆积木每次半径增减、颜色变化。当你把画圆这件基础能力封装成可靠的工具积木后后续所有创意都变得非常顺畅。5. 常见问题与排查技巧实录5.1 画出来的图形不闭合或首尾接不上这是一个出现频率极高的问题。先说结论最常见的原因是循环次数和边长公式的乘积不等于圆周长。如果你用弧长均分法循环次数 n 和单边长度 2πr÷n 相乘总长刚好等于圆周长理论上是闭合的。但如果循环次数写成 360很多新手容易觉得“转 360 度就是一遍所以循环 360 次”边长却用的是 2πr÷n这就会要么走多了、要么走少了最终图形不闭合。还有一种情况是单边长度过小。当半径 r 只有 50 步、边数 n 拉到 360 时单边长度约 0.87 步。Scratch 角色移动底层虽然支持小数坐标但在小步长下移动精度和渲染表现都会下降常见症状就是边与边之间有细小的缝隙看起来像没闭合。解决办法是降低边数到 120 左右或者增大半径。如果必须用 360 边且半径很小可以考虑把整张图放大后再缩小但那就比较绕了。5.2 为什么圆的位置总是不对多了一条半径线这个问题几乎一定出在起笔前没有抬笔或者起点坐标写成了圆心坐标。我之前见过一个学生他写“移到 x:(cx) y:(cy)”然后在“面向 90°”之后直接落笔画圆。结果笔画从圆心向右画了一条半径到圆上然后再开始围圈最后的成品是一个圆加一条直线。这种错误特别迷惑因为圆本身看起来没问题只是多了一条“尾巴”。排查方法也很简单检查落笔前最后一次移动的目标点必须是 (cxr, cy)而不应该是 (cx, cy)同时确认从上一个状态到起点之间笔一直处于抬起状态。更稳的做法是在画圆积木开头先把笔抬起来、移动到起点、面向正确方向然后一个落笔把这个顺序固化下来。这样即使前一个程序状态很混乱画圆积木也能强制恢复到一个干净的初始状态。5.3 圆的大小比指定半径偏大或者偏小如果你用的是弧长均分法边数又较少你会看到实际图形比预期半径稍微大一点。原因就是前面讲过的那张误差表边长是弧长拉直的结果弦比弧短所以为了凑满同样的中心角多边形的外接圆半径会略微变大。n6 时偏大 4.7%n12 时偏大 1.15%肉眼能看出来但不会太明显n30 以下建议用正弦精确法来保证半径准确。如果你用的是正弦精确法但实际画出来的半径仍然不对最常见的坑是 sin 积木的角度单位没换算。请注意Scratch 的 sin 积木吃的是“度”所以公式里的 sin(π÷n) 要写成 sin(180÷n)。我见过有人直接填 sin(π÷n)Scratch 会把它当 sin(180÷n) 吗不会它只是把 π÷n 这个数值当成角度去算结果完全错乱画出来的多边形边长会严重偏小所有顶点缩成一团。这个问题一旦出现先检查角度单位十有八九就解决了。5.4 绘制速度慢得让人着急绘制慢前面说过的“运行时不刷新屏幕”是首选解法。如果已经勾选还是不理想第二优先是减少边数。静态圆形 120 边完全够动态演示 60 边已经接近视觉效果上限。第三检查你是否在循环内部插入了多余的动作比如每次循环都改变颜色、改变粗细、播放音效这些都会拖慢整体速度尤其是刷新屏幕被关闭后所有计算都要等积木结束才渲染中间步骤白白占据 CPU。真正高效的做法是画图期间只做移动和旋转其他操作全部放到画图循环之外。一个附加技巧图形画完后立刻把角色隐藏可以减少舞台重绘负担尤其在多圆嵌套、需要频繁重绘的画布项目中效果明显。5.5 画笔颜色和粗细偶尔失灵残影怎么处理画笔扩展偶尔会出现颜色设置不生效的情况原因是你要么在抬笔状态下设置颜色要么上一个图形的颜色还没“用完”就被新图形覆盖了一部分。我的习惯是每次画新图形之前先设置颜色再设置粗细然后抬笔到位、落笔绘制。顺序固定可以避免很多莫名其妙的画笔状态混乱。残影问题大概率不是画笔出了 bug而是上一轮图形没有“全部擦除”。如果项目里希望并存多个图形就不该在每次画圆时调用“全部擦除”。可以把“全部擦除”单独放到主程序的某个初始化按键里比如按空格键才清屏而画圆积木内部不负责清屏。这样画多个圆的时候不会互相擦除需要重画时也就一键清空。5.6 一个容易忽略的方向细节左转和右转的选择正常情况下不管是左转还是右转只要每步都按同一个方向转画出来的多边形都是一样的只是绘制方向相反。但如果你想跟其他角色的路径配合比如让一个小球沿着圆轨迹移动那么转向方向就必须和移动方向一致。在 Scratch 里“右转”是顺时针方向在小舞台坐标系里是从屏幕上方开始向右转。如果你希望角色逆时针沿圆运动就用“左转 360÷n 度”。有一次我在做圆周运动演示时圆画好了小球移动方向却和预期相反原因就是调用了同一个画圆积木而画圆积木里用的是右转小球脚本里却用了左转。把旋转方向统一问题立刻解决。这个细节虽然不致命但在项目整合阶段会花掉不少排查时间提前统一约定会省事很多。最后再说几句实操体会这套“多边形逼近法 弧度概念”的组合我已经在好几个项目里反复使用。最开始我也跳过原理直接用一个固定脚木画圆结果一旦要换圆心、换半径、换边数就不得不重新翻开脚本去调一堆变量。后来把画圆封装成带参数的自制积木又把弧度和角度换算关系理清之后整个效率提升了一个量级。如果你只是偶尔画一次圆用文章里的弧长均分法脚本就够了。但如果你想真正搞懂这个圆是怎么来的我强烈建议你亲手拖一遍边数滑杆把 n 从 3 慢慢拖到 360同时把半径设成一个大一些的整数比如 120。看着六边形长成十二边形、二十四边形最后变成流畅的圆那种“原来圆是这样逼近出来”的感觉比背一百遍公式都管用。再往后任何需要画圆弧、画仪表盘、画圆环的项目你都会比别人多一层底气圆的每一段边到底从哪里来心里有数代码自然就写不歪。