Is your feature request related to a problem? Please describe.
Trying to create an extension to the scene editor, eg. spline editor, terrain editor, is difficult due to current code structure.
I have created a proof of concept project of a spline editor, along with a write up of issues that need to be resolved. for proper integration (currently uses reflection to bypass engine issues).
The TLDR is that developers need to be able to register an editor control, and be able to properly take control of the scene in a predictable way.
You can extend EditorGameMouseServiceBase and block input with IsControllingMouse = true.
For something like a spline editor, this is necessary for blocking the entity selector service which controls selection/deselection of an entity (or multiple entities) that you click in the scene, however doing so also blocks the editor camera and transform gizmo (which we don't want to block).
Describe the solution you'd like
Most common solution is to extend some base editor tool class, with configuration like if it is targeted for an entity component or a global tool.
Looking at other engines:
Unreal Engine divides scene editing into distinct modes (Select, Landscape, Foliage, etc)
https://dev.epicgames.com/documentation/unreal-engine/level-editor-modes-in-unreal-engine
Not counting their blueprint solution, you need to extend UEdMode and register that class
https://dev.epicgames.com/documentation/unreal-engine/API/Editor/UnrealEd/UEdMode
Does not appear to have input blocking, I assume modes are exclusive (or it is done in a different way).
Unity tries to be more context based, based on the current entity selection, then select the edit mode:
https://docs.unity3d.com/6000.4/Documentation/ScriptReference/EditorTools.EditorTool.html
https://www.foundations.unity.com/patterns/contextual-tooling
You extend EditorTool and define the context (eg. component specific or global). The different editing modes only appear after selecting the correct object (assuming you've made a component specific editor).
It is very IMGUI centric, so things like displaying handles, input handling (and consuming input) is done in IMGUI way.
Godot can be context based, based on the current entity ("node") selection, however it does not appear have different edit modes:
https://docs.godotengine.org/en/latest/classes/class_editorplugin.html
You extend EditorPlugin and define context with _handles
Can block input with _forward_3d_gui_input
O3DE is also context based:
https://docs.o3de.org/docs/user-guide/programming/components/editor-components/
You extend EditorComponentBase.
Note that the editor component adds a Edit/Done button at the bottom of the component's properties, see
https://youtu.be/hboNgEpH8O8?t=2232 (~37min 12s mark)
Unlike Unity/Godot, this also locks the UI's entity tree & all other components from being edited until the User hits Done.
No input blocking required as modes are exclusive (I'm assuming).
Proposed solution
At a minimum we need some editor tool class to inherit to register (or assembly scanned).
Internally the scene entity selector service, editor camera and transform gizmo services should not be updating independently, and should be driven by a new 'entity selection mode' editor tool class.
If any new 'modes' are created, then they can get the editor camera and transform gizmo services and update (assuming they need them).
In terms of activating the tool, not sure if having an explicit mode like Unreal (also Blender), or context based. Context based might make more sense since usually you need some entity target selected.
Additional context
A much more generalized issue for the plugin system is written in #1120
This is much more focused on extending the scene editor for things like spline editing & terrain painting.
Additional features can be extended, eg. injecting additional UI controls, blocking input events (eg. conflicting hotkeys should prioritize the active tool), however that is increasing the scope.
Is your feature request related to a problem? Please describe.
Trying to create an extension to the scene editor, eg. spline editor, terrain editor, is difficult due to current code structure.
I have created a proof of concept project of a spline editor, along with a write up of issues that need to be resolved. for proper integration (currently uses reflection to bypass engine issues).
The TLDR is that developers need to be able to register an editor control, and be able to properly take control of the scene in a predictable way.
You can extend
EditorGameMouseServiceBaseand block input withIsControllingMouse = true.For something like a spline editor, this is necessary for blocking the entity selector service which controls selection/deselection of an entity (or multiple entities) that you click in the scene, however doing so also blocks the editor camera and transform gizmo (which we don't want to block).
Describe the solution you'd like
Most common solution is to extend some base editor tool class, with configuration like if it is targeted for an entity component or a global tool.
Looking at other engines:
Unreal Engine divides scene editing into distinct modes (Select, Landscape, Foliage, etc)
https://dev.epicgames.com/documentation/unreal-engine/level-editor-modes-in-unreal-engine
Not counting their blueprint solution, you need to extend
UEdModeand register that classhttps://dev.epicgames.com/documentation/unreal-engine/API/Editor/UnrealEd/UEdMode
Does not appear to have input blocking, I assume modes are exclusive (or it is done in a different way).
Unity tries to be more context based, based on the current entity selection, then select the edit mode:
https://docs.unity3d.com/6000.4/Documentation/ScriptReference/EditorTools.EditorTool.html
https://www.foundations.unity.com/patterns/contextual-tooling
You extend
EditorTooland define the context (eg. component specific or global). The different editing modes only appear after selecting the correct object (assuming you've made a component specific editor).It is very IMGUI centric, so things like displaying handles, input handling (and consuming input) is done in IMGUI way.
Godot can be context based, based on the current entity ("node") selection, however it does not appear have different edit modes:
https://docs.godotengine.org/en/latest/classes/class_editorplugin.html
You extend
EditorPluginand define context with_handlesCan block input with
_forward_3d_gui_inputO3DE is also context based:
https://docs.o3de.org/docs/user-guide/programming/components/editor-components/
You extend
EditorComponentBase.Note that the editor component adds a Edit/Done button at the bottom of the component's properties, see
https://youtu.be/hboNgEpH8O8?t=2232 (~37min 12s mark)
Unlike Unity/Godot, this also locks the UI's entity tree & all other components from being edited until the User hits Done.
No input blocking required as modes are exclusive (I'm assuming).
Proposed solution
At a minimum we need some editor tool class to inherit to register (or assembly scanned).
Internally the scene entity selector service, editor camera and transform gizmo services should not be updating independently, and should be driven by a new 'entity selection mode' editor tool class.
If any new 'modes' are created, then they can get the editor camera and transform gizmo services and update (assuming they need them).
In terms of activating the tool, not sure if having an explicit mode like Unreal (also Blender), or context based. Context based might make more sense since usually you need some entity target selected.
Additional context
A much more generalized issue for the plugin system is written in #1120
This is much more focused on extending the scene editor for things like spline editing & terrain painting.
Additional features can be extended, eg. injecting additional UI controls, blocking input events (eg. conflicting hotkeys should prioritize the active tool), however that is increasing the scope.