Godot 3D调试绘图插件开发：从原理到实战，提升游戏开发效率-开发者社区

1. 项目概述：为什么我们需要一个3D调试绘图插件？

在Godot引擎里做3D开发，尤其是涉及到物理、AI寻路、自定义碰撞检测或者复杂算法时，最头疼的问题之一就是“看不见”。你写了一段代码，计算出一个角色的移动路径，或者生成了一个复杂的碰撞体形状，又或者是在调试一个自定义的物理模拟。代码逻辑看起来没问题，但角色就是卡在墙角，或者路径莫名其妙地绕了个大圈。这时候，你只能靠打印一堆坐标到控制台，然后在脑海里艰难地进行3D空间想象，效率极低，而且极易出错。

Godot引擎自带的调试可视化工具，比如导航网格（Navigation Mesh）的显示，确实很有用。但它的功能是固定的、有限的，并且通常只在编辑器模式下启用。一旦项目运行起来，或者你需要可视化一些引擎没有内置的、属于你自己游戏逻辑的数据时，就束手无策了。比如，你想实时看到角色AI的“感知范围”（一个球体），敌人巡逻的“路径点”（一系列线段和点），或者一个复杂技能的作用区域（一个自定义的多边形）。这些需求，原生的调试工具无法满足。

这就是“Godot 3D调试绘图插件”诞生的核心原因。它不是一个游戏功能插件，而是一个开发工具。它的目标是在游戏运行时，以高性能的方式，将你代码中抽象的数学数据（点、线、面、体）直接绘制在3D场景中，让你能“看见”你的逻辑。这就像给程序员装上了一双“透视眼”，能直接观察到向量、矩阵、边界框、射线检测结果等一切不可见元素在3D世界中的实际形态。

一个优秀的调试绘图插件，应该具备几个核心特性：

高性能：调试绘图通常是高频操作（每帧都可能绘制），绝不能成为性能瓶颈。它需要绕过复杂的场景节点系统，直接与渲染服务器（RenderingServer）对话。
即时性：绘制的图形生命周期要灵活，可以是持续一帧的临时标记，也可以是持续数秒的持久显示。
易用性：接口必须简洁直观，一两行代码就能画出一个立方体或一条射线，让开发者专注于逻辑本身，而不是绘图细节。
丰富性：支持基础几何图元（点、线、三角形、立方体、球体、箭头等），并能方便地设置颜色、线宽、持续时间等属性。

接下来，我将从一个资深Godot开发者的角度，详细拆解如何从零构建这样一个插件，并分享在实际项目中应用它的实战技巧与避坑经验。

2. 核心设计思路：绕过SceneTree，直连RenderingServer

要理解如何实现高性能的调试绘图，首先要明白Godot的渲染架构。Godot的渲染分为几个层次，从高到低大致是：场景节点（Node） -> 视觉服务器（VisualServer，在Godot 4中已整合为RenderingServer的一部分概念） -> 渲染设备（RenderingDevice）。SceneTree管理节点逻辑和层级关系，而RenderingServer则负责最终将几何体提交给GPU。

如果我们通过创建MeshInstance3D节点来画一个调试立方体，会发生什么？每帧我们都需要：创建节点、设置网格资源、添加到场景树、等待场景树处理、最后由RenderingServer渲染。这个过程中包含了大量的内存分配、引用计数、节点信号、属性检查等开销。画几十个这样的立方体，帧率就可能显著下降。

因此，高性能调试绘图的核心思想是：绕过整个SceneTree和节点系统，直接使用RenderingServer（或其前身VisualServer的接口）提供的immediate模式或custom绘制接口。在Godot 4中，更现代的做法是使用RenderingServer的canvas_item_add系列方法（针对2D）或mesh_create配合instance_set_base（针对3D），但对于动态、瞬时的调试图形，我们通常采用一种更轻量级的模式：在_process或_physics_process中，直接向RenderingServer提交绘图指令。

Godot 4 提供了ImmediateMesh类，它是对这种“即时模式”绘图的封装。但即使是ImmediateMesh，如果每帧都创建新的MeshInstance节点，开销依然不小。更优的方案是：创建一个常驻的、单例的调试绘制管理器。这个管理器在游戏启动时创建一个专用的MeshInstance3D（或使用SubViewport+CanvasItem的某种组合），然后在整个游戏运行期间，重复利用这个节点和其背后的ImmediateMesh资源。每一帧，我们清空旧的绘制内容，然后根据当前帧收集到的所有调试绘制请求（比如“在位置(0,1,0)画一个红色球体”），重新生成网格数据并提交。

这种“集中提交”的模式，将大量零散的绘图调用合并为每帧一两次的网格构建操作，并复用GPU资源，是保证高性能的关键。

2.1 插件架构设计

基于以上思路，一个典型的3D调试绘图插件架构如下：

DebugDraw3D (单例/自动加载)：这是插件的核心管理器。它是一个Node（通常是Node3D）的子类，作为自动加载（AutoLoad）单例存在，确保在游戏的任何地方都能通过DebugDraw3D这个全局名称访问到。
绘图命令队列：管理器内部维护几个队列或列表，用于存储本帧接收到的所有绘图命令。命令包含类型（画线、画立方体）、参数（位置、大小、颜色）、持续时间等。
专用绘制节点：在_ready()中，管理器会创建一个（或多个）MeshInstance3D节点，并为其分配一个ImmediateMesh。这个节点被添加到场景树中，但它的唯一用途就是承载调试图形。
帧循环：在_process(delta)中，管理器执行以下操作：
- 遍历命令队列，根据“持续时间”更新每个命令的剩余生命。
- 清除已过期的命令。
- 清空ImmediateMesh。
- 遍历所有存活的命令，调用对应的绘制函数（如_draw_line,_draw_box），向ImmediateMesh添加顶点、颜色等数据。
- 将更新后的ImmediateMesh赋值给MeshInstance3D。
对外接口：提供一系列静态的、易于调用的函数，如DebugDraw3D.draw_line(start, end, color)，DebugDraw3D.draw_sphere(center, radius, color)。这些函数内部只是将绘图命令参数打包，放入管理器的命令队列中。

2.2 与Godot内置调试的对比与互补

你可能会问，Godot的Debugger和Performance监控不是也有可视化吗？是的，但它们面向的是引擎内部状态（如物理碰撞形状、导航网格、帧率图表）。我们的插件是面向游戏逻辑数据的。两者是互补关系。

内置调试：查看引擎“看到”的世界。比如，开启物理调试后，你能看到所有CollisionShape3D的实际轮廓。
自定义调试插件：查看你“代码中”的世界。比如，你计算出的理想路径、角色的仇恨列表范围、一个生成式地形的采样点分布。

在实际项目中，我经常同时开启两者：用内置工具检查引擎层面的问题（如碰撞体错位），用自定义插件检查游戏逻辑层面的问题（如AI决策错误）。

3. 核心实现细节与实操要点

理论说完了，我们进入实战环节。我将以Godot 4.1+版本为例，详细讲解关键部分的实现。

3.1 创建单例管理器

首先，创建一个名为DebugDraw3D.gd的脚本，并将其设置为自动加载（Project Settings -> AutoLoad）。确保其继承自Node3D，以便拥有3D变换能力（虽然管理器本身通常不需要移动）。

# DebugDraw3D.gd extends Node3D class_name DebugDraw3D # 单例实例引用 static var instance: DebugDraw3D = null # 绘图命令队列 var _draw_commands: Array = [] # 我们的专用MeshInstance和ImmediateMesh var _debug_mesh_instance: MeshInstance3D var _immediate_mesh: ImmediateMesh func _init(): # 确保单例唯一性 if instance != null: push_error("DebugDraw3D already instantiated!") return instance = self func _ready(): # 创建绘制节点 _debug_mesh_instance = MeshInstance3D.new() _debug_mesh_instance.name = "DebugDrawMeshInstance" add_child(_debug_mesh_instance) # 创建ImmediateMesh并设置材质 _immediate_mesh = ImmediateMesh.new() _debug_mesh_instance.mesh = _immediate_mesh # 创建一个简单的无光照材质，顶点颜色决定最终颜色 var material = StandardMaterial3D.new() material.shading_mode = StandardMaterial3D.SHADING_MODE_UNSHADED material.vertex_color_use_as_albedo = true material.transparency = BaseMaterial3D.TRANSPARENCY_ALPHA_DEPTH_PRE_PASS // 半透明支持 material.cull_mode = BaseMaterial3D.CULL_DISABLED // 双面显示 _debug_mesh_instance.material_override = material func _process(delta): _update_draw_commands(delta) _render_commands() func _update_draw_commands(delta): # 更新命令持续时间并移除过期命令 var i = 0 while i < _draw_commands.size(): var cmd = _draw_commands[i] cmd.lifetime -= delta if cmd.lifetime <= 0: _draw_commands.remove_at(i) else: i += 1 func _render_commands(): # 清空上一帧的绘制 _immediate_mesh.clear_surfaces() if _draw_commands.is_empty(): return # 开始绘制 _immediate_mesh.surface_begin(Mesh.PRIMITIVE_LINES) for cmd in _draw_commands: match cmd.type: DRAW_TYPE.LINE: _draw_line_immediate(cmd) DRAW_TYPE.BOX: _draw_box_immediate(cmd) # ... 其他类型 _immediate_mesh.surface_end() # 如果需要绘制三角形（如面），需要另一个surface _immediate_mesh.surface_begin(Mesh.PRIMITIVE_TRIANGLES) for cmd in _draw_commands: if cmd.type == DRAW_TYPE.SPHERE_WIREFRAME: # 例如，用三角形画实心球太复杂，这里用线框 pass # 实际实现会更复杂 _immediate_mesh.surface_end() # 具体的绘制函数（以线为例） func _draw_line_immediate(cmd: DrawCommand): _immediate_mesh.surface_set_color(cmd.color) _immediate_mesh.surface_add_vertex(cmd.start) _immediate_mesh.surface_add_vertex(cmd.end) # 对外静态接口 static func draw_line(start: Vector3, end: Vector3, color: Color = Color.WHITE, duration: float = 0.0): if instance == null: push_error("DebugDraw3D instance not found! Is it added to AutoLoad?") return var cmd = DrawCommand.new(DRAW_TYPE.LINE, duration) cmd.start = start cmd.end = end cmd.color = color instance._draw_commands.append(cmd) # 命令类型枚举和命令类 enum DRAW_TYPE { LINE, BOX, SPHERE, ARROW } class DrawCommand: var type: int var lifetime: float var color: Color var start: Vector3 var end: Vector3 # ... 其他参数如 size, radius 等 func _init(p_type: int, p_duration: float): type = p_type lifetime = p_duration if p_duration > 0 else 0.001 # 0表示持续一帧

注意：上面的代码是一个高度简化的框架。实际实现中，你需要处理更多细节：
多材质/多Surface：线、三角形、点可能需要不同的图元类型，不能混在一个surface_begin/end中。通常需要按图元类型分组绘制。
性能优化：如果命令数非常多，每帧遍历数组并重新生成整个网格可能成为瓶颈。可以考虑使用MultiMesh对于大量相同的图形（如大量点）进行实例化绘制，但这会提高复杂度。
深度测试：调试图形应该通常在最上层显示，不被场景物体遮挡。你可能需要设置材质的depth_draw_mode为DEPTH_DRAW_ALWAYS或DEPTH_DRAW_DISABLED，并调整渲染优先级。
坐标系：确保你绘制的顶点坐标是在世界空间（World Space）中。ImmediateMesh添加的顶点是相对于其父节点（我们的DebugDraw3D节点）的。通常我们会将DebugDraw3D节点放在根节点下，并保持其变换为单位矩阵，这样顶点坐标就是世界坐标。

3.2 实现常用几何图元

基于上面的框架，实现各种图元就是数学和ImmediateMeshAPI 调用的结合。这里给出几个关键图元的实现思路：

画线 (Line): 如上所示，最简单，两个顶点。

画立方体框 (Wireframe Box): 一个立方体有12条边。你需要计算8个顶点，然后按顺序连接成12条线段。

static func draw_box(center: Vector3, size: Vector3, color: Color = Color.WHITE, duration: float = 0.0): # size是各轴方向的全尺寸，计算半尺寸 var half = size * 0.5 var points = [ center + Vector3(-half.x, -half.y, -half.z), center + Vector3( half.x, -half.y, -half.z), center + Vector3( half.x, -half.y, half.z), center + Vector3(-half.x, -half.y, half.z), center + Vector3(-half.x, half.y, -half.z), center + Vector3( half.x, half.y, -half.z), center + Vector3( half.x, half.y, half.z), center + Vector3(-half.x, half.y, half.z), ] # 定义12条边的顶点索引对 var edges = [[0,1],[1,2],[2,3],[3,0], [4,5],[5,6],[6,7],[7,4], [0,4],[1,5],[2,6],[3,7]] # 在内部命令类中存储points和edges，在_render时循环绘制

