简介面向计算机图形学课程设计与项目实践的完整工程包源自南京大学计算机图形学大作业实现了一个可运行的图形学系统功能覆盖画布初始化/重置、保存画布、画笔颜色设置以及线段、多边形、椭圆、曲线的绘制和图元平移、旋转、缩放、线段裁剪等核心算法。系统同时提供基于文件输入的CLI接口和基于鼠标事件的GUI交互界面支持算法对照与可视化操作便于理解图形学原理和工程实现。资源共44个文件以Python源码、pyc编译文件、GIF操作演示、图片、XML配置及docx报告和README说明为主压缩包2.21MB内容组织清晰。已有320人学习下载适合计算机相关专业学生、教师或开发者用于课程设计、毕业设计或图形学入门进阶。下载后可获得完整源码、配套文档、操作演示与课程设计报告代码经运行测试且作者说明答辩评审平均分达96分参考价值较高。1. 图形学系统拆包一个能跑能答辩的完整实现这套课程设计把计算机图形学教材里散落的算法收拢成一个真正能运行的图形学系统从画布初始化、画笔颜色设置到线段、多边形、椭圆和曲线的光栅化绘制再到图元平移、旋转、缩放和线段裁剪并且同时提供 CLI 文件输入和 GUI 鼠标事件两套操作入口。源代码里既有面向批处理验证的 main_cli.py 和 input.txt 示例又有面向交互演示的 main.py配合 README 和实验报告相当于把原理、实现、实验数据一次性配齐。适合正在做课设、需要参考完整图形管线代码的人也适合想复习光栅化算法和齐次变换的从业者——很多 GPU 层面的概念在这个二维代码里反而能看得更直接。这类资源最容易踩的坑不是算法难度而是拿到手跑不起来。2. 光栅化底层线段、圆与多边形填充的像素级实现图形学系统之所以叫“系统”不是因为有一堆命令挂在界面上而是从用户输入到屏幕像素之间有一条完整的处理链。这条链的起点就是光栅化把几何定义转换成画布上的离散像素点。资源里的 line.py、circle.py、polygon.py 三个模块分别承担这条链上最基础的三种图元读懂它们后面曲线的 Bézier 实现和变换矩阵才有支点。2.1 用 Bresenham 画线而不是 DDA 的取舍画线算法最常用的两个候选是 DDA 和 Bresenham。DDA 的思路是沿着主位移方向每次步进一个单位另一个方向按斜率累加浮点增量。这种方式代码直观但每画一个像素就要做一次浮点加法和一次取整运算在长线段上误差会累积端点也容易偏半个像素。这套系统里 line.py 采用的是整数化的 Bresenham 算法核心是维护一个误差项err每次根据误差值的符号决定是否在非主位移方向上前进一步。def draw_line(x0, y0, x1, y1, color): dx abs(x1 - x0) dy -abs(y1 - y0) sx 1 if x0 x1 else -1 sy 1 if y0 y1 else -1 err dx dy while True: set_pixel(x0, y0, color) if x0 x1 and y0 y1: break e2 2 * err if e2 dy: err dy x0 sx if e2 dx: err dx y0 sydx取绝对值后为正dy取负值这样误差项的正负能同时反映两个方向上谁欠得更多。sx和sy是步进方向由端点的相对位置决定保证算法能处理任意方向的线段。e2 2 * err是 Bresenham 的一个经典优化不直接比较err与dx、dy的浮点比值而是放大两倍做整数比较避免除法开销。这里如果e2 dy成立说明误差累积到了需要在 x 方向步进的程度e2 dx则对应 y 方向。实际操作里有一个容易忽略的边界当线段恰好是水平或垂直时斜率不存在但这个实现天然兼容两个 if 中只有一个会持续命中。算法计算开销适用范围DDA每像素一次浮点乘加教学演示不追求性能Bresenham每像素几次整数比较任意斜率的线段嵌入式友好Wu 反走样每像素多次浮点运算需要抗锯齿的高质量渲染这套系统选择 Bresenham 作为默认画线方案是合理的CLI 模式下要快速处理 input.txt 里成百上千条指令GUI 模式下鼠标拖动会反复触发重绘整数运算能明显降低延迟。反走样没有做因为课程设计的评分点通常在算法正确性和交互完整性上而非画质。2.2 中点圆算法与逐点填充多边形的判定circle.py 里绘制椭圆时一种常见做法是分象限画弧段用对称性减少重复计算。中点圆算法的基本思想是维护一个决策参数d每次在水平向右和右下两个候选像素中选距离真实圆弧更近的那个def draw_ellipse(cx, cy, rx, ry, color): x, y 0, ry d ry * ry - rx * rx * ry rx * rx / 4 while rx * rx * y ry * ry * x: set_pixel(cx x, cy y, color) set_pixel(cx - x, cy y, color) set_pixel(cx x, cy - y, color) set_pixel(cx - x, cy - y, color) if d 0: d 2 * ry * ry * x 3 * ry * ry else: d 2 * ry * ry * x - 2 * rx * rx * y 2 * ry * ry 3 * ry * ry y - 1 x 1 # 第二区域对称绘制省略重复代码这里cx、cy是圆心坐标rx、ry是长短半轴。决策参数d每次迭代都按当前(x, y)的位置更新不再需要计算平方根或三角函数。set_pixel同时写到四个对称点把一个象限的计算结果扩展到整个椭圆。由于椭圆有两个轴当斜率绝对值接近 1 时决策表达式要切换到另一套递推式这是代码里容易出 bug 的地方——如果只画半个椭圆就停止多半是这里漏了分支。polygon.py 的填充核心不是逐段画边而是要判断一个像素点是否落在多边形内部。资源里采用射线法从目标点向右发一条水平射线统计与多边形边的交点个数奇数次落在内部def point_in_polygon(px, py, points): inside False j len(points) - 1 for i in range(len(points)): xi, yi points[i] xj, yj points[j] if (yi py) ! (yj py) and px (xj - xi) * (py - yi) / (yj - yi) xi: inside not inside j i return insidepoints是多边形顶点序列j始终指向i的前一个顶点构成一条封闭边。第一个判断条件要求边的两个端点必须分布在射线两侧第二个条件用相似三角形算出交点横坐标判断目标点是否在交点左侧。这个实现应对凹多边形同样成立因为奇偶规则不依赖顶点的凹凸性。实际绘制填充区域时只需要先扫出多边形的包围盒遍历包围盒内每个像素并调用point_in_polygon命中则着色。提示如果多边形顶点数很大纯逐点判断会变慢。实践里可以先把顶点按 y 坐标做桶排序用扫描线算法逐行维护活跃边表但课程设计场景下逐点判断的代码可读性更好也更容易在报告里解释原理。2.3 绘制顺序与颜色状态对画布的影响这三点在界面操作里还会有体现新建图元时调色、旧图元被覆盖、重绘时资源刷新。也就是说绘制顺序不是把像素画上就结束了而是整个图形系统的状态管理问题。资源里的 base.py 显然承担了画布状态的维护当前画笔颜色、画布尺寸、已绘制的图元列表。CLI 模式下每条指令执行后画布状态必须立刻反映到输出文件里GUI 模式下每次鼠标拖拽结束也要把图元追加进列表并触发重绘。如果一个线段在平移后没重绘其他图元就会出现背景残留这类问题排查起来往往比算法本身更耗时间。3. 曲线与齐次变换Bézier、旋转缩放和平移裁剪的实现路径图元画完只是静态内容图形学系统的价值在于“能编辑”。curve.py 负责参数曲线生成base.py 或独立的变换模块负责几何变换和裁剪。它们共享同一个坐标系但处理逻辑完全不同。3.1 三次 Bézier 的参数形式与 de Casteljau 求值curve.py 里的曲线绘制大概率是直接基于三次 Bézier 公式计算的四个控制点P0到P3定义一条曲线def bezier_point(t, p0, p1, p2, p3): mt 1.0 - t x mt ** 3 * p0[0] 3 * mt ** 2 * t * p1[0] 3 * mt * t ** 2 * p2[0] t ** 3 * p3[0] y mt ** 3 * p0[1] 3 * mt ** 2 * t * p1[1] 3 * mt * t ** 2 * p2[1] t ** 3 * p3[1] return x, y参数t从 0 连续变化到 1每个t值对应曲线上一个点然后把相邻点用线段连起来。步长决定了曲线的平滑度步长太大会出现折线感太小则计算量大增。常见做法是固定采样 100 到 200 次既保证视觉光滑又不会拖慢交互响应。de Casteljau 算法提供了另一种求值方式把四个控制点按比例t两两线性插值得到三个新点再两两插值得到两个点最后再插值一次得到曲线上的点。这个算法的好处是数值稳定性更好不会像伯恩斯坦多项式那样在t接近两端时出现高次幂的精度损失而且代码逻辑可以反复递归到任意阶数的曲线。资源里的 curve1.gif 和 curve2.gif 展示了不同控制点布局下的曲线形态如果报告里需要对比图可以直接用这两个 gif。3.2 用 3x3 齐次矩阵统一平移、旋转与缩放平移如果不是用矩阵而是直接对坐标分量做加减那“旋转后再平移”和“平移后再旋转”的效果就得写两套代码。这套系统里应该采用了齐次坐标把二维点(x, y)扩展成(x, y, 1)这样平移、旋转、缩放都能统一成 3x3 矩阵乘法的形式def build_transform(tx, ty, angle_deg, sx, sy): rad math.radians(angle_deg) sin_a, cos_a math.sin(rad), math.cos(rad) # 先缩放再旋转最后平移 m [ [sx * cos_a, -sin_a, tx], [sin_a, sy * cos_a, ty], [0, 0, 1] ] return m def apply_point(m, x, y): px m[0][0] * x m[0][1] * y m[0][2] py m[1][0] * x m[1][1] * y m[1][2] return px, pytx、ty是平移量angle_deg是绕原点旋转的角度sx、sy是 x、y 方向的缩放因子。矩阵连乘时顺序很关键上面这个矩阵等价于“先缩放、再旋转、最后平移”因为列向量的点坐标会先被最右边的矩阵作用。如果想绕任意点旋转需要先平移到原点、旋转、再平移回去三段矩阵连乘否则旋转中心会跑偏。缩放因子取负数时会产生镜像效果如果报告里需要展示翻转可以把这个作为扩展功能写上。3.3 线段裁剪从 Cohen-Sutherland 到 Liang-Barsky裁剪是这套系统里比较“硬核”的部分clip.gif 对应的就是裁剪演示。最常见的实现是 Cohen-Sutherland 算法把窗口四边编码成上下左右四个 bit线段端点的编码相交为非零则完全在窗口外直接丢弃端点编码相或为非零则需要求交点INSIDE, LEFT, RIGHT, BOTTOM, TOP 0, 1, 2, 4, 8 def compute_outcode(x, y, xmin, ymin, xmax, ymax): code INSIDE if x xmin: code | LEFT elif x xmax: code | RIGHT if y ymin: code | BOTTOM elif y ymax: code | TOP return code def cohen_sutherland(x0, y0, x1, y1, xmin, ymin, xmax, ymax): outcode0 compute_outcode(x0, y0, xmin, ymin, xmax, ymax) outcode1 compute_outcode(x1, y1, xmin, ymin, xmax, ymax) while True: if not (outcode0 | outcode1): return x0, y0, x1, y1 if outcode0 outcode1: return None outcode outcode0 or outcode1 if outcode TOP: x x0 (x1 - x0) * (ymax - y0) / (y1 - y0) y ymax elif outcode BOTTOM: x x0 (x1 - x0) * (ymin - y0) / (y1 - y0) y ymin elif outcode RIGHT: y y0 (y1 - y0) * (xmax - x0) / (x1 - x0) x xmax elif outcode LEFT: y y0 (y1 - y0) * (xmin - x0) / (x1 - x0) x xmin if outcode outcode0: x0, y0 x, y outcode0 compute_outcode(x0, y0, xmin, ymin, xmax, ymax) else: x1, y1 x, y outcode1 compute_outcode(x1, y1, xmin, ymin, xmax, ymax)outcode0 | outcode1全零表示线段两端都在窗口内整体保留outcode0 outcode1非零表示两个端点都在窗口同一外侧整体舍弃。中间循环只处理一个端点用相似三角形求交点后替换该端点并重新编码。这个算法最多循环 4 次就能收敛。Liang-Barsky 参数化裁剪线段效率更高、代码更短但理解门槛稍高如果报告里只写一种算法Cohen-Sutherland 更好讲清楚。注意求交点时如果线段恰好与窗口边平行分母y1 - y0或x1 - x0可能为 0要先判断斜率是否为零否则会抛出 ZeroDivisionError。这套系统在 CLI 指令里如果输入了边界退化线段应该捕获这个异常并跳过该指令。4. CLI 文件输入与 GUI 鼠标事件双模式接口的分工和组合资源文件列表里同时出现 main_cli.py 和 main.py这不是冗余而是两套完全互补的交互接口。CLI 模式的价值在于可自动化验证把 input.txt 里的指令批量执行生成一张确定的画布图片方便对比算法正确性。GUI 模式的价值在于演示鼠标拖拽生成图元交互反馈直观。理解两者如何共享 base.py 里的画布对象比重复读实现代码更有收获。4.1 input.txt 指令格式与解析流程CLI 入口的逻辑不复杂读取指令文件按行解析把每条指令映射到对应模块的函数。这套系统里的指令格式可以从资源文件名和课程设计习惯推测出来常见做法是“操作名 空格 参数”例如reset 800 600 color #FF0000 line 100 100 300 200 polygon 100 100 200 100 150 200 ellipse 400 300 80 50 curve 80 400 160 250 240 400 320 250 translate 50 30 rotate 45 200 200 scale 1.5 1.5 200 200 save output.pngreset的第一个参数是画布宽度、第二个是高度color接受十六进制颜色值line、polygon、ellipse传入坐标和尺寸translate传平移量rotate和scale除了角度或缩放因子外还应该传旋转或缩放中心坐标否则交互不够灵活。save把当前画布内容导出为图片文件。解析代码的核心是一个循环加字典映射def run_cli(cmd_file): commands { reset: reset_canvas, color: set_brush_color, line: draw_line_cmd, polygon: draw_polygon_cmd, ellipse: draw_ellipse_cmd, curve: draw_curve_cmd, translate: translate_cmd, rotate: rotate_cmd, scale: scale_cmd, save: save_canvas, } for raw in open(cmd_file, r, encodingutf-8): tokens raw.strip().split() if not tokens: continue op tokens[0].lower() args parse_args(tokens[1:]) if op in commands: commands[op](*args) else: print(funknown command: {op})parse_args会根据指令类型把字符串参数转成整数或浮点数。这里最大的坑在颜色color #FF0000里的#会让split()之后的#FF0000变成单个 token但 Python 字符串转整数时需要int(#FF0000, 16)或者先去掉#再用int(..., 16)处理不好会直接抛异常。再者CLI 模式必须同步打印每一次指令的执行结果比如每条指令后的图元数量或画布占用信息便于在报告里贴运行日志。4.2 tkinter 鼠标事件驱动的交互绘图GUI 模式用的是 Python 标准库 tkinter 的 Canvas 组件事件绑定集中在三个鼠标事件上canvas.bind(Button-1, self.on_press) canvas.bind(B1-Motion, self.on_drag) canvas.bind(ButtonRelease-1, self.on_release) def on_press(self, event): self.start_x, self.start_y event.x, event.y self.temp_item None def on_drag(self, event): if self.temp_item: canvas.delete(self.temp_item) self.temp_item canvas.create_line( self.start_x, self.start_y, event.x, event.y, fillself.current_color, tagspreview ) def on_release(self, event): if self.current_mode line: draw_line(self.start_x, self.start_y, event.x, event.y, self.current_color) elif self.current_mode polygon: self.polygon_points.append((event.x, event.y)) self.temp_item NoneButton-1是鼠标左键按下B1-Motion是按住左键拖动ButtonRelease-1是松开。按下时记录起点拖动时动态创建临时图元做预览松开后才真正调用底层的光栅化函数。这里没有监听普通的Motion事件否则鼠标悬停就会触发大量回调画布会被无意义的预览图元刷爆。tagspreview的值很重要后续可以用canvas.delete(preview)批量清理临时对象而不影响已确定的图元。工具按钮切换的是self.current_mode这个变量的取值决定了释放鼠标时调用哪个图元函数。如果需要连续画线每次释放后应该用canvas.create_line把几何信息持久化到图元列表而不是只画到画布上否则下一次重绘时所有已经完成的绘制会消失。交互模式触发时机预期结果画线段按下、拖动、释放释放时生成最终线段画多边形逐点按下每次点击加入一个顶点双击闭合画椭圆拖动起始点为外接矩形一角释放点为其对角变换图元选中图元后拖动实时平移或绕选中点旋转缩放4.3 模式切换、颜色设置与画布重置的状态管理画布状态不是零散的全局变量而是收敛在一个画布对象里图元列表、当前画笔颜色、当前选择模式、已保存的绘制历史。颜色选择控件要么是预先定义好的色板要么提供一个颜色输入框把十六进制字符串转成 tkinter 可识别的颜色值。重置画布时除了canvas.delete(all)还要把图元列表清空、变换矩阵恢复为单位矩阵否则下一个输入文件会带着上一次的变换残留。状态管理里最容易出的问题在“重置”不是“清空”重置画布还应该重新生成基底网格或背景色重置画笔颜色到默认黑色重置当前选中的图元为 None。这套系统里 reset.gif 应该就是演示这个完整的重置流程如果只调用了delete(all)而没重置颜色那新的绘制会延续之前的颜色。5. 答辩前验证与四个实测踩坑点项目代码能跑通是一回事答辩时被问倒是另一回事。这里给出四个实测中容易踩的坑和对应的验证思路比临时背概念更有用。坑一缓存文件与 Python 版本错位。资源里出现line.cpython-37.pyc、curve.cpython-37.pyc等编译缓存文件说明生成环境是 Python 3.7。如果本机默认是 Python 3.10 及以上解释器不会加载旧的.pyc文件而是直接重新编译源码这本身没问题。但项目中自带的 venv 目录带有pyvenv.cfg里面的路径指向作者的绝对路径直接复用大概率找不到解释器。正确做法是删除 venv 和__pycache__目录在 Python 3.7 环境下重新创建虚拟环境再安装依赖而不是试图修复.pyc。坑二屏幕坐标系与数学坐标系的方向冲突。tkinter Canvas 的原点在左上角、y 轴向下而数学中常用的坐标系 y 轴向上。旋转正方向因此是反的屏幕上看起来是顺时针旋转数学公式里是逆时针。如果你用缩放、旋转的 gif 做演示要提前统一约定——建议在报告里写明“所有旋转角度基于屏幕坐标系”。否则答辩评委用一个角度验证结果方向相反解释成本很高。坑三变换顺序不同步导致图元漂移。第 3 章里的矩阵是先缩放、再旋转、最后平移。如果你的rotate指令传入的是图元绕自身中心旋转那必须在调用旋转前把图元坐标平移到原点旋转后再平移回去。一个可复现的验证步骤画一个中心在(200, 200)的矩形执行rotate 90 200 200期望结果是矩形只绕中心旋转、中心点位置不变。如果中心点跑到了别处逐行检查矩阵相乘的顺序。坑四保存画布的格式问题。tkinter Canvas 没有直接保存 PNG 的接口常见做法是用 PostScript 导出再转换canvas.postscript(fileoutput.eps, colormodecolor) ps2png output.eps output.png如果你的环境里没有 Ghostscriptps2png会直接报错。更稳妥的替代方案是用 PIL 的ImageGrab.grab()截取 Canvas 区域但截屏方式依赖窗口置顶和 DPI 设置批量跑 CLI 用例时不稳定。最后提醒一点save_canvas的参数里写明输出路径避免循环跑指令时把上一次的图片覆盖掉留一份expected.png做对照。本文还有配套的精品资源点击获取