Editor architecture and isolated iteration
Current source locations, EditorInterface boundaries and an isolated test environment.
Editor architecture
The editor uses engine UI controls and rendering. Use EditorPlugin and EditorInterface for project extensions; C++ source is needed when changing built-in implementation. The editor is not an ordinary user .rscene project that can simply be opened and resaved.
Locate the code
Paths below are relative to the current Source root:
| Path | Responsibility |
|---|---|
editor/editor_node.cpp | Main interface assembly and editor coordination. EditorNode is the actual internal C++ class identifier. |
editor/editor_interface.cpp | Public bridge to editor capabilities, also used by C# tools. |
editor/plugins/editor_plugin.cpp | Extension and control registration. |
editor/docks/ | Panels and dock infrastructure, including EditorDock. |
editor/project_manager/project_manager.cpp | Separate project-manager interface. |
editor/scene/canvas_item_editor_plugin.cpp | Main 2D editor. |
editor/scene/3d/entity_3d_editor_plugin.cpp | Main 3D editor. |
editor/scene/3d/gizmos/ | Specialized 3D gizmos. |
editor/themes/ | Theme generation, fonts, icons and style variants. |
modules/ | Additional features; modules can have their own editor portion. |
Not every feature lives in one editor file. Control and Theme resources, for example, are implemented in shared scene/gui/ and scene/resources/; lower-level servers support both editor and game.
Public API boundary
EditorInterface provides the base Control, currently edited level, theme and other documented capabilities. It does not promise a stable internal tree for every child control.
Use EditorDock for panels and EditorInspectorPlugin for inspector extensions. Do not copy an entire built-in panel for one command or couple a plugin to another button's localized caption. An internal handler can be useful in a narrow implementation check without becoming a third-party tool contract.
Change editor core
- Reproduce the problem in a small project and identify the relevant control, plugin or resource.
- Locate the handler and dependencies. Keep new code dependencies flowing
editor → scene → servers → core; do not treat an existing reverse include as a model for a new layer. - Decide whether the change affects only the editor or game behavior too. A shared Control change can affect both; an editor-panel test does not cover exported-game UI.
- Build a separate
target=editorusing the build guide. Account for the managed package when using C#. - Open a separate test project with the new binary. Check reproduction, tool activation/deactivation, saving/reopening levels and undo behavior.
This guide does not automatically require core changes. If a plugin solves the task, test it within a project without replacing the working engine. No C++ editor build was performed for this article; the file map was reviewed against current source.