2017-09-12 22:42:36 +02:00
<?xml version="1.0" encoding="UTF-8" ?>
2020-03-30 18:22:57 +02:00
<class name= "Node3D" inherits= "Node" version= "4.0" >
2017-09-12 22:42:36 +02:00
<brief_description >
2019-06-22 01:04:47 +02:00
Most basic 3D game object, parent of all 3D-related nodes.
2017-09-12 22:42:36 +02:00
</brief_description>
<description >
2020-05-03 10:27:36 +02:00
Most basic 3D game object, with a 3D [Transform3D] and visibility settings. All other 3D game objects inherit from Node3D. Use [Node3D] as a parent node to move, scale, rotate and show/hide children in a 3D project.
2020-03-30 18:22:57 +02:00
Affine operations (rotate, scale, translate) happen in parent's local coordinate system, unless the [Node3D] object is set as top-level. Affine operations in this coordinate system correspond to direct affine operations on the [Node3D]'s transform. The word local below refers to this coordinate system. The coordinate system that is attached to the [Node3D] object itself is referred to as object-local coordinate system.
2021-01-04 14:33:44 +01:00
[b]Note:[/b] Unless otherwise specified, all methods that have angle parameters must have angles specified as [i]radians[/i]. To convert degrees to radians, use [method @GlobalScope.deg2rad].
2017-09-12 22:42:36 +02:00
</description>
<tutorials >
2020-08-05 14:43:40 +02:00
<link title= "Introduction to 3D" > https://docs.godotengine.org/en/latest/tutorials/3d/introduction_to_3d.html</link>
2020-10-01 10:34:47 +02:00
<link title= "All 3D Demos" > https://github.com/godotengine/godot-demo-projects/tree/master/3d</link>
2017-09-12 22:42:36 +02:00
</tutorials>
<methods >
2021-06-23 16:49:50 +02:00
<method name= "add_gizmo" >
<return type= "void" >
</return>
<argument index= "0" name= "gizmo" type= "Node3DGizmo" >
</argument>
<description >
Attach a gizmo to this [code]Node3D[/code].
</description>
</method>
<method name= "clear_gizmos" >
<return type= "void" >
</return>
<description >
Clear all gizmos attached to this [code]Node3D[/code].
</description>
</method>
<method name= "clear_subgizmo_selection" >
<return type= "void" >
</return>
<description >
Clears subgizmo selection for this node in the editor. Useful when subgizmo IDs become invalid after a property change.
</description>
</method>
2018-09-11 00:18:05 +02:00
<method name= "force_update_transform" >
<return type= "void" >
</return>
<description >
2019-11-01 10:37:39 +01:00
Forces the transform to update. Transform changes in physics are not instant for performance reasons. Transforms are accumulated and then set. Use this if you need an up-to-date transform when doing physics operations.
2018-09-11 00:18:05 +02:00
</description>
</method>
2021-06-23 16:49:50 +02:00
<method name= "get_gizmos" qualifiers= "const" >
<return type= "Array" >
</return>
<description >
Returns all the gizmos attached to this [code]Node3D[/code].
</description>
</method>
2021-06-09 13:06:38 +02:00
<method name= "get_parent_node_3d" qualifiers= "const" >
2020-03-30 18:22:57 +02:00
<return type= "Node3D" >
2017-09-12 22:42:36 +02:00
</return>
<description >
2020-03-30 18:22:57 +02:00
Returns the parent [Node3D], or an empty [Object] if no parent exists or parent is not of type [Node3D].
2017-09-12 22:42:36 +02:00
</description>
</method>
2020-05-04 16:55:01 +02:00
<method name= "get_world_3d" qualifiers= "const" >
2020-03-30 18:22:57 +02:00
<return type= "World3D" >
2017-09-12 22:42:36 +02:00
</return>
<description >
2020-03-30 18:22:57 +02:00
Returns the current [World3D] resource this [Node3D] node is registered to.
2017-09-12 22:42:36 +02:00
</description>
</method>
2018-01-03 13:45:03 +01:00
<method name= "global_rotate" >
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
<return type= "void" >
</return>
<argument index= "0" name= "axis" type= "Vector3" >
</argument>
<argument index= "1" name= "angle" type= "float" >
</argument>
<description >
2018-01-03 13:45:03 +01:00
Rotates the global (world) transformation around axis, a unit [Vector3], by specified angle in radians. The rotation axis is in global coordinate system.
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
</description>
</method>
2018-01-03 13:45:03 +01:00
<method name= "global_scale" >
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
<return type= "void" >
</return>
<argument index= "0" name= "scale" type= "Vector3" >
</argument>
<description >
2019-10-30 11:19:08 +01:00
Scales the global (world) transformation by the given [Vector3] scale factors.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "global_translate" >
<return type= "void" >
</return>
<argument index= "0" name= "offset" type= "Vector3" >
</argument>
<description >
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
Moves the global (world) transformation by [Vector3] offset. The offset is in global coordinate system.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "hide" >
<return type= "void" >
</return>
<description >
2019-01-07 10:02:04 +01:00
Disables rendering of this node. Changes [member visible] to [code]false[/code].
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "is_local_transform_notification_enabled" qualifiers= "const" >
<return type= "bool" >
</return>
<description >
2020-03-30 18:22:57 +02:00
Returns whether node notifies about its local transformation changes. [Node3D] will not propagate this by default.
2017-09-12 22:42:36 +02:00
</description>
</method>
2018-07-26 11:56:21 +02:00
<method name= "is_scale_disabled" qualifiers= "const" >
<return type= "bool" >
</return>
<description >
2019-10-30 11:19:08 +01:00
Returns whether this node uses a scale of [code](1, 1, 1)[/code] or its local transformation scale.
2018-07-26 11:56:21 +02:00
</description>
</method>
2017-09-12 22:42:36 +02:00
<method name= "is_transform_notification_enabled" qualifiers= "const" >
<return type= "bool" >
</return>
<description >
2020-03-30 18:22:57 +02:00
Returns whether the node notifies about its global and local transformation changes. [Node3D] will not propagate this by default.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "is_visible_in_tree" qualifiers= "const" >
<return type= "bool" >
</return>
<description >
2020-07-27 12:09:51 +02:00
Returns [code]true[/code] if the node is present in the [SceneTree], its [member visible] property is [code]true[/code] and all its antecedents are also visible. If any antecedent is hidden, this node will not be visible in the scene tree.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "look_at" >
<return type= "void" >
</return>
<argument index= "0" name= "target" type= "Vector3" >
</argument>
2019-09-24 19:45:03 +02:00
<argument index= "1" name= "up" type= "Vector3" default= "Vector3(0, 1, 0)" >
2017-09-12 22:42:36 +02:00
</argument>
<description >
2018-04-29 15:44:07 +02:00
Rotates itself so that the local -Z axis points towards the [code]target[/code] position.
The transform will first be rotated around the given [code]up[/code] vector, and then fully aligned to the target by a further rotation around an axis perpendicular to both the [code]target[/code] and [code]up[/code] vectors.
Operations take place in global space.
2017-09-12 22:42:36 +02:00
</description>
</method>
2017-09-10 15:37:49 +02:00
<method name= "look_at_from_position" >
2017-09-12 22:42:36 +02:00
<return type= "void" >
</return>
2017-09-10 15:37:49 +02:00
<argument index= "0" name= "position" type= "Vector3" >
2017-09-12 22:42:36 +02:00
</argument>
<argument index= "1" name= "target" type= "Vector3" >
</argument>
2019-09-24 19:45:03 +02:00
<argument index= "2" name= "up" type= "Vector3" default= "Vector3(0, 1, 0)" >
2017-09-12 22:42:36 +02:00
</argument>
<description >
2018-04-29 15:44:07 +02:00
Moves the node to the specified [code]position[/code], and then rotates itself to point toward the [code]target[/code] as per [method look_at]. Operations take place in global space.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "orthonormalize" >
<return type= "void" >
</return>
<description >
2020-05-03 10:27:36 +02:00
Resets this node's transformations (like scale, skew and taper) preserving its rotation and translation by performing Gram-Schmidt orthonormalization on this node's [Transform3D].
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "rotate" >
<return type= "void" >
</return>
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
<argument index= "0" name= "axis" type= "Vector3" >
2017-09-12 22:42:36 +02:00
</argument>
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
<argument index= "1" name= "angle" type= "float" >
2017-09-12 22:42:36 +02:00
</argument>
<description >
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
Rotates the local transformation around axis, a unit [Vector3], by specified angle in radians.
2017-09-12 22:42:36 +02:00
</description>
</method>
2018-01-03 13:45:03 +01:00
<method name= "rotate_object_local" >
<return type= "void" >
</return>
<argument index= "0" name= "axis" type= "Vector3" >
</argument>
<argument index= "1" name= "angle" type= "float" >
</argument>
<description >
Rotates the local transformation around axis, a unit [Vector3], by specified angle in radians. The rotation axis is in object-local coordinate system.
</description>
</method>
2017-09-12 22:42:36 +02:00
<method name= "rotate_x" >
<return type= "void" >
</return>
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
<argument index= "0" name= "angle" type= "float" >
2017-09-12 22:42:36 +02:00
</argument>
<description >
2019-06-22 01:04:47 +02:00
Rotates the local transformation around the X axis by angle in radians.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "rotate_y" >
<return type= "void" >
</return>
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
<argument index= "0" name= "angle" type= "float" >
2017-09-12 22:42:36 +02:00
</argument>
<description >
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
Rotates the local transformation around the Y axis by angle in radians.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "rotate_z" >
<return type= "void" >
</return>
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
<argument index= "0" name= "angle" type= "float" >
2017-09-12 22:42:36 +02:00
</argument>
<description >
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
Rotates the local transformation around the Z axis by angle in radians.
2017-09-12 22:42:36 +02:00
</description>
</method>
2018-01-03 13:45:03 +01:00
<method name= "scale_object_local" >
<return type= "void" >
</return>
<argument index= "0" name= "scale" type= "Vector3" >
</argument>
<description >
Scales the local transformation by given 3D scale factors in object-local coordinate system.
</description>
</method>
2018-07-26 11:56:21 +02:00
<method name= "set_disable_scale" >
<return type= "void" >
</return>
<argument index= "0" name= "disable" type= "bool" >
</argument>
<description >
2019-10-30 11:19:08 +01:00
Sets whether the node uses a scale of [code](1, 1, 1)[/code] or its local transformation scale. Changes to the local transformation scale are preserved.
2018-07-26 11:56:21 +02:00
</description>
</method>
2017-09-12 22:42:36 +02:00
<method name= "set_identity" >
<return type= "void" >
</return>
<description >
2020-05-03 10:27:36 +02:00
Reset all transformations for this node (sets its [Transform3D] to the identity matrix).
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "set_ignore_transform_notification" >
<return type= "void" >
</return>
<argument index= "0" name= "enabled" type= "bool" >
</argument>
<description >
2019-06-22 01:04:47 +02:00
Sets whether the node ignores notification that its transformation (global or local) changed.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "set_notify_local_transform" >
<return type= "void" >
</return>
<argument index= "0" name= "enable" type= "bool" >
</argument>
<description >
2020-03-30 18:22:57 +02:00
Sets whether the node notifies about its local transformation changes. [Node3D] will not propagate this by default.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "set_notify_transform" >
<return type= "void" >
</return>
<argument index= "0" name= "enable" type= "bool" >
</argument>
<description >
2020-05-08 21:59:25 +02:00
Sets whether the node notifies about its global and local transformation changes. [Node3D] will not propagate this by default, unless it is in the editor context and it has a valid gizmo.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "show" >
<return type= "void" >
</return>
<description >
2019-01-07 10:02:04 +01:00
Enables rendering of this node. Changes [member visible] to [code]true[/code].
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "to_global" qualifiers= "const" >
<return type= "Vector3" >
</return>
<argument index= "0" name= "local_point" type= "Vector3" >
</argument>
<description >
2019-06-22 01:04:47 +02:00
Transforms [code]local_point[/code] from this node's local space to world space.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "to_local" qualifiers= "const" >
<return type= "Vector3" >
</return>
<argument index= "0" name= "global_point" type= "Vector3" >
</argument>
<description >
2019-06-22 01:04:47 +02:00
Transforms [code]global_point[/code] from world space to this node's local space.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "translate" >
<return type= "void" >
</return>
<argument index= "0" name= "offset" type= "Vector3" >
</argument>
<description >
2020-01-26 06:59:51 +01:00
Changes the node's position by the given offset [Vector3].
2019-06-24 23:33:21 +02:00
Note that the translation [code]offset[/code] is affected by the node's scale, so if scaled by e.g. [code](10, 1, 1)[/code], a translation by an offset of [code](2, 0, 0)[/code] would actually add 20 ([code]2 * 10[/code]) to the X coordinate.
2017-09-12 22:42:36 +02:00
</description>
</method>
2018-01-03 13:45:03 +01:00
<method name= "translate_object_local" >
<return type= "void" >
</return>
<argument index= "0" name= "offset" type= "Vector3" >
</argument>
<description >
2020-01-26 06:59:51 +01:00
Changes the node's position by the given offset [Vector3] in local space.
2018-01-03 13:45:03 +01:00
</description>
</method>
2021-06-23 16:49:50 +02:00
<method name= "update_gizmos" >
2017-09-12 22:42:36 +02:00
<return type= "void" >
</return>
<description >
2021-06-23 16:49:50 +02:00
Updates all the [Node3DGizmo]s attached to this node.
2017-09-12 22:42:36 +02:00
</description>
</method>
</methods>
<members >
2020-05-03 10:27:36 +02:00
<member name= "global_transform" type= "Transform3D" setter= "set_global_transform" getter= "get_global_transform" >
World3D space (global) [Transform3D] of this node.
2017-09-12 22:42:36 +02:00
</member>
2019-09-24 19:45:03 +02:00
<member name= "position" type= "Vector3" setter= "set_position" getter= "get_position" default= "Vector3(0, 0, 0)" >
2020-12-08 18:35:30 +01:00
Local position or translation of this node relative to the parent. This is equivalent to [code]transform.origin[/code].
</member>
Fix editor suffixes and degrees conversion
* Functions to convert to/from degrees are all gone. Conversion is done by the editor.
* Use PROPERTY_HINT_ANGLE instead of PROPERTY_HINT_RANGE to edit radian angles in degrees.
* Added possibility to add suffixes to range properties, use "min,max[,step][,suffix:<something>]" example "0,100,1,suffix:m"
* In general, can add suffixes for EditorSpinSlider
Not covered by this PR, will have to be addressed by future ones:
* Ability to switch radians/degrees in the inspector for angle properties (if actually wanted).
* Animations previously made will most likely break, need to add a way to make old ones compatible.
* Only added a "px" suffix to 2D position and a "m" one to 3D position, someone needs to go through the rest of the engine and add all remaining suffixes.
* Likely also need to track down usage of EditorSpinSlider outside properties to add suffixes to it too.
2021-06-29 21:42:12 +02:00
<member name= "rotation" type= "Vector3" setter= "set_rotation" getter= "get_rotation" default= "Vector3(0, 0, 0)" >
2019-06-22 01:04:47 +02:00
Rotation part of the local transformation in radians, specified in terms of YXZ-Euler angles in the format (X angle, Y angle, Z angle).
[b]Note:[/b] In the mathematical sense, rotation is a matrix and not a vector. The three Euler angles, which are the three independent parameters of the Euler-angle parametrization of the rotation matrix, are stored in a [Vector3] data structure not because the rotation is a vector, but only because [Vector3] exists as a convenient data-structure to store 3 floating-point numbers. Therefore, applying affine operations on the rotation "vector" is not meaningful.
2017-09-12 22:42:36 +02:00
</member>
2019-09-24 19:45:03 +02:00
<member name= "scale" type= "Vector3" setter= "set_scale" getter= "get_scale" default= "Vector3(1, 1, 1)" >
Restore the behavior of Spatial rotations recently changed in c1153f5.
That change was borne out of a confusion regarding the meaning of "local" in #14569.
Affine transformations in Spatial simply correspond to affine operations of its Transform. Such operations take place in a coordinate system that is defined by the parent Spatial. When there is no parent, they correspond to operations in the global coordinate system.
This coordinate system, which is relative to the parent, has been referred to as the local coordinate system in the docs so far, but this sloppy language has apparently confused some users, making them think that the local coordinate system refers to the one whose axes are "painted" on the Spatial node itself.
To avoid such conceptual conflations and misunderstandings in the future, the parent-relative local system is now referred to as "parent-local", and the object-relative local system is called "object-local" in the docs.
This commit adds the functionality "requested" in #14569, not by changing how rotate/scale/translate works, but by adding new rotate_object_local, scale_object_local and translate_object_local functions. Also, for completeness, there is now global_scale.
This commit also updates another part of the docs regarding the rotation property of Spatial, which also leads to confusion among some users.
2017-12-27 01:15:20 +01:00
Scale part of the local transformation.
2017-09-12 22:42:36 +02:00
</member>
2020-10-09 15:04:15 +02:00
<member name= "top_level" type= "bool" setter= "set_as_top_level" getter= "is_set_as_top_level" default= "false" >
2020-10-01 08:43:30 +02:00
If [code]true[/code], the node will not inherit its transformations from its parent. Node transformations are only in global space.
</member>
2019-09-24 19:45:03 +02:00
<member name= "transform" type= "Transform3D" setter= "set_transform" getter= "get_transform" default= "Transform3D(1, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0)" >
2020-05-03 10:27:36 +02:00
Local space [Transform3D] of this node, with respect to the parent node.
2017-09-12 22:42:36 +02:00
</member>
2021-05-09 18:23:20 +02:00
<member name= "visibility_parent" type= "NodePath" setter= "set_visibility_parent" getter= "get_visibility_parent" default= "NodePath("")" >
Defines the visibility range parent for this node and its subtree. The visibility parent must be a GeometryInstance3D. Any visual instance will only be visible if the visibility parent (and all of its visibility ancestors) is hidden by being closer to the camera than its own [member GeometryInstance3D.visibility_range_begin]. Nodes hidden via the [member Node3D.visible] property are essentially removed from the visibility dependency tree, so dependant instances will not take the hidden node or its ancestors into account.
</member>
2019-06-29 12:38:01 +02:00
<member name= "visible" type= "bool" setter= "set_visible" getter= "is_visible" default= "true" >
2020-07-27 12:09:51 +02:00
If [code]true[/code], this node is drawn. The node is only visible if all of its antecedents are visible as well (in other words, [method is_visible_in_tree] must return [code]true[/code]).
2017-09-12 22:42:36 +02:00
</member>
</members>
<signals >
<signal name= "visibility_changed" >
<description >
2017-09-14 07:42:21 +02:00
Emitted when node visibility changes.
2017-09-12 22:42:36 +02:00
</description>
</signal>
</signals>
<constants >
2019-04-15 14:49:41 +02:00
<constant name= "NOTIFICATION_TRANSFORM_CHANGED" value= "2000" >
2020-03-30 18:22:57 +02:00
Node3D nodes receives this notification when their global transform changes. This means that either the current or a parent node changed its transform.
2021-06-23 16:49:50 +02:00
In order for [constant NOTIFICATION_TRANSFORM_CHANGED] to work, users first need to ask for it, with [method set_notify_transform]. The notification is also sent if the node is in the editor context and it has at least one valid gizmo.
2017-09-12 22:42:36 +02:00
</constant>
2017-11-24 23:16:30 +01:00
<constant name= "NOTIFICATION_ENTER_WORLD" value= "41" >
2020-03-30 18:22:57 +02:00
Node3D nodes receives this notification when they are registered to new [World3D] resource.
2017-09-12 22:42:36 +02:00
</constant>
2017-11-24 23:16:30 +01:00
<constant name= "NOTIFICATION_EXIT_WORLD" value= "42" >
2020-03-30 18:22:57 +02:00
Node3D nodes receives this notification when they are unregistered from current [World3D] resource.
2017-09-12 22:42:36 +02:00
</constant>
2017-11-24 23:16:30 +01:00
<constant name= "NOTIFICATION_VISIBILITY_CHANGED" value= "43" >
2020-03-30 18:22:57 +02:00
Node3D nodes receives this notification when their visibility changes.
2017-09-12 22:42:36 +02:00
</constant>
</constants>
</class>
