Primary and secondary handles are no longer differentiated by their ids, so a bool was added to tell them apart in all the handle-related methods.
Includes a minor fix in CollisionPolygon3DEditor, unrelated to editor gizmos.
* New syntax is type safe.
* New syntax allows for type safe virtuals in native extensions.
* New syntax permits extremely fast calling.
Note: Everything was replaced where possible except for `_gui_input` `_input` and `_unhandled_input`.
These will require API rework on a separate PR as they work different than the rest of the functions.
Added a new method flag METHOD_FLAG_OBJECT_CORE, used internally. Allows to not dump the core virtuals like `_notification` to the json API, since each language will implement those as it is best fits.
For the time being we don't support writing a description for those, preferring
having all details in the method's description.
Using self-closing tags saves half the lines, and prevents contributors from
thinking that they should write the argument or return documentation there.
* Fixed subgizmo editing on scaled nodes.
* Added more clarifications on the coordinate space of subgizmos.
* Given input priority to the transform gizmo over subgizmo selection.
* Clean-up of node_3d_editor_plugin.{h,cpp}: removed unused code, fixed some bugs.
* Moved node_3d_editor_gizmos.{h,cpp} to editor/plugins.
* Added support for multiple gizmos per node. This means custom gizmos will no longer override the built-in ones and that multiple gizmos can be used in more complex nodes.
* Added support for handle IDs. When adding handles to a gizmo, an ID can be specified for each one, making it easier to work with gizmos that have a variable number of handles.
* Added support for subgizmos, selectable elements that can be transformed without needing a node of their own. By overriding _subgizmo_intersect_frustum() and/or _subgizmo_intersect_ray() gizmos can define which subgizmos should be selected on a region or click selection. Subgizmo transformations are applied using get/set/commit virtual methods, similar to how handles work.
Resolvesgodotengine/godot-proposals#1246.
It is difficult to tell the difference between the handles for adjusting
curves and the points themselves when looking at a Path gizmo.
This re-uses the icons used for Path2D.
Unlike Path2D, this does not use a different icon for smooth vs sharp
points, as using a potentially different material for each point would
prevent batching the points in add_handles (and adding them out-of-order
messes up other logic based on handle indices).
This includes a public API change to allow specifying a texture for a
handle material. This allows spatial gizmo plugins to customize the way
a handle is rendered, if desired, but does not break existing behavior
(as providing no texture uses the default).
The path handle icons were resized as well. 16x16 is the standard icon
size. These icons were 10x10 rather than 16x16, and appeared rather
small in the editor.
To resize, I:
- Opened the original in Inkscape
- Resized the document to 16x16
- Opened the transform dialog
- Scaled by 160% proportionally
- Used Align/Distribute to center on the page
- Saved the document
- Cleaned with `svgcleaner --multipass`
