NecromanovPDE这个项目其实是从一个很具体的问题里长出来的——Processing在可视化编程、快速原型和交互艺术领域确实很顺手，但真到了“把一堆三维模型摆进一个场景、调好角度、导出给别的系统用”这一步，你会发现它天生缺一套正经的编辑器。你可以用代码逐行声明每个物体的位置和旋转，但想用鼠标拖拽、实时看到层级关系、像在Unity里一样组织场景结构，Processing原生的开发环境基本帮不上忙。
PDE（Processing D Editor）想做的事，就是把这个缺口补上：在Processing生态里，做一版面向三维场景的轻量编辑器。它不是一个建模工具，也无意跟Blender这类重型软件抢饭碗，它解决的核心问题是“场景编排”——把现成的模型、粒子、光效、地形参数组合进一个统一的三维空间，以可视化的方式维护，然后输出成结构化数据，交给运行时引擎或者业务系统加载。这篇记录会把它的设计思路、核心模块的落地方法、以及我在开发过程中踩过的坑完整写出来，尤其适合两类人看：一类是在Processing里做可视化项目的开发者，另一类是想自己写一个“小Unity”但不想从零造引擎的人。
1. 项目缘起：为什么说Processing缺一个编辑器
1.1 Processing生态的短板
Processing最爽的地方也是它最头疼的地方：一切都能用代码画出来，但一切都要靠代码组织。写一个demo的时候这完全没问题，代码本身就是存档，运行即所见。可一旦场景里有两百个物件、几十种材质、一套复杂的相机路径，用代码维护的体验就会迅速劣化。模型的坐标散落在初始化函数里，材质参数在另一个类里以静态常量存在，粒子系统的发射位置又在配置文件中——出了需求变更，你要在代码里来回穿梭。三维场景编辑器存在的意义，就是把“数据编排”和“渲染表现”分开：编辑器负责管理场景里有什么、摆在哪、怎么动，运行端只关心怎么把这些数据高效画出来。
PDE的定位就是这一层的编辑器。它不替代Processing做渲染，恰恰相反，它把Processing当作一个可嵌入的渲染底子，在上面套上场景管理、层级面板、属性面板、相机控制器和文件序列化体系。
1.2 PDE在场景资源流里的位置
你可以把PDE理解成一条可视化装配线：
- 输入侧：导入外部模型文件（OBJ、STL或SVG化的轮廓），或者直接用内置的图元生成器创建球体、立方体、地形等基础体；
- 编辑侧：用户在工作区以所见即所得的方式摆放对象、调整属性、建立父子层级、设置动画参数；
- 输出侧：整个场景序列化成JSON，网络加载器、数据可视化引擎、甚至另一台机器上的Processing程序都可以消费这份配置。
这条链路里PDE的关键产出不是画面，而是“可移植的场景描述”。这也是它和SketchUp、Blender最大的区别：别人围绕网格编辑做文章，PDE围绕场景编排做文章，建模用外部工具，编辑用PDE，运行时各自负责，中间用定义良好的场景文件衔接。
1.3 技术选型的基本盘
技术选型没有太多悬念。编辑器本身跑在JVM上，开发语言Java 17，渲染层直接用Processing 4.x的P3D渲染器，UI层使用Java Swing作为宿主窗口框架。我知道很多人的第一反应是“Swing太老了”，但这里有一个很现实的理由：Processing的PApplet本质上就是一个AWT/Swing组件，使用Swing做壳可以做到最小程度的桥接损耗，不需要中间再套一层JavaFX的WebView或者第三方原生窗口库。PDE当前版本基于Processing 4.3构建，早期原型在3.5.2上也验证过，只要是P3D渲染模式，核心场景类就能兼容。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. PDE编辑器整体架构与场景数据模型
2.1 模块边界怎么切
整个编辑器我按“数据模型—渲染视图—编辑交互—序列化”四层来拆。
第一层是SceneModel，也就是所有场景元素的抽象表示。Node是所有元素的基类，下面派生MeshNode（模型/图元）、GroupNode（容器）、CameraNode（相机）、LightNode（灯光）。这层不依赖任何Processing类，只是为了“描述场景”而存在，理论上一套数据模型可以服务多个渲染后端。第二层是RenderView，负责把SceneModel里的数据翻译成Processing的绘制指令，这一层才允许直接调用PVector、PShape、PImage等渲染API。第三层是EditorInteraction，处理鼠标拾取、拖动、框选、层级拖拽，其实就是在Processing画布上叠了事件处理器。第四层是SceneIO，负责JSON的导出和导入。
这么做最大的好处是替换成本极低。如果你想给PDE换一个渲染后端，比如换成JOGL裸写OpenGL，只需重写RenderView层，SceneModel和SceneIO不会被影响。反过来，如果你想出另一种场景文件格式，比如二进制或XML，只动SceneIO即可。
2.2 SceneGraph的关键设计
SceneModel内部是一个典型的场景图（SceneGraph）。根节点永远是唯一的SceneRoot，下面挂各种Node，每个Node有一个parent引用和一个有序children列表。节点数据结构我简化成下面这样：
java复制public abstract class Node {
private String id; // 全局唯一
private String name; // 显示名称
private Node parent;
private final List<Node> ch