画球体线框 (Wireframe Sphere): 可以通过在多个经度和纬度上画圆环来近似。例如，在XY、XZ、YZ平面上画三个圆环，就能形成一个不错的线框球体。

static func draw_sphere(center: Vector3, radius: float, color: Color = Color.WHITE, duration: float = 0.0): var cmd = DrawCommand.new(DRAW_TYPE.SPHERE_WIRE, duration) cmd.center = center cmd.radius = radius cmd.color = color instance._draw_commands.append(cmd) # 在 _draw_sphere_wire_immediate 中： func _draw_sphere_wire_immediate(cmd): var segments = 24 # 分段数，影响精度和性能 var center = cmd.center var radius = cmd.radius var color = cmd.color _immediate_mesh.surface_set_color(color) # 在XY平面画圆 (Z=0) for i in range(segments): var angle1 = i * TAU / segments var angle2 = (i+1) * TAU / segments var p1 = center + Vector3(cos(angle1)*radius, sin(angle1)*radius, 0) var p2 = center + Vector3(cos(angle2)*radius, sin(angle2)*radius, 0) _immediate_mesh.surface_add_vertex(p1) _immediate_mesh.surface_add_vertex(p2) # 同理画XZ平面和YZ平面的圆

画箭头 (Arrow): 用于表示向量（方向+大小）。通常由一条线段和箭头头部的两个小线段组成。

static func draw_arrow(from: Vector3, to: Vector3, color: Color = Color.WHITE, duration: float = 0.0): var direction = (to - from).normalized() var length = from.distance_to(to) var head_length = min(length * 0.2, 0.5) # 箭头头部长度 var head_width = head_length * 0.5 # 主线 draw_line(from, to, color, duration) # 计算箭头头部的两个分支点 var right = direction.cross(Vector3.UP).normalized() # 需要一个向上的参考向量，如果direction平行于UP，需要处理 if right.length_squared() < 0.001: right = direction.cross(Vector3.FORWARD).normalized() var up = right.cross(direction).normalized() var head_base = to - direction * head_length var branch1 = head_base + right * head_width var branch2 = head_base - right * head_width var branch3 = head_base + up * head_width var branch4 = head_base - up * head_width draw_line(to, branch1, color, duration) draw_line(to, branch2, color, duration) draw_line(to, branch3, color, duration) draw_line(to, branch4, color, duration)

画文本 (Text): 这是最复杂的部分之一。Godot没有直接的3D文本绘制API。常见解决方案有：

使用Label3D节点：动态创建和销毁Label3D节点。性能较差，但最简单。
使用SubViewport+Label：创建一个渲染文本到纹理的SubViewport，然后将其纹理应用到始终面向相机的Sprite3D上。性能中等，实现复杂。
使用TextMesh：Godot 4 的TextMesh资源可以生成3D网格文本。你可以预生成常用字符的网格，然后动态组合。性能最好，但实现最复杂，且灵活性受限。

对于调试插件，如果文本需求不多，采用第一种方案（动态Label3D）并配合对象池进行复用，是一个在易用性和性能之间比较平衡的选择。你需要管理这些Label3D节点的生命周期、位置更新和面向相机（Billboard）行为。

3.3 材质与渲染状态管理

为了让调试图形清晰可见，材质设置至关重要：

无光照 (Unshaded):material.shading_mode = StandardMaterial3D.SHADING_MODE_UNSHADED。我们不希望场景灯光影响调试图形的颜色。
顶点颜色 (Vertex Color as Albedo):material.vertex_color_use_as_albedo = true。这样我们就可以通过surface_set_color来指定每个顶点（或每段图元）的颜色，非常灵活。
透明与混合 (Transparency):material.transparency = BaseMaterial3D.TRANSPARENCY_ALPHA_DEPTH_PRE_PASS或TRANSPARENCY_ALPHA_SCISSOR。前者支持半透明叠加，后者性能更好但边缘有锯齿。调试线框通常不需要完美半透明，ALPHA_SCISSOR可能就够了。
禁用背面剔除 (No Culling):material.cull_mode = BaseMaterial3D.CULL_DISABLED。确保从任何角度都能看到线框。
深度测试 (Depth Test):material.depth_draw_mode = BaseMaterial3D.DEPTH_DRAW_ALWAYS。让调试图形参与深度测试，这样它们会被近处的物体遮挡，更符合空间关系。如果你希望调试图形始终在最前面，可以设置为DEPTH_DRAW_NEVER，但要注意可能造成视觉混乱。

实操心得：在实际项目中，我通常会创建两套材质：一套用于线框（PRIMITIVE_LINES），设置较细的线宽（通过render_priority和可能的自定义着色器模拟）；另一套用于实心面（PRIMITIVE_TRIANGLES），设置适当的透明度。两者都使用顶点颜色。

4. 实战应用：在复杂项目中发挥威力

有了这个插件，你的调试能力将得到质的飞跃。下面分享几个我经历过的真实应用场景。

4.1 场景一：AI行为树与感知系统调试

在一个潜行游戏中，敌人的AI使用行为树，并有一个复杂的视觉/听觉感知系统。

问题：敌人有时会“看穿”墙壁，或者对声音反应异常。
调试：
1. 视觉锥：在敌人的_process中，调用DebugDraw3D.draw_sector(origin, direction, angle, radius, color)（需要自己实现扇形绘制函数），画出其视野范围。立刻就能发现视觉锥的朝向、角度或起始点是否与模型眼睛位置对齐。
2. 视线射线：当敌人进行射线检测判断是否看到玩家时，绘制这条射线DebugDraw3D.draw_line(eye_pos, hit_position, Color.GREEN if can_see else Color.RED, 0.1)。红色表示被阻挡，绿色表示可见。运行游戏，你就能清晰地看到哪些射线击中了墙壁，哪些穿过了本应阻挡的缝隙。
3. 听觉范围：在玩家发出声音的位置，绘制一个逐渐淡出的球体DebugDraw3D.draw_sphere(sound_origin, sound_radius, Color(1,0.5,0,0.5), 2.0)。半透明的橙色球体随时间缩小，直观展示了声音的传播范围和衰减。
4. 行为树状态：在敌人头顶上方，用DebugDraw3D.draw_text_3d(enemy.global_transform.origin + Vector3.UP * 2, current_state_name, Color.YELLOW)显示其当前行为树状态（如“Patrol”, “Chase”, “Search”）。

通过这些可视化手段，我们迅速定位了一个BUG：视觉锥的起始点错误地绑定在了敌人的脚底而非头部，导致其能从地面以下“看到”玩家。也发现了声音系统衰减计算错误，导致声音传播距离是预期的两倍。

4.2 场景二：物理与碰撞检测精调

在一个有复杂车辆物理和自定义碰撞的赛车游戏中。

问题：车辆在某些斜坡上会莫名弹起，与路肩的碰撞感觉不真实。
调试：
1. 车轮射线：车辆使用射线检测来模拟车轮悬架和碰撞。我们在每个车轮位置绘制射线DebugDraw3D.draw_line(wheel_pos, wheel_pos - Vector3.UP * max_suspension, Color.CYAN)。当射线击中地面时，在击中点画一个小点DebugDraw3D.draw_point(hit_point, Color.RED, 0.5)。这样就能清楚地看到每条射线的长度、是否击中、击中点在哪里。
2. 车辆包围盒：绘制车辆的物理包围盒（可以从CollisionShape3D计算或自定义）。DebugDraw3D.draw_box(global_transform.origin, custom_size, Color.WHITE, 0)。在高速翻滚时，观察包围盒与实际模型的贴合度。
3. 接触点与法线：在物理碰撞回调中，获取接触点（contact point）和法线（normal）。在接触点画点，并沿法线方向画一条短线DebugDraw3D.draw_line(contact_point, contact_point + normal, Color.MAGENTA, 0.2)。这揭示了碰撞发生的精确位置和表面的方向，对于调整碰撞体形状和物理材质参数至关重要。

通过可视化，我们发现车辆底盘的碰撞体在某些倾斜角度下会与地面产生多个不稳定的接触点，导致向上的合力突变，引起弹跳。通过调整碰撞体形状和增加物理阻尼，问题得以解决。

4.3 场景三：程序化生成与寻路验证

在一个使用程序化算法生成地下城关卡的项目中。

