You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An EditorPlugin that provides specialized translation and rotation gizmos for Node3D. My plugin provides a gizmo that snaps nodes to a hexagonal grid on the XZ plane while translating and rotates nodes in 60 degree increments while preserving any rotational offset provided by the user.
I am using this plugin for my own personal use, currently, but I would like to release publicly once I can solve the issue that prompted this request, detailed below.
Describe the problem or limitation you are having in your project
The issue I'm facing is that the default Node3D gizmo handles get in the way of my own gizmo's handles. Two solutions I've tried:
Simply move my handles further away. This works but isn't ideal as the visual clutter gets worse and the default handles can still be accidentally interacted with, introducing unwanted transform modifications.
Use the editor lock feature to lock nodes while a node is selected (toggleable by user). This is also not ideal because it hijacks another feature and means my gizmo is forced to ignore the lock setting, making my gizmos effectively unlockable.
A third solution I have considered is having my plugin navigate the editor UI and use the user-facing menus and options to toggle gizmos on and off. This is also bad because it means my plugin will break if the nodes used in the editor interface ever change and could possibly have unintended side effects such as stealing focus.
It also appears from my testing that the default gizmos are not returned by Node3D.get_gizmos() nor affected by Node3D.clear_gizmos(), not that either of these would really be a good option even if they did work.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
The feature I'm proposing is some method for plugins and code in the editor context (such as tool scripts) to control the visibility of gizmos on specific nodes.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
One possibility is some method on the Node3D class that toggles the visibility if its default gizmos:
Perhaps including an optional flag parameter to control which gizmos specifically. An open question that remains would be if and how this will include custom gizmos added by plugins.
Another option could be a method on EditorNode3DGizmoPlugin that declares exclusivity over objects that it handles via EditorNode3DGizmoPlugin._create_gizmo, such that the returned gizmo will be used exclusively.
If this enhancement will not be used often, can it be worked around with a few lines of script?
It is possible to partially work around the issue, but so far the best solution I could come up with involves hijacking an unrelated feature (editor lock) and requires that my gizmo can not respect the lock setting. The workaround feels hacky and makes me hesitant to include in a publicly released plugin. For my own purposes I can deal with it, but it doesn't work as well as I'd like or as it could.
Is there a reason why this should be core and not an add-on in the asset library?
Because I am making an addon and I can't find any way to do it properly :)
The text was updated successfully, but these errors were encountered:
I had come close to that conclusion myself after searching through the source last night, as I didn't see them alongside the other gizmo plugins for the more specialized Node3D types. But I wasn't entirely sure so I'm glad you can confirm it. I suppose that means then that there really is no way for a plugin to modify their visibility aside from (mis)using the editor lock feature or navigating the UI to click the options to hide gizmos (which might even hide my gizmo?).
The Node3DEditor already uses node meta data to know when not to draw the transform gizmos, e.g. when a node is locked with meta _edit_lock_, so maybe this can be used or extended for plugins.
Describe the project you are working on
An EditorPlugin that provides specialized translation and rotation gizmos for Node3D. My plugin provides a gizmo that snaps nodes to a hexagonal grid on the XZ plane while translating and rotates nodes in 60 degree increments while preserving any rotational offset provided by the user.
I am using this plugin for my own personal use, currently, but I would like to release publicly once I can solve the issue that prompted this request, detailed below.
Describe the problem or limitation you are having in your project
The issue I'm facing is that the default Node3D gizmo handles get in the way of my own gizmo's handles. Two solutions I've tried:
A third solution I have considered is having my plugin navigate the editor UI and use the user-facing menus and options to toggle gizmos on and off. This is also bad because it means my plugin will break if the nodes used in the editor interface ever change and could possibly have unintended side effects such as stealing focus.
It also appears from my testing that the default gizmos are not returned by
Node3D.get_gizmos()
nor affected byNode3D.clear_gizmos()
, not that either of these would really be a good option even if they did work.Describe the feature / enhancement and how it helps to overcome the problem or limitation
The feature I'm proposing is some method for plugins and code in the editor context (such as tool scripts) to control the visibility of gizmos on specific nodes.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
One possibility is some method on the Node3D class that toggles the visibility if its default gizmos:
Perhaps including an optional flag parameter to control which gizmos specifically. An open question that remains would be if and how this will include custom gizmos added by plugins.
Another option could be a method on EditorNode3DGizmoPlugin that declares exclusivity over objects that it handles via
EditorNode3DGizmoPlugin._create_gizmo
, such that the returned gizmo will be used exclusively.Or as an optional parameter on
EditorPlugin.add_node_3d_gizmo_plugin
to preserve backwards compatibility and current behavior:If this enhancement will not be used often, can it be worked around with a few lines of script?
It is possible to partially work around the issue, but so far the best solution I could come up with involves hijacking an unrelated feature (editor lock) and requires that my gizmo can not respect the lock setting. The workaround feels hacky and makes me hesitant to include in a publicly released plugin. For my own purposes I can deal with it, but it doesn't work as well as I'd like or as it could.
Is there a reason why this should be core and not an add-on in the asset library?
Because I am making an addon and I can't find any way to do it properly :)
The text was updated successfully, but these errors were encountered: