2017-09-12 22:42:36 +02:00
<?xml version="1.0" encoding="UTF-8" ?>
2022-08-05 18:51:38 +02:00
<class name= "Spatial" inherits= "Node" version= "3.6" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation= "../class.xsd" >
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 >
2019-03-29 23:37:35 +01:00
Most basic 3D game object, with a 3D [Transform] and visibility settings. All other 3D game objects inherit from Spatial. Use [Spatial] as a parent node to move, scale, rotate and show/hide children in a 3D project.
2019-06-22 01:04:47 +02:00
Affine operations (rotate, scale, translate) happen in parent's local coordinate system, unless the [Spatial] object is set as top-level. Affine operations in this coordinate system correspond to direct affine operations on the [Spatial]'s transform. The word local below refers to this coordinate system. The coordinate system that is attached to the [Spatial] object itself is referred to as object-local coordinate system.
2020-04-17 15:25:55 +02: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 @GDScript.deg2rad].
2017-09-12 22:42:36 +02:00
</description>
<tutorials >
2021-11-15 17:11:20 +01:00
<link title= "Introduction to 3D" > $DOCS_URL/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 >
2018-09-11 00:18:05 +02:00
<method name= "force_update_transform" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
2018-09-11 00:18:05 +02:00
<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-09-15 13:30:45 +02:00
<method name= "get_global_transform_interpolated" >
<return type= "Transform" />
<description >
When using physics interpolation, there will be circumstances in which you want to know the interpolated (displayed) transform of a node rather than the standard transform (which may only be accurate to the most recent physics tick).
This is particularly important for frame-based operations that take place in [method Node._process], rather than [method Node._physics_process]. Examples include [Camera]s focusing on a node, or finding where to fire lasers from on a frame rather than physics tick.
</description>
</method>
2017-09-12 22:42:36 +02:00
<method name= "get_parent_spatial" qualifiers= "const" >
2021-07-30 15:28:05 +02:00
<return type= "Spatial" />
2017-09-12 22:42:36 +02:00
<description >
2019-03-29 23:37:35 +01:00
Returns the parent [Spatial], or an empty [Object] if no parent exists or parent is not of type [Spatial].
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "get_world" qualifiers= "const" >
2021-07-30 15:28:05 +02:00
<return type= "World" />
2017-09-12 22:42:36 +02:00
<description >
2019-03-29 23:37:35 +01:00
Returns the current [World] resource this [Spatial] 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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "axis" type= "Vector3" />
<argument index= "1" name= "angle" type= "float" />
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 >
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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "scale" type= "Vector3" />
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 >
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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "offset" type= "Vector3" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "bool" />
2017-09-12 22:42:36 +02:00
<description >
2019-03-29 23:37:35 +01:00
Returns whether node notifies about its local transformation changes. [Spatial] 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" >
2021-07-30 15:28:05 +02:00
<return type= "bool" />
2018-07-26 11:56:21 +02:00
<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>
2020-10-19 16:58:56 +02:00
<method name= "is_set_as_toplevel" qualifiers= "const" >
2021-07-30 15:28:05 +02:00
<return type= "bool" />
2020-10-19 16:58:56 +02:00
<description >
Returns whether this node is set as Toplevel, that is whether it ignores its parent nodes transformations.
</description>
</method>
2017-09-12 22:42:36 +02:00
<method name= "is_transform_notification_enabled" qualifiers= "const" >
2021-07-30 15:28:05 +02:00
<return type= "bool" />
2017-09-12 22:42:36 +02:00
<description >
2019-03-29 23:37:35 +01:00
Returns whether the node notifies about its global and local transformation changes. [Spatial] will not propagate this by default.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "is_visible_in_tree" qualifiers= "const" >
2021-07-30 15:28:05 +02:00
<return type= "bool" />
2017-09-12 22:42:36 +02:00
<description >
2023-05-04 06:49:50 +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 ancestors are also visible. If any ancestor 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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "target" type= "Vector3" />
<argument index= "1" name= "up" type= "Vector3" />
2017-09-12 22:42:36 +02:00
<description >
2022-01-31 03:49:52 +01:00
Rotates the node so that the local forward axis (-Z) points toward the [code]target[/code] position.
The local up axis (+Y) points as close to the [code]up[/code] vector as possible while staying perpendicular to the local forward axis. The resulting transform is orthogonal, and the scale is preserved. Non-uniform scaling may not work correctly.
The [code]target[/code] position cannot be the same as the node's position, the [code]up[/code] vector cannot be zero, and the direction from the node's position to the [code]target[/code] vector cannot be parallel to the [code]up[/code] vector.
2018-04-29 15:44:07 +02:00
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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "position" type= "Vector3" />
<argument index= "1" name= "target" type= "Vector3" />
<argument index= "2" name= "up" type= "Vector3" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
2017-09-12 22:42:36 +02:00
<description >
2019-01-07 10:02:04 +01: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 [Transform].
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "rotate" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "axis" type= "Vector3" />
<argument index= "1" name= "angle" type= "float" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "axis" type= "Vector3" />
<argument index= "1" name= "angle" type= "float" />
2018-01-03 13:45:03 +01:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "angle" type= "float" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "angle" type= "float" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "angle" type= "float" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "scale" type= "Vector3" />
2018-01-03 13:45:03 +01:00
<description >
Scales the local transformation by given 3D scale factors in object-local coordinate system.
</description>
</method>
2020-10-19 16:58:56 +02:00
<method name= "set_as_toplevel" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "enable" type= "bool" />
2020-10-19 16:58:56 +02:00
<description >
Makes the node ignore its parents transformations. Node transformations are only in global space.
</description>
</method>
2018-07-26 11:56:21 +02:00
<method name= "set_disable_scale" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "disable" type= "bool" />
2018-07-26 11:56:21 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
2017-09-12 22:42:36 +02:00
<description >
2019-06-22 01:04:47 +02:00
Reset all transformations for this node (sets its [Transform] to the identity matrix).
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "set_ignore_transform_notification" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "enabled" type= "bool" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "enable" type= "bool" />
2017-09-12 22:42:36 +02:00
<description >
2019-06-22 01:04:47 +02:00
Sets whether the node notifies about its local transformation changes. [Spatial] will not propagate this by default.
2017-09-12 22:42:36 +02:00
</description>
</method>
<method name= "set_notify_transform" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "enable" type= "bool" />
2017-09-12 22:42:36 +02:00
<description >
2020-05-08 21:59:25 +02:00
Sets whether the node notifies about its global and local transformation changes. [Spatial] 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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "Vector3" />
<argument index= "0" name= "local_point" type= "Vector3" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "Vector3" />
<argument index= "0" name= "global_point" type= "Vector3" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "offset" type= "Vector3" />
2017-09-12 22:42:36 +02:00
<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" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
<argument index= "0" name= "offset" type= "Vector3" />
2018-01-03 13:45:03 +01:00
<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>
2017-09-12 22:42:36 +02:00
<method name= "update_gizmo" >
2021-07-30 15:28:05 +02:00
<return type= "void" />
2017-09-12 22:42:36 +02:00
<description >
2017-09-14 07:42:21 +02:00
Updates the [SpatialGizmo] of this node.
2017-09-12 22:42:36 +02:00
</description>
</method>
</methods>
<members >
2019-06-29 21:22:15 +02:00
<member name= "gizmo" type= "SpatialGizmo" setter= "set_gizmo" getter= "get_gizmo" >
2019-01-07 10:02:04 +01:00
The [SpatialGizmo] for this node. Used for example in [EditorSpatialGizmo] as custom visualization and editing handles in Editor.
2018-01-11 23:38:35 +01:00
</member>
2023-09-20 21:25:45 +02:00
<member name= "global_position" type= "Vector3" setter= "set_global_translation" getter= "get_global_translation" >
Global position of this node. This is a forward-compatible alias for [member global_translation].
</member>
2021-07-21 06:13:52 +02:00
<member name= "global_rotation" type= "Vector3" setter= "set_global_rotation" getter= "get_global_rotation" >
Rotation part of the global 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.
</member>
2019-06-29 21:22:15 +02:00
<member name= "global_transform" type= "Transform" setter= "set_global_transform" getter= "get_global_transform" >
2017-09-12 22:42:36 +02:00
World space (global) [Transform] of this node.
</member>
2021-07-21 06:13:52 +02:00
<member name= "global_translation" type= "Vector3" setter= "set_global_translation" getter= "get_global_translation" >
Global position of this node. This is equivalent to [code]global_transform.origin[/code].
</member>
2023-09-20 21:25:45 +02:00
<member name= "position" type= "Vector3" setter= "set_translation" getter= "get_translation" >
Local position of this node. This is a forward-compatible alias for [member translation].
</member>
2019-06-29 21:22:15 +02:00
<member name= "rotation" type= "Vector3" setter= "set_rotation" getter= "get_rotation" >
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-06-29 12:38:01 +02:00
<member name= "rotation_degrees" type= "Vector3" setter= "set_rotation_degrees" getter= "get_rotation_degrees" default= "Vector3( 0, 0, 0 )" >
2019-06-22 01:04:47 +02:00
Rotation part of the local transformation in degrees, specified in terms of YXZ-Euler angles in the format (X angle, Y angle, Z angle).
2017-09-12 22:42:36 +02:00
</member>
2019-06-29 12:38:01 +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.
2022-06-10 07:56:35 +02:00
[b]Note:[/b] Mixed negative scales in 3D are not decomposable from the transformation matrix. Due to the way scale is represented with transformation matrices in Godot, the scale values will either be all positive or all negative.
2022-10-08 23:14:10 +02:00
[b]Note:[/b] Not all nodes are visually scaled by the [member scale] property. For example, [Light]s are not visually affected by [member scale].
2017-09-12 22:42:36 +02:00
</member>
2019-06-29 12:38:01 +02:00
<member name= "transform" type= "Transform" setter= "set_transform" getter= "get_transform" default= "Transform( 1, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0 )" >
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
Local space [Transform] of this node, with respect to the parent node.
2017-09-12 22:42:36 +02:00
</member>
2019-06-29 12:38:01 +02:00
<member name= "translation" type= "Vector3" setter= "set_translation" getter= "get_translation" default= "Vector3( 0, 0, 0 )" >
2017-09-12 22:42:36 +02:00
Local translation of this node.
</member>
2019-06-29 12:38:01 +02:00
<member name= "visible" type= "bool" setter= "set_visible" getter= "is_visible" default= "true" >
2023-05-04 06:49:50 +02:00
If [code]true[/code], this node is drawn. The node is only visible if all of its ancestors 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 >
2021-02-04 11:43:08 +01:00
<signal name= "gameplay_entered" >
<description >
Emitted by portal system gameplay monitor when a node enters the gameplay area.
</description>
</signal>
<signal name= "gameplay_exited" >
<description >
Emitted by portal system gameplay monitor when a node exits the gameplay area.
</description>
</signal>
2017-09-12 22:42:36 +02:00
<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" >
2017-09-14 07:42:21 +02:00
Spatial nodes receives this notification when their global transform changes. This means that either the current or a parent node changed its transform.
2020-05-08 21:59:25 +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 a 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" >
2017-09-14 07:42:21 +02:00
Spatial nodes receives this notification when they are registered to new [World] 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" >
2017-09-14 07:42:21 +02:00
Spatial nodes receives this notification when they are unregistered from current [World] 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" >
2017-09-14 07:42:21 +02:00
Spatial nodes receives this notification when their visibility changes.
2017-09-12 22:42:36 +02:00
</constant>
2021-02-04 11:43:08 +01:00
<constant name= "NOTIFICATION_ENTER_GAMEPLAY" value= "45" >
Spatial nodes receives this notification if the portal system gameplay monitor detects they have entered the gameplay area.
</constant>
<constant name= "NOTIFICATION_EXIT_GAMEPLAY" value= "46" >
Spatial nodes receives this notification if the portal system gameplay monitor detects they have exited the gameplay area.
</constant>
2017-09-12 22:42:36 +02:00
</constants>
</class>