问题：生成的房间有时会重叠，导航网格烘焙后AI无法在某些门廊通行。
调试：
1. 房间边界：在生成算法中，为每个房间绘制其矩形边界DebugDraw3D.draw_rect_3d(room_center, room_size, Color.GREEN, 10.0)。持久显示10秒，让你一目了然地看到所有房间的布局，重叠部分立刻显现。
2. 导航网格边界：在烘焙导航网格后，遍历NavigationRegion3D获取其NavigationMesh资源，并读取多边形的顶点数据。用DebugDraw3D.draw_polygon(polygon_vertices, Color.BLUE)将每个导航多边形轮廓画出来。这时你会发现，某些狭窄的门廊处，因为导航网格体素（voxel）大小的限制，没有生成可通行的多边形。
3. 寻路路径：当AI计算路径时，将得到的路径点数组（Vector3数组）用线段依次连接起来DebugDraw3D.draw_path(path_points, Color.YELLOW)。黄色的折线清晰地展示了AI将要行走的路线。如果路径在某个点中断或绕远，结合导航网格可视化，就能快速定位是网格数据问题还是寻路算法问题。

我们利用这个插件发现，房间生成算法在连接房间的走廊处，没有预留足够的空间给导航网格体素化，导致走廊中间“断裂”。通过调整算法，确保走廊宽度至少是导航网格体素大小的两倍，问题迎刃而解。

5. 高级技巧、性能优化与常见问题

5.1 性能优化策略

即使使用了ImmediateMesh，不当使用仍可能导致性能问题。

批处理与排序：在_render_commands中，不要为每个命令单独调用surface_begin/end。应该按图元类型（线、三角形）和材质（如果需要多种颜色/透明度）对命令进行排序和批处理。将所有线段放在一个绘制调用里，所有三角形放在另一个里。
限制绘制数量：提供一个全局开关或详细级别（LOD）控制。在发布版本或性能分析时，可以完全关闭调试绘制，或者只绘制最重要的部分（如只画路径，不画感知范围）。
避免每帧分配内存：DrawCommand对象的创建和数组的增删会触发垃圾回收（GC）。可以使用对象池（Object Pool）来复用命令对象。同样，用于计算顶点位置的临时Vector3数组也尽量复用。
使用MultiMesh处理大量重复图形：如果你需要绘制成千上万个相同的点（比如粒子系统的潜在位置），使用MultiMeshInstance3D配合MultiMesh的性能远高于用ImmediateMesh画成千上万条短线。可以在插件中集成一个专门的“点云”绘制模式。
谨慎使用3D文本：动态创建Label3D是昂贵的。如果必须显示大量文本，考虑使用2D的Control节点配合SubViewport渲染到纹理，或者仅在调试时通过2D的CanvasLayer显示信息。

5.2 常见问题与排查

什么都画不出来？
- 检查单例：确保DebugDraw3D已正确添加到项目的自动加载列表，且没有拼写错误。
- 检查渲染顺序：你的调试MeshInstance3D可能被其他不透明物体完全遮挡。尝试将它的render_priority调高，或使用DEPTH_DRAW_NEVER材质。
- 检查相机裁剪：确保调试图形在相机视锥体（Frustum）内。画一个在(0,0,0)的大立方体测试。
- 检查颜色和透明度：颜色Alpha值是否为0？材质是否设置了vertex_color_use_as_albedo = true？
绘制导致帧率严重下降？
- 使用性能分析器：打开Godot的Debugger -> Profiler，查看_process和_physics_process中哪个函数耗时最长。很可能是你的绘制命令过多或_render_commands中的循环效率低下。
- 减少绘制数量：添加一个简单的计数器，在控制台输出每帧绘制的图元数量。如果超过几千，就需要考虑优化或减少细节。
- 检查是否在循环中错误调用：确保draw_xxx函数不是在嵌套很深的循环中被调用成千上万次。有时一个双重循环就能产生海量的绘制请求。
线条闪烁或抖动？
- 深度冲突 (Z-fighting)：当调试图形与场景物体表面几乎重合时，会因为深度缓冲精度问题产生闪烁。可以轻微偏移调试图形（例如，沿法线方向偏移0.01单位），或者使用DEPTH_DRAW_NEVER使其始终在前。
- 时间不一致：如果你在_physics_process中更新逻辑并绘制，但在_process中渲染，而两者帧率不同，可能导致图形位置更新和渲染不同步。确保绘图命令的提交和渲染在同一个处理循环中（通常都在_process里）。
如何在不同场景间保持调试？
- 由于DebugDraw3D是自动加载的单例，它存在于整个游戏生命周期中，独立于任何具体场景。无论你切换到哪里，它都会持续存在并绘制。这是它相对于临时节点的一大优势